repoburg 1.3.97 → 1.3.99

package/backend/node_modules/@typescript-eslint/eslint-plugin/docs/rules/explicit-member-accessibility.md

@@ -1,344 +0,0 @@
----
-description: 'Require explicit accessibility modifiers on class properties and methods.'
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/explicit-member-accessibility** for documentation.
-
-TypeScript allows placing explicit `public`, `protected`, and `private` accessibility modifiers in front of class members.
-The modifiers exist solely in the type system and just serve to describe who is allowed to access those members.
-
-Leaving off accessibility modifiers makes for less code to read and write.
-Members are `public` by default.
-
-However, adding in explicit accessibility modifiers can be helpful in codebases with many classes for enforcing proper privacy of members.
-Some developers also find it preferable for code readability to keep member publicity explicit.
-
-## Examples
-
-This rule aims to make code more readable and explicit about who can use
-which properties.
-
-## Options
-
-### Configuring in a mixed JS/TS codebase
-
-If you are working on a codebase within which you lint non-TypeScript code (i.e. `.js`/`.mjs`/`.cjs`/`.jsx`), you should ensure that you should use [ESLint `overrides`](https://eslint.org/docs/user-guide/configuring#disabling-rules-only-for-a-group-of-files) to only enable the rule on `.ts`/`.mts`/`.cts`/`.tsx` files. If you don't, then you will get unfixable lint errors reported within `.js`/`.mjs`/`.cjs`/`.jsx` files.
-
-```jsonc
-{
-  "rules": {
-    // disable the rule for all files
-    "@typescript-eslint/explicit-member-accessibility": "off",
-  },
-  "overrides": [
-    {
-      // enable the rule specifically for TypeScript files
-      "files": ["*.ts", "*.mts", "*.cts", "*.tsx"],
-      "rules": {
-        "@typescript-eslint/explicit-member-accessibility": "error",
-      },
-    },
-  ],
-}
-```
-
-### `accessibility`
-
-This rule in its default state requires no configuration and will enforce that every class member has an accessibility modifier. If you would like to allow for some implicit public members then you have the following options:
-
-```jsonc
-{
-  "accessibility: "explicit",
-  "overrides": {
-    "accessors": "explicit",
-    "constructors": "no-public",
-    "methods": "explicit",
-    "properties": "off",
-    "parameterProperties": "explicit"
-  }
-}
-```
-
-Note the above is an example of a possible configuration you could use - it is not the default configuration.
-
-The following patterns are considered incorrect code if no options are provided:
-
-```ts showPlaygroundButton
-class Animal {
-  constructor(name) {
-    // No accessibility modifier
-    this.animalName = name;
-  }
-  animalName: string; // No accessibility modifier
-  get name(): string {
-    // No accessibility modifier
-    return this.animalName;
-  }
-  set name(value: string) {
-    // No accessibility modifier
-    this.animalName = value;
-  }
-  walk() {
-    // method
-  }
-}
-```
-
-The following patterns are considered correct with the default options `{ accessibility: 'explicit' }`:
-
-```ts option='{ "accessibility": "explicit" }' showPlaygroundButton
-class Animal {
-  public constructor(
-    public breed,
-    name,
-  ) {
-    // Parameter property and constructor
-    this.animalName = name;
-  }
-  private animalName: string; // Property
-  get name(): string {
-    // get accessor
-    return this.animalName;
-  }
-  set name(value: string) {
-    // set accessor
-    this.animalName = value;
-  }
-  public walk() {
-    // method
-  }
-}
-```
-
-The following patterns are considered incorrect with the accessibility set to **no-public** `[{ accessibility: 'no-public' }]`:
-
-```ts option='{ "accessibility": "no-public" }' showPlaygroundButton
-class Animal {
-  public constructor(
-    public breed,
-    name,
-  ) {
-    // Parameter property and constructor
-    this.animalName = name;
-  }
-  public animalName: string; // Property
-  public get name(): string {
-    // get accessor
-    return this.animalName;
-  }
-  public set name(value: string) {
-    // set accessor
-    this.animalName = value;
-  }
-  public walk() {
-    // method
-  }
-}
-```
-
-The following patterns are considered correct with the accessibility set to **no-public** `[{ accessibility: 'no-public' }]`:
-
-```ts option='{ "accessibility": "no-public" }' showPlaygroundButton
-class Animal {
-  constructor(
-    protected breed,
-    name,
-  ) {
-    // Parameter property and constructor
-    this.name = name;
-  }
-  private animalName: string; // Property
-  get name(): string {
-    // get accessor
-    return this.animalName;
-  }
-  private set name(value: string) {
-    // set accessor
-    this.animalName = value;
-  }
-  protected walk() {
-    // method
-  }
-}
-```
-
-### `overrides`
-
-There are three ways in which an override can be used.
-
-- To disallow the use of public on a given member.
-- To enforce explicit member accessibility when the root has allowed implicit public accessibility
-- To disable any checks on given member type
-
-#### Disallow the use of public on a given member
-
-e.g. `[ { overrides: { constructors: 'no-public' } } ]`
-
-The following patterns are considered incorrect with the example override
-
-```ts option='{ "overrides": { "constructors": "no-public" } }' showPlaygroundButton
-class Animal {
-  public constructor(protected animalName) {}
-  public get name() {
-    return this.animalName;
-  }
-}
-```
-
-The following patterns are considered correct with the example override
-
-```ts option='{ "overrides": { "constructors": "no-public" } }' showPlaygroundButton
-class Animal {
-  constructor(protected animalName) {}
-  public get name() {
-    return this.animalName;
-  }
-}
-```
-
-#### Require explicit accessibility for a given member
-
-e.g. `[ { accessibility: 'no-public', overrides: { properties: 'explicit' } } ]`
-
-The following patterns are considered incorrect with the example override
-
-```ts option='{ "accessibility": "no-public", "overrides": { "properties": "explicit" } }' showPlaygroundButton
-class Animal {
-  constructor(protected animalName) {}
-  get name() {
-    return this.animalName;
-  }
-  protected set name(value: string) {
-    this.animalName = value;
-  }
-  legs: number;
-  private hasFleas: boolean;
-}
-```
-
-The following patterns are considered correct with the example override
-
-```ts option='{ "accessibility": "no-public", "overrides": { "properties": "explicit" } }' showPlaygroundButton
-class Animal {
-  constructor(protected animalName) {}
-  get name() {
-    return this.animalName;
-  }
-  protected set name(value: string) {
-    this.animalName = value;
-  }
-  public legs: number;
-  private hasFleas: boolean;
-}
-```
-
-e.g. `[ { accessibility: 'off', overrides: { parameterProperties: 'explicit' } } ]`
-
-The following code is considered incorrect with the example override
-
-```ts option='{ "accessibility": "off", "overrides": { "parameterProperties": "explicit" } }' showPlaygroundButton
-class Animal {
-  constructor(readonly animalName: string) {}
-}
-```
-
-The following code patterns are considered correct with the example override
-
-```ts option='{ "accessibility": "off", "overrides": { "parameterProperties": "explicit" } }' showPlaygroundButton
-class Animal {
-  constructor(public readonly animalName: string) {}
-}
-
-class Animal {
-  constructor(public animalName: string) {}
-}
-
-class Animal {
-  constructor(animalName: string) {}
-}
-```
-
-e.g. `[ { accessibility: 'off', overrides: { parameterProperties: 'no-public' } } ]`
-
-The following code is considered incorrect with the example override
-
-```ts option='{ "accessibility": "off", "overrides": { "parameterProperties": "no-public" } }' showPlaygroundButton
-class Animal {
-  constructor(public readonly animalName: string) {}
-}
-```
-
-The following code is considered correct with the example override
-
-```ts option='{ "accessibility": "off", "overrides": { "parameterProperties": "no-public" } }' showPlaygroundButton
-class Animal {
-  constructor(public animalName: string) {}
-}
-```
-
-#### Disable any checks on given member type
-
-e.g. `[{ overrides: { accessors : 'off' } } ]`
-
-As no checks on the overridden member type are performed all permutations of visibility are permitted for that member type
-
-The follow pattern is considered incorrect for the given configuration
-
-```ts option='{ "overrides": { "accessors" : "off" } }' showPlaygroundButton
-class Animal {
-  constructor(protected animalName) {}
-  public get name() {
-    return this.animalName;
-  }
-  get legs() {
-    return this.legCount;
-  }
-}
-```
-
-The following patterns are considered correct with the example override
-
-```ts option='{ "overrides": { "accessors" : "off" } }' showPlaygroundButton
-class Animal {
-  public constructor(protected animalName) {}
-  public get name() {
-    return this.animalName;
-  }
-  get legs() {
-    return this.legCount;
-  }
-}
-```
-
-### `ignoredMethodNames`
-
-If you want to ignore some specific methods, you can do it by specifying method names. Note that this option does not care for the context, and will ignore every method with these names, which could lead to it missing some cases. You should use this sparingly.
-e.g. `[ { ignoredMethodNames: ['specificMethod', 'whateverMethod'] } ]`
-
-```ts option='{ "ignoredMethodNames": ["specificMethod", "whateverMethod"] }' showPlaygroundButton
-class Animal {
-  get specificMethod() {
-    console.log('No error because you specified this method on option');
-  }
-  get whateverMethod() {
-    console.log('No error because you specified this method on option');
-  }
-  public get otherMethod() {
-    console.log('This method comply with this rule');
-  }
-}
-```
-
-## When Not To Use It
-
-If you think defaulting to public is a good default, then you should consider using the `no-public` setting.
-If you want to mix implicit and explicit public members then you can disable this rule.
-
-However, keep in mind that inconsistent style can harm readability in a project.
-We recommend picking a single option for this rule that works best for your project.
-
-## Further Reading
-
-- TypeScript [Accessibility Modifiers Handbook Docs](https://www.typescriptlang.org/docs/handbook/2/classes.html#member-visibility)

package/backend/node_modules/@typescript-eslint/eslint-plugin/docs/rules/explicit-module-boundary-types.md

@@ -1,249 +0,0 @@
----
-description: "Require explicit return and argument types on exported functions' and classes' public class methods."
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/explicit-module-boundary-types** for documentation.
-
-Explicit types for function return values and arguments makes it clear to any calling code what is the module boundary's input and output.
-Adding explicit type annotations for those types can help improve code readability.
-It can also improve TypeScript type checking performance on larger codebases.
-
-## Examples
-
-<!--tabs-->
-
-### ❌ Incorrect
-
-```ts
-// Should indicate that no value is returned (void)
-export function test() {
-  return;
-}
-
-// Should indicate that a string is returned
-export var arrowFn = () => 'test';
-
-// All arguments should be typed
-export var arrowFn = (arg): string => `test ${arg}`;
-export var arrowFn = (arg: any): string => `test ${arg}`;
-
-export class Test {
-  // Should indicate that no value is returned (void)
-  method() {
-    return;
-  }
-}
-```
-
-### ✅ Correct
-
-```ts
-// A function with no return value (void)
-export function test(): void {
-  return;
-}
-
-// A return value of type string
-export var arrowFn = (): string => 'test';
-
-// All arguments should be typed
-export var arrowFn = (arg: string): string => `test ${arg}`;
-export var arrowFn = (arg: unknown): string => `test ${arg}`;
-
-export class Test {
-  // A class method with no return value (void)
-  method(): void {
-    return;
-  }
-}
-
-// The function does not apply because it is not an exported function.
-function test() {
-  return;
-}
-```
-
-## Options
-
-### Configuring in a mixed JS/TS codebase
-
-If you are working on a codebase within which you lint non-TypeScript code (i.e. `.js`/`.mjs`/`.cjs`/`.jsx`), you should ensure that you should use [ESLint `overrides`](https://eslint.org/docs/user-guide/configuring#disabling-rules-only-for-a-group-of-files) to only enable the rule on `.ts`/`.mts`/`.cts`/`.tsx` files. If you don't, then you will get unfixable lint errors reported within `.js`/`.mjs`/`.cjs`/`.jsx` files.
-
-```jsonc
-{
-  "rules": {
-    // disable the rule for all files
-    "@typescript-eslint/explicit-module-boundary-types": "off",
-  },
-  "overrides": [
-    {
-      // enable the rule specifically for TypeScript files
-      "files": ["*.ts", "*.mts", "*.cts", "*.tsx"],
-      "rules": {
-        "@typescript-eslint/explicit-module-boundary-types": "error",
-      },
-    },
-  ],
-}
-```
-
-### `allowArgumentsExplicitlyTypedAsAny`
-
-Examples of code for this rule with `{ allowArgumentsExplicitlyTypedAsAny: false }`:
-
-<!--tabs-->
-
-#### ❌ Incorrect
-
-```ts option='{ "allowArgumentsExplicitlyTypedAsAny": false }'
-export const func = (value: any): number => value + 1;
-```
-
-#### ✅ Correct
-
-```ts option='{ "allowArgumentsExplicitlyTypedAsAny": false }'
-export const func = (value: number): number => value + 1;
-```
-
-### `allowDirectConstAssertionInArrowFunctions`
-
-Examples of code for this rule with `{ allowDirectConstAssertionInArrowFunctions: false }`:
-
-<!--tabs-->
-
-#### ❌ Incorrect
-
-```ts option='{ "allowArgumentsExplicitlyTypedAsAny": false }'
-export const func = (value: number) => ({ type: 'X', value });
-export const foo = () => ({
-  bar: true,
-});
-export const bar = () => 1;
-```
-
-#### ✅ Correct
-
-```ts option='{ "allowArgumentsExplicitlyTypedAsAny": false }'
-export const func = (value: number) => ({ type: 'X', value }) as const;
-export const foo = () =>
-  ({
-    bar: true,
-  }) as const;
-export const bar = () => 1 as const;
-```
-
-### `allowedNames`
-
-You may pass function/method names you would like this rule to ignore, like so:
-
-```json
-{
-  "@typescript-eslint/explicit-module-boundary-types": [
-    "error",
-    {
-      "allowedNames": ["ignoredFunctionName", "ignoredMethodName"]
-    }
-  ]
-}
-```
-
-### `allowHigherOrderFunctions`
-
-Examples of code for this rule with `{ allowHigherOrderFunctions: false }`:
-
-<!--tabs-->
-
-#### ❌ Incorrect
-
-```ts option='{ "allowHigherOrderFunctions": false }'
-export const arrowFn = () => () => {};
-
-export function fn() {
-  return function () {};
-}
-
-export function foo(outer: string) {
-  return function (inner: string) {};
-}
-```
-
-#### ✅ Correct
-
-```ts option='{ "allowHigherOrderFunctions": false }'
-export const arrowFn = () => (): void => {};
-
-export function fn() {
-  return function (): void {};
-}
-
-export function foo(outer: string) {
-  return function (inner: string): void {};
-}
-```
-
-### `allowTypedFunctionExpressions`
-
-Examples of code for this rule with `{ allowTypedFunctionExpressions: false }`:
-
-<!--tabs-->
-
-#### ❌ Incorrect
-
-```ts option='{ "allowTypedFunctionExpressions": false }'
-export let arrowFn = () => 'test';
-
-export let funcExpr = function () {
-  return 'test';
-};
-
-export let objectProp = {
-  foo: () => 1,
-};
-
-export const foo = bar => {};
-```
-
-#### ✅ Correct
-
-```ts option='{ "allowTypedFunctionExpressions": false }'
-type FuncType = () => string;
-
-export let arrowFn: FuncType = () => 'test';
-
-export let funcExpr: FuncType = function () {
-  return 'test';
-};
-
-export let asTyped = (() => '') as () => string;
-export let castTyped = <() => string>(() => '');
-
-interface ObjectType {
-  foo(): number;
-}
-export let objectProp: ObjectType = {
-  foo: () => 1,
-};
-export let objectPropAs = {
-  foo: () => 1,
-} as ObjectType;
-export let objectPropCast = <ObjectType>{
-  foo: () => 1,
-};
-
-type FooType = (bar: string) => void;
-export const foo: FooType = bar => {};
-```
-
-## When Not To Use It
-
-If your project is not used by downstream consumers that are sensitive to API types, you can disable this rule.
-
-## Further Reading
-
-- TypeScript [Functions](https://www.typescriptlang.org/docs/handbook/functions.html#function-types)
-
-## Related To
-
-- [explicit-function-return-type](./explicit-function-return-type.md)

package/backend/node_modules/@typescript-eslint/eslint-plugin/docs/rules/func-call-spacing.md

@@ -1,10 +0,0 @@
----
-description: 'Require or disallow spacing between function identifiers and their invocations.'
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/func-call-spacing** for documentation.
-
-This rule extends the base [`eslint/func-call-spacing`](https://eslint.org/docs/rules/func-call-spacing) rule.
-It adds support for generic type parameters on function calls.

package/backend/node_modules/@typescript-eslint/eslint-plugin/docs/rules/indent.md

@@ -1,18 +0,0 @@
----
-description: 'Enforce consistent indentation.'
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/indent** for documentation.
-
-## Warning
-
-:::warning
-
-Please read [Issue #1824: Problems with the indent rule](https://github.com/typescript-eslint/typescript-eslint/issues/1824) before using this rule!
-
-:::
-
-This rule extends the base [`eslint/indent`](https://eslint.org/docs/rules/indent) rule.
-It adds support for TypeScript nodes.

package/backend/node_modules/@typescript-eslint/eslint-plugin/docs/rules/init-declarations.md

@@ -1,10 +0,0 @@
----
-description: 'Require or disallow initialization in variable declarations.'
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/init-declarations** for documentation.
-
-This rule extends the base [`eslint/init-declarations`](https://eslint.org/docs/rules/init-declarations) rule.
-It adds support for TypeScript's `declare` variables.

package/backend/node_modules/@typescript-eslint/eslint-plugin/docs/rules/key-spacing.md

@@ -1,10 +0,0 @@
----
-description: 'Enforce consistent spacing between property names and type annotations in types and interfaces.'
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/key-spacing** for documentation.
-
-This rule extends the base [`eslint/key-spacing`](https://eslint.org/docs/rules/key-spacing) rule.
-It adds support for type annotations on interfaces, classes and type literals properties.

package/backend/node_modules/@typescript-eslint/eslint-plugin/docs/rules/keyword-spacing.md

@@ -1,10 +0,0 @@
----
-description: 'Enforce consistent spacing before and after keywords.'
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/keyword-spacing** for documentation.
-
-This rule extends the base [`eslint/keyword-spacing`](https://eslint.org/docs/rules/keyword-spacing) rule.
-It adds support for generic type parameters on function calls.

package/backend/node_modules/@typescript-eslint/eslint-plugin/docs/rules/lines-around-comment.md

@@ -1,25 +0,0 @@
----
-description: 'Require empty lines around comments.'
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/lines-around-comment** for documentation.
-
-This rule extends the base [`eslint/lines-around-comment`](https://eslint.org/docs/rules/lines-around-comment) rule.
-It adds support for TypeScript syntax.
-
-See the [ESLint documentation](https://eslint.org/docs/rules/lines-around-comment) for more details on the `lines-around-comment` rule.
-
-## Options
-
-In addition to the options supported by the `lines-around-comment` rule in ESLint core, the rule adds the following options:
-
-- `allowEnumEnd: true` doesn't require a blank line after an enum body block end
-- `allowEnumStart: true` doesn't require a blank line before an enum body block start
-- `allowInterfaceEnd: true` doesn't require a blank line before an interface body block end
-- `allowInterfaceStart: true` doesn't require a blank line after an interface body block start
-- `allowModuleEnd: true` doesn't require a blank line before a module body block end
-- `allowModuleStart: true` doesn't require a blank line after a module body block start
-- `allowTypeEnd: true` doesn't require a blank line before a type literal block end
-- `allowTypeStart: true` doesn't require a blank line after a type literal block start