repoburg 1.3.98 → 1.3.99

package/backend/node_modules/@typescript-eslint/eslint-plugin/docs/rules/class-literal-property-style.md

@@ -1,105 +0,0 @@
----
-description: 'Enforce that literals on classes are exposed in a consistent style.'
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/class-literal-property-style** for documentation.
-
-Some TypeScript applications store literal values on classes using fields with the `readonly` modifier to prevent them from being reassigned.
-When writing TypeScript libraries that could be used by JavaScript users, however, it's typically safer to expose these literals using `getter`s, since the `readonly` modifier is enforced at compile type.
-
-This rule aims to ensure that literals exposed by classes are done so consistently, in one of the two style described above.
-By default this rule prefers the `fields` style as it means JS doesn't have to setup & teardown a function closure.
-
-## Options
-
-:::note
-
-This rule only checks for constant _literal_ values (string, template string, number, bigint, boolean, regexp, null). It does not check objects or arrays, because a readonly field behaves differently to a getter in those cases. It also does not check functions, as it is a common pattern to use readonly fields with arrow function values as auto-bound methods.
-This is because these types can be mutated and carry with them more complex implications about their usage.
-
-:::
-
-### `"fields"`
-
-This style checks for any getter methods that return literal values, and requires them to be defined using fields with the `readonly` modifier instead.
-
-Examples of code with the `fields` style:
-
-<!--tabs-->
-
-#### ❌ Incorrect
-
-```ts option='"fields"'
-class Mx {
-  public static get myField1() {
-    return 1;
-  }
-
-  private get ['myField2']() {
-    return 'hello world';
-  }
-}
-```
-
-#### ✅ Correct
-
-```ts option='"fields"'
-class Mx {
-  public readonly myField1 = 1;
-
-  // not a literal
-  public readonly myField2 = [1, 2, 3];
-
-  private readonly ['myField3'] = 'hello world';
-
-  public get myField4() {
-    return `hello from ${window.location.href}`;
-  }
-}
-```
-
-### `"getters"`
-
-This style checks for any `readonly` fields that are assigned literal values, and requires them to be defined as getters instead.
-This style pairs well with the [`@typescript-eslint/prefer-readonly`](prefer-readonly.md) rule,
-as it will identify fields that can be `readonly`, and thus should be made into getters.
-
-Examples of code with the `getters` style:
-
-<!--tabs-->
-
-#### ❌ Incorrect
-
-```ts option='"getters"'
-class Mx {
-  readonly myField1 = 1;
-  readonly myField2 = `hello world`;
-  private readonly myField3 = 'hello world';
-}
-```
-
-#### ✅ Correct
-
-```ts option='"getters"'
-class Mx {
-  // no readonly modifier
-  public myField1 = 'hello';
-
-  // not a literal
-  public readonly myField2 = [1, 2, 3];
-
-  public static get myField3() {
-    return 1;
-  }
-
-  private get ['myField4']() {
-    return 'hello world';
-  }
-}
-```
-
-## When Not To Use It
-
-When you have no strong preference, or do not wish to enforce a particular style for how literal values are exposed by your classes.

package/backend/node_modules/@typescript-eslint/eslint-plugin/docs/rules/class-methods-use-this.md

@@ -1,96 +0,0 @@
----
-description: 'Enforce that class methods utilize `this`.'
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/class-methods-use-this** for documentation.
-
-This rule extends the base [`eslint/class-methods-use-this`](https://eslint.org/docs/rules/class-methods-use-this) rule.
-It adds support for ignoring `override` methods or methods on classes that implement an interface.
-
-## Options
-
-This rule adds the following options:
-
-```ts
-interface Options extends BaseClassMethodsUseThisOptions {
-  ignoreOverrideMethods?: boolean;
-  ignoreClassesThatImplementAnInterface?: boolean | 'public-fields';
-}
-
-const defaultOptions: Options = {
-  ...baseClassMethodsUseThisOptions,
-  ignoreOverrideMethods: false,
-  ignoreClassesThatImplementAnInterface: false,
-};
-```
-
-### `ignoreOverrideMethods`
-
-Makes the rule to ignores any class member explicitly marked with `override`.
-
-Example of a correct code when `ignoreOverrideMethods` is set to `true`:
-
-```ts option='{ "ignoreOverrideMethods": true }' showPlaygroundButton
-class X {
-  override method() {}
-  override property = () => {};
-}
-```
-
-### `ignoreClassesThatImplementAnInterface`
-
-Makes the rule ignore class members that are defined within a class that `implements` a type.
-If specified, it can be either:
-
-- `true`: Ignore all classes that implement an interface
-- `'public-fields'`: Ignore only the public fields of classes that implement an interface
-
-It's important to note that this option does not only apply to members defined in the interface as that would require type information.
-
-#### `true`
-
-Example of a correct code when `ignoreClassesThatImplementAnInterface` is set to `true`:
-
-```ts option='{ "ignoreClassesThatImplementAnInterface": true }' showPlaygroundButton
-class X implements Y {
-  method() {}
-  property = () => {};
-}
-```
-
-#### `'public-fields'`
-
-Example of a incorrect code when `ignoreClassesThatImplementAnInterface` is set to `'public-fields'`:
-
-<!--tabs-->
-
-##### ❌ Incorrect
-
-```ts
-class X implements Y {
-  method() {}
-  property = () => {};
-
-  private privateMethod() {}
-  private privateProperty = () => {};
-
-  protected privateMethod() {}
-  protected privateProperty = () => {};
-}
-```
-
-##### ✅ Correct
-
-```ts
-class X implements Y {
-  method() {}
-  property = () => {};
-}
-```
-
-## When Not To Use It
-
-If your project dynamically changes `this` scopes around in a way TypeScript has difficulties modeling, this rule may not be viable to use.
-You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.

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

@@ -1,20 +0,0 @@
----
-description: 'Require or disallow trailing commas.'
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/comma-dangle** for documentation.
-
-This rule extends the base [`eslint/comma-dangle`](https://eslint.org/docs/rules/comma-dangle) rule.
-It adds support for TypeScript syntax.
-
-See the [ESLint documentation](https://eslint.org/docs/rules/comma-dangle) for more details on the `comma-dangle` rule.
-
-## Options
-
-In addition to the options supported by the `comma-dangle` rule in ESLint core, the rule adds the following options:
-
-- `"enums"` is for trailing comma in enum. (e.g. `enum Foo = {Bar,}`)
-- `"generics"` is for trailing comma in generic. (e.g. `function foo<T,>() {}`)
-- `"tuples"` is for trailing comma in tuple. (e.g. `type Foo = [string,]`)

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

@@ -1,10 +0,0 @@
----
-description: 'Enforce consistent spacing before and after commas.'
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/comma-spacing** for documentation.
-
-This rule extends the base [`eslint/comma-spacing`](https://eslint.org/docs/rules/comma-spacing) rule.
-It adds support for trailing comma in a types parameters list.

package/backend/node_modules/@typescript-eslint/eslint-plugin/docs/rules/consistent-generic-constructors.md

@@ -1,76 +0,0 @@
----
-description: 'Enforce specifying generic type arguments on type annotation or constructor name of a constructor call.'
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/consistent-generic-constructors** for documentation.
-
-When constructing a generic class, you can specify the type arguments on either the left-hand side (as a type annotation) or the right-hand side (as part of the constructor call):
-
-```ts
-// Left-hand side
-const map: Map<string, number> = new Map();
-
-// Right-hand side
-const map = new Map<string, number>();
-```
-
-This rule ensures that type arguments appear consistently on one side of the declaration.
-Keeping to one side consistently improve code readability.
-
-> The rule never reports when there are type parameters on both sides, or neither sides of the declaration.
-> It also doesn't report if the names of the type annotation and the constructor don't match.
-
-## Options
-
-- `constructor` _(default)_: type arguments that **only** appear on the type annotation are disallowed.
-- `type-annotation`: type arguments that **only** appear on the constructor are disallowed.
-
-### `constructor`
-
-<!--tabs-->
-
-#### ❌ Incorrect
-
-```ts option='"constructor"'
-const map: Map<string, number> = new Map();
-const set: Set<string> = new Set();
-```
-
-#### ✅ Correct
-
-```ts option='"constructor"'
-const map = new Map<string, number>();
-const map: Map<string, number> = new MyMap();
-const set = new Set<string>();
-const set = new Set();
-const set: Set<string> = new Set<string>();
-```
-
-### `type-annotation`
-
-<!--tabs-->
-
-#### ❌ Incorrect
-
-```ts option='"type-annotation"'
-const map = new Map<string, number>();
-const set = new Set<string>();
-```
-
-#### ✅ Correct
-
-```ts option='"type-annotation"'
-const map: Map<string, number> = new Map();
-const set: Set<string> = new Set();
-const set = new Set();
-const set: Set<string> = new Set<string>();
-```
-
-## When Not To Use It
-
-You can turn this rule off if you don't want to enforce one kind of generic constructor style over the other.
-
-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.

package/backend/node_modules/@typescript-eslint/eslint-plugin/docs/rules/consistent-indexed-object-style.md

@@ -1,80 +0,0 @@
----
-description: 'Require or disallow the `Record` type.'
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/consistent-indexed-object-style** for documentation.
-
-TypeScript supports defining arbitrary object keys using an index signature. TypeScript also has a builtin type named `Record` to create an empty object defining only an index signature. For example, the following types are equal:
-
-```ts
-interface Foo {
-  [key: string]: unknown;
-}
-
-type Foo = {
-  [key: string]: unknown;
-};
-
-type Foo = Record<string, unknown>;
-```
-
-Keeping to one declaration form consistently improve code readability.
-
-## Options
-
-- `"record"` _(default)_: only allow the `Record` type.
-- `"index-signature"`: only allow index signatures.
-
-### `record`
-
-<!--tabs-->
-
-#### ❌ Incorrect
-
-```ts option='"record"'
-interface Foo {
-  [key: string]: unknown;
-}
-
-type Foo = {
-  [key: string]: unknown;
-};
-```
-
-#### ✅ Correct
-
-```ts option='"record"'
-type Foo = Record<string, unknown>;
-```
-
-### `index-signature`
-
-<!--tabs-->
-
-#### ❌ Incorrect
-
-```ts option='"index-signature"'
-type Foo = Record<string, unknown>;
-```
-
-#### ✅ Correct
-
-```ts option='"index-signature"'
-interface Foo {
-  [key: string]: unknown;
-}
-
-type Foo = {
-  [key: string]: unknown;
-};
-```
-
-## When Not To Use It
-
-This rule is purely a stylistic rule for maintaining consistency in your project.
-You can turn it off if you don't want to keep a consistent style for indexed object types.
-
-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.

package/backend/node_modules/@typescript-eslint/eslint-plugin/docs/rules/consistent-type-assertions.md

@@ -1,113 +0,0 @@
----
-description: 'Enforce consistent usage of type assertions.'
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/consistent-type-assertions** for documentation.
-
-TypeScript provides two syntaxes for "type assertions":
-
-- Angle brackets: `<Type>value`
-- As: `value as Type`
-
-This rule aims to standardize the use of type assertion style across the codebase.
-Keeping to one syntax consistently helps with code readability.
-
-:::note
-Type assertions are also commonly referred as "type casting" in TypeScript.
-However, that term is technically slightly different to what is understood by type casting in other languages.
-Type assertions are a way to say to the TypeScript compiler, _"I know better than you, it's actually this different type!"_.
-:::
-
-[`const` assertions](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-4.html#const-assertions) are always allowed by this rule.
-Examples of them include `let x = "hello" as const;` and `let x = <const>"hello";`.
-
-## Options
-
-### `assertionStyle`
-
-This option defines the expected assertion style. Valid values for `assertionStyle` are:
-
-- `as` will enforce that you always use `... as foo`.
-- `angle-bracket` will enforce that you always use `<foo>...`
-- `never` will enforce that you do not do any type assertions.
-
-Most codebases will want to enforce not using `angle-bracket` style because it conflicts with JSX syntax, and is confusing when paired with generic syntax.
-
-Some codebases like to go for an extra level of type safety, and ban assertions altogether via the `never` option.
-
-### `objectLiteralTypeAssertions`
-
-Always prefer `const x: T = { ... };` to `const x = { ... } as T;` (or similar with angle brackets). The type assertion in the latter case is either unnecessary or will probably hide an error.
-
-The compiler will warn for excess properties with this syntax, but not missing _required_ fields. For example: `const x: { foo: number } = {};` will fail to compile, but `const x = {} as { foo: number }` will succeed.
-
-The const assertion `const x = { foo: 1 } as const`, introduced in TypeScript 3.4, is considered beneficial and is ignored by this option.
-
-Assertions to `any` are also ignored by this option.
-
-Examples of code for `{ assertionStyle: 'as', objectLiteralTypeAssertions: 'never' }`:
-
-<!--tabs-->
-
-#### ❌ Incorrect
-
-```ts option='{ "assertionStyle": "as", "objectLiteralTypeAssertions": "never" }'
-const x = { foo: 1 } as T;
-
-function bar() {
-  return { foo: 1 } as T;
-}
-```
-
-#### ✅ Correct
-
-```ts option='{ "assertionStyle": "as", "objectLiteralTypeAssertions": "never" }'
-const x: T = { foo: 1 };
-const y = { foo: 1 } as any;
-const z = { foo: 1 } as unknown;
-
-function bar(): T {
-  return { foo: 1 };
-}
-```
-
-<!--/tabs-->
-
-Examples of code for `{ assertionStyle: 'as', objectLiteralTypeAssertions: 'allow-as-parameter' }`:
-
-<!--tabs-->
-
-#### ❌ Incorrect
-
-```ts option='{ "assertionStyle": "as", "objectLiteralTypeAssertions": "allow-as-parameter" }'
-const x = { foo: 1 } as T;
-
-function bar() {
-  return { foo: 1 } as T;
-}
-```
-
-#### ✅ Correct
-
-```tsx option='{ "assertionStyle": "as", "objectLiteralTypeAssertions": "allow-as-parameter" }'
-const x: T = { foo: 1 };
-const y = { foo: 1 } as any;
-const z = { foo: 1 } as unknown;
-bar({ foo: 1 } as T);
-new Clazz({ foo: 1 } as T);
-function bar() {
-  throw { foo: 1 } as Foo;
-}
-const foo = <Foo props={{ bar: 1 } as Bar} />;
-```
-
-<!--/tabs-->
-
-## When Not To Use It
-
-If you do not want to enforce consistent type assertions.
-
-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.

package/backend/node_modules/@typescript-eslint/eslint-plugin/docs/rules/consistent-type-definitions.md

@@ -1,81 +0,0 @@
----
-description: 'Enforce type definitions to consistently use either `interface` or `type`.'
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/consistent-type-definitions** for documentation.
-
-TypeScript provides two common ways to define an object type: `interface` and `type`.
-
-```ts
-// type alias
-type T1 = {
-  a: string;
-  b: number;
-};
-
-// interface keyword
-interface T2 {
-  a: string;
-  b: number;
-}
-```
-
-The two are generally very similar, and can often be used interchangeably.
-Using the same type declaration style consistently helps with code readability.
-
-## Options
-
-- `"interface"` _(default)_: enforce using `interface`s for object type definitions.
-- `"type"`: enforce using `type`s for object type definitions.
-
-### `interface`
-
-<!--tabs-->
-
-#### ❌ Incorrect
-
-```ts option='"interface"'
-type T = { x: number };
-```
-
-#### ✅ Correct
-
-```ts option='"interface"'
-type T = string;
-type Foo = string | {};
-
-interface T {
-  x: number;
-}
-```
-
-### `type`
-
-<!--tabs-->
-
-#### ❌ Incorrect
-
-```ts option='"type"'
-interface T {
-  x: number;
-}
-```
-
-#### ✅ Correct
-
-```ts option='"type"'
-type T = { x: number };
-```
-
-## When Not To Use It
-
-If you specifically want to use an interface or type literal for stylistic reasons, you can avoid 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.
-
-There are also subtle differences between `Record` and `interface` that can be difficult to catch statically.
-For example, if your project is a dependency of another project that relies on a specific type definition style, this rule may be counterproductive.
-You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.

package/backend/node_modules/@typescript-eslint/eslint-plugin/docs/rules/consistent-type-exports.md

@@ -1,105 +0,0 @@
----
-description: 'Enforce consistent usage of type exports.'
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/consistent-type-exports** for documentation.
-
-TypeScript allows specifying a `type` keyword on exports to indicate that the export exists only in the type system, not at runtime.
-This allows transpilers to drop exports without knowing the types of the dependencies.
-
-> See [Blog > Consistent Type Exports and Imports: Why and How](/blog/consistent-type-imports-and-exports-why-and-how) for more details.
-
-## Examples
-
-<!--tabs-->
-
-### ❌ Incorrect
-
-```ts
-interface ButtonProps {
-  onClick: () => void;
-}
-
-class Button implements ButtonProps {
-  onClick = () => console.log('button!');
-}
-
-export { Button, ButtonProps };
-```
-
-### ✅ Correct
-
-```ts
-interface ButtonProps {
-  onClick: () => void;
-}
-
-class Button implements ButtonProps {
-  onClick = () => console.log('button!');
-}
-
-export { Button };
-export type { ButtonProps };
-```
-
-## Options
-
-### `fixMixedExportsWithInlineTypeSpecifier`
-
-When this is set to true, the rule will autofix "mixed" export cases using TS 4.5's "inline type specifier".
-If you are using a TypeScript version less than 4.5, then you will not be able to use this option.
-
-For example the following code:
-
-```ts
-const x = 1;
-type T = number;
-
-export { x, T };
-```
-
-With `{fixMixedExportsWithInlineTypeSpecifier: true}` will be fixed to:
-
-```ts
-const x = 1;
-type T = number;
-
-export { x, type T };
-```
-
-With `{fixMixedExportsWithInlineTypeSpecifier: false}` will be fixed to:
-
-```ts
-const x = 1;
-type T = number;
-
-export type { T };
-export { x };
-```
-
-<!--tabs-->
-
-### ❌ Incorrect
-
-```ts option='{ "fixMixedExportsWithInlineTypeSpecifier": true }'
-export { Button } from 'some-library';
-export type { ButtonProps } from 'some-library';
-```
-
-### ✅ Correct
-
-```ts option='{ "fixMixedExportsWithInlineTypeSpecifier": true }'
-export { Button, type ButtonProps } from 'some-library';
-```
-
-## When Not To Use It
-
-If you use `--isolatedModules` the compiler would error if a type is not re-exported using `export type`.
-This rule may be less useful in those cases.
-
-If you specifically want to use both export kinds for stylistic reasons, or don't wish to enforce one style over the other, you can avoid 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.