repoburg 1.3.98 → 1.3.99

package/backend/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-unsafe-assignment.md

@@ -1,96 +0,0 @@
----
-description: 'Disallow assigning a value with type `any` to variables and properties.'
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/no-unsafe-assignment** for documentation.
-
-The `any` type in TypeScript is a dangerous "escape hatch" from the type system.
-Using `any` disables many type checking rules and is generally best used only as a last resort or when prototyping code.
-
-Despite your best intentions, the `any` type can sometimes leak into your codebase.
-Assigning an `any` typed value to a variable can be hard to pick up on, particularly if it leaks in from an external library.
-
-This rule disallows assigning `any` to a variable, and assigning `any[]` to an array destructuring.
-
-This rule also compares generic type argument types to ensure you don't pass an unsafe `any` in a generic position to a receiver that's expecting a specific type.
-For example, it will error if you assign `Set<any>` to a variable declared as `Set<string>`.
-
-## Examples
-
-<!--tabs-->
-
-### ❌ Incorrect
-
-```ts
-const x = 1 as any,
-  y = 1 as any;
-const [x] = 1 as any;
-const [x] = [] as any[];
-const [x] = [1 as any];
-[x] = [1] as [any];
-
-function foo(a = 1 as any) {}
-class Foo {
-  constructor(private a = 1 as any) {}
-}
-class Foo {
-  private a = 1 as any;
-}
-
-// generic position examples
-const x: Set<string> = new Set<any>();
-const x: Map<string, string> = new Map<string, any>();
-const x: Set<string[]> = new Set<any[]>();
-const x: Set<Set<Set<string>>> = new Set<Set<Set<any>>>();
-```
-
-### ✅ Correct
-
-```ts
-const x = 1,
-  y = 1;
-const [x] = [1];
-[x] = [1] as [number];
-
-function foo(a = 1) {}
-class Foo {
-  constructor(private a = 1) {}
-}
-class Foo {
-  private a = 1;
-}
-
-// generic position examples
-const x: Set<string> = new Set<string>();
-const x: Map<string, string> = new Map<string, string>();
-const x: Set<string[]> = new Set<string[]>();
-const x: Set<Set<Set<string>>> = new Set<Set<Set<string>>>();
-```
-
-<!--/tabs-->
-
-There are cases where the rule allows assignment of `any` to `unknown`.
-
-Example of `any` to `unknown` assignment that are allowed:
-
-```ts showPlaygroundButton
-const x: unknown = y as any;
-const x: unknown[] = y as any[];
-const x: Set<unknown> = y as Set<any>;
-```
-
-## When Not To Use It
-
-If your codebase has many existing `any`s or areas of unsafe code, it may be difficult to enable this rule.
-It may be easier to skip the `no-unsafe-*` rules pending increasing type safety in unsafe areas of your project.
-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.
-
-## Related To
-
-- [`no-explicit-any`](./no-explicit-any.md)
-- [`no-unsafe-argument`](./no-unsafe-argument.md)
-- [`no-unsafe-call`](./no-unsafe-call.md)
-- [`no-unsafe-member-access`](./no-unsafe-member-access.md)
-- [`no-unsafe-return`](./no-unsafe-return.md)

package/backend/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-unsafe-call.md

@@ -1,68 +0,0 @@
----
-description: 'Disallow calling a value with type `any`.'
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/no-unsafe-call** for documentation.
-
-The `any` type in TypeScript is a dangerous "escape hatch" from the type system.
-Using `any` disables many type checking rules and is generally best used only as a last resort or when prototyping code.
-
-Despite your best intentions, the `any` type can sometimes leak into your codebase.
-Calling an `any`-typed value as a function creates a potential type safety hole and source of bugs in your codebase.
-
-This rule disallows calling any value that is typed as `any`.
-
-## Examples
-
-<!--tabs-->
-
-### ❌ Incorrect
-
-```ts
-declare const anyVar: any;
-declare const nestedAny: { prop: any };
-
-anyVar();
-anyVar.a.b();
-
-nestedAny.prop();
-nestedAny.prop['a']();
-
-new anyVar();
-new nestedAny.prop();
-
-anyVar`foo`;
-nestedAny.prop`foo`;
-```
-
-### ✅ Correct
-
-```ts
-declare const typedVar: () => void;
-declare const typedNested: { prop: { a: () => void } };
-
-typedVar();
-typedNested.prop.a();
-
-(() => {})();
-
-new Map();
-
-String.raw`foo`;
-```
-
-## When Not To Use It
-
-If your codebase has many existing `any`s or areas of unsafe code, it may be difficult to enable this rule.
-It may be easier to skip the `no-unsafe-*` rules pending increasing type safety in unsafe areas of your project.
-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.
-
-## Related To
-
-- [`no-explicit-any`](./no-explicit-any.md)
-- [`no-unsafe-argument`](./no-unsafe-argument.md)
-- [`no-unsafe-assignment`](./no-unsafe-assignment.md)
-- [`no-unsafe-member-access`](./no-unsafe-member-access.md)
-- [`no-unsafe-return`](./no-unsafe-return.md)

package/backend/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-unsafe-declaration-merging.md

@@ -1,59 +0,0 @@
----
-description: 'Disallow unsafe declaration merging.'
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/no-unsafe-declaration-merging** for documentation.
-
-TypeScript's "declaration merging" supports merging separate declarations with the same name.
-
-Declaration merging between classes and interfaces is unsafe.
-The TypeScript compiler doesn't check whether properties are initialized, which can cause lead to TypeScript not detecting code that will cause runtime errors.
-
-```ts
-interface Foo {
-  nums: number[];
-}
-
-class Foo {}
-
-const foo = new Foo();
-
-foo.nums.push(1); // Runtime Error: Cannot read properties of undefined.
-```
-
-## Examples
-
-<!--tabs-->
-
-### ❌ Incorrect
-
-```ts
-interface Foo {}
-
-class Foo {}
-```
-
-### ✅ Correct
-
-```ts
-interface Foo {}
-class Bar implements Foo {}
-
-namespace Baz {}
-namespace Baz {}
-enum Baz {}
-
-namespace Qux {}
-function Qux() {}
-```
-
-## When Not To Use It
-
-If your project intentionally defines classes and interfaces with unsafe declaration merging patterns, this rule might not be for you.
-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.
-
-## Further Reading
-
-- [Declaration Merging](https://www.typescriptlang.org/docs/handbook/declaration-merging.html)

package/backend/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-unsafe-enum-comparison.md

@@ -1,82 +0,0 @@
----
-description: 'Disallow comparing an enum value with a non-enum value.'
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/no-unsafe-enum-comparison** for documentation.
-
-The TypeScript compiler can be surprisingly lenient when working with enums. String enums are widely considered to be safer than number enums, but even string enums have some pitfalls. For example, it is allowed to compare enum values against literals:
-
-```ts
-enum Vegetable {
-  Asparagus = 'asparagus',
-}
-
-declare const vegetable: Vegetable;
-
-vegetable === 'asparagus'; // No error
-```
-
-The above code snippet should instead be written as `vegetable === Vegetable.Asparagus`. Allowing literals in comparisons subverts the point of using enums in the first place. By enforcing comparisons with properly typed enums:
-
-- It makes a codebase more resilient to enum members changing values.
-- It allows for code IDEs to use the "Rename Symbol" feature to quickly rename an enum.
-- It aligns code to the proper enum semantics of referring to them by name and treating their values as implementation details.
-
-## Examples
-
-<!--tabs-->
-
-### ❌ Incorrect
-
-```ts
-enum Fruit {
-  Apple,
-}
-
-declare let fruit: Fruit;
-
-fruit === 0;
-```
-
-```ts
-enum Vegetable {
-  Asparagus = 'asparagus',
-}
-
-declare let vegetable: Vegetable;
-
-vegetable === 'asparagus';
-```
-
-### ✅ Correct
-
-```ts
-enum Fruit {
-  Apple,
-}
-
-declare let fruit: Fruit;
-
-fruit === Fruit.Apple;
-```
-
-```ts
-enum Vegetable {
-  Asparagus = 'asparagus',
-}
-
-declare let vegetable: Vegetable;
-
-vegetable === Vegetable.Asparagus;
-```
-
-<!--/tabs-->
-
-## When Not To Use It
-
-If you don't mind number and/or literal string constants being compared against enums, you likely don't need this rule.
-
-Separately, in the rare case of relying on an third party enums that are only imported as `type`s, it may be difficult to adhere to this rule.
-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/no-unsafe-member-access.md

@@ -1,74 +0,0 @@
----
-description: 'Disallow member access on a value with type `any`.'
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/no-unsafe-member-access** for documentation.
-
-The `any` type in TypeScript is a dangerous "escape hatch" from the type system.
-Using `any` disables many type checking rules and is generally best used only as a last resort or when prototyping code.
-
-Despite your best intentions, the `any` type can sometimes leak into your codebase.
-Accessing a member of an `any`-typed value creates a potential type safety hole and source of bugs in your codebase.
-
-This rule disallows member access on any variable that is typed as `any`.
-
-## Examples
-
-<!--tabs-->
-
-### ❌ Incorrect
-
-```ts
-declare const anyVar: any;
-declare const nestedAny: { prop: any };
-
-anyVar.a;
-anyVar.a.b;
-anyVar['a'];
-anyVar['a']['b'];
-
-nestedAny.prop.a;
-nestedAny.prop['a'];
-
-const key = 'a';
-nestedAny.prop[key];
-
-// Using an any to access a member is unsafe
-const arr = [1, 2, 3];
-arr[anyVar];
-nestedAny[anyVar];
-```
-
-### ✅ Correct
-
-```ts
-declare const properlyTyped: { prop: { a: string } };
-
-properlyTyped.prop.a;
-properlyTyped.prop['a'];
-
-const key = 'a';
-properlyTyped.prop[key];
-
-const arr = [1, 2, 3];
-arr[1];
-let idx = 1;
-arr[idx];
-arr[idx++];
-```
-
-## When Not To Use It
-
-If your codebase has many existing `any`s or areas of unsafe code, it may be difficult to enable this rule.
-It may be easier to skip the `no-unsafe-*` rules pending increasing type safety in unsafe areas of your project.
-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.
-
-## Related To
-
-- [`no-explicit-any`](./no-explicit-any.md)
-- [`no-unsafe-argument`](./no-unsafe-argument.md)
-- [`no-unsafe-assignment`](./no-unsafe-assignment.md)
-- [`no-unsafe-call`](./no-unsafe-call.md)
-- [`no-unsafe-return`](./no-unsafe-return.md)

package/backend/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-unsafe-return.md

@@ -1,113 +0,0 @@
----
-description: 'Disallow returning a value with type `any` from a function.'
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/no-unsafe-return** for documentation.
-
-The `any` type in TypeScript is a dangerous "escape hatch" from the type system.
-Using `any` disables many type checking rules and is generally best used only as a last resort or when prototyping code.
-
-Despite your best intentions, the `any` type can sometimes leak into your codebase.
-Returning an an `any`-typed value from a function creates a potential type safety hole and source of bugs in your codebase.
-
-This rule disallows returning `any` or `any[]` from a function.
-
-This rule also compares generic type argument types to ensure you don't return an unsafe `any` in a generic position to a function that's expecting a specific type.
-For example, it will error if you return `Set<any>` from a function declared as returning `Set<string>`.
-
-## Examples
-
-<!--tabs-->
-
-### ❌ Incorrect
-
-```ts
-function foo1() {
-  return 1 as any;
-}
-function foo2() {
-  return Object.create(null);
-}
-const foo3 = () => {
-  return 1 as any;
-};
-const foo4 = () => Object.create(null);
-
-function foo5() {
-  return [] as any[];
-}
-function foo6() {
-  return [] as Array<any>;
-}
-function foo7() {
-  return [] as readonly any[];
-}
-function foo8() {
-  return [] as Readonly<any[]>;
-}
-const foo9 = () => {
-  return [] as any[];
-};
-const foo10 = () => [] as any[];
-
-const foo11 = (): string[] => [1, 2, 3] as any[];
-
-// generic position examples
-function assignability1(): Set<string> {
-  return new Set<any>([1]);
-}
-type TAssign = () => Set<string>;
-const assignability2: TAssign = () => new Set<any>([true]);
-```
-
-### ✅ Correct
-
-```ts
-function foo1() {
-  return 1;
-}
-function foo2() {
-  return Object.create(null) as Record<string, unknown>;
-}
-
-const foo3 = () => [];
-const foo4 = () => ['a'];
-
-function assignability1(): Set<string> {
-  return new Set<string>(['foo']);
-}
-type TAssign = () => Set<string>;
-const assignability2: TAssign = () => new Set(['foo']);
-```
-
-<!--/tabs-->
-
-There are cases where the rule allows to return `any` to `unknown`.
-
-Examples of `any` to `unknown` return that are allowed:
-
-```ts showPlaygroundButton
-function foo1(): unknown {
-  return JSON.parse(singleObjString); // Return type for JSON.parse is any.
-}
-
-function foo2(): unknown[] {
-  return [] as any[];
-}
-```
-
-## When Not To Use It
-
-If your codebase has many existing `any`s or areas of unsafe code, it may be difficult to enable this rule.
-It may be easier to skip the `no-unsafe-*` rules pending increasing type safety in unsafe areas of your project.
-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.
-
-## Related To
-
-- [`no-explicit-any`](./no-explicit-any.md)
-- [`no-unsafe-argument`](./no-unsafe-argument.md)
-- [`no-unsafe-assignment`](./no-unsafe-assignment.md)
-- [`no-unsafe-call`](./no-unsafe-call.md)
-- [`no-unsafe-member-access`](./no-unsafe-member-access.md)

package/backend/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-unsafe-unary-minus.md

@@ -1,52 +0,0 @@
----
-description: 'Require unary negation to take a number.'
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/no-unsafe-unary-minus** for documentation.
-
-TypeScript does not prevent you from putting a minus sign before things other than numbers:
-
-```ts
-const s = 'hello';
-const x = -s; // x is NaN
-```
-
-This rule restricts the unary `-` operator to `number | bigint`.
-
-## Examples
-
-### ❌ Incorrect
-
-```ts
-declare const a: string;
--a;
-
-declare const b: {};
--b;
-```
-
-### ✅ Correct
-
-```ts
--42;
--42n;
-
-declare const a: number;
--a;
-
-declare const b: number;
--b;
-
-declare const c: number | bigint;
--c;
-
-declare const d: any;
--d;
-
-declare const e: 1 | 2;
--e;
-```
-
-<!-- Intentionally Omitted: When Not To Use It -->

package/backend/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-unused-expressions.md

@@ -1,10 +0,0 @@
----
-description: 'Disallow unused expressions.'
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/no-unused-expressions** for documentation.
-
-This rule extends the base [`eslint/no-unused-expressions`](https://eslint.org/docs/rules/no-unused-expressions) rule.
-It adds support for optional call expressions `x?.()`, and directive in module declarations.

package/backend/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-unused-vars.md

@@ -1,27 +0,0 @@
----
-description: 'Disallow unused variables.'
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/no-unused-vars** for documentation.
-
-This rule extends the base [`eslint/no-unused-vars`](https://eslint.org/docs/rules/no-unused-vars) rule.
-It adds support for TypeScript features, such as types.
-
-## Benefits Over TypeScript
-
-TypeScript provides [`noUnusedLocals`](https://www.typescriptlang.org/tsconfig#noUnusedLocals) and [`noUnusedParameters`](https://www.typescriptlang.org/tsconfig#noUnusedParameters) compiler options that can report errors on unused local variables or parameters, respectively.
-Those compiler options can be convenient to use if you don't want to set up ESLint and typescript-eslint.
-However:
-
-- These lint rules are more configurable than TypeScript's compiler options.
-  - For example, the [`varsIgnorePattern` option](https://eslint.org/docs/latest/rules/no-unused-vars#varsignorepattern) can customize what names are always allowed to be exempted. TypeScript hardcodes its exemptions to names starting with `_`.
-- [ESLint can be configured](https://eslint.org/docs/latest/use/configure/rules) within lines, files, and folders. TypeScript compiler options are linked to their TSConfig file.
-- Many projects configure TypeScript's reported errors to block builds more aggressively than ESLint complaints. Blocking builds on unused variables can be inconvenient.
-
-We generally recommend using `@typescript-eslint/no-unused-vars` to flag unused locals and parameters instead of TypeScript.
-
-:::tip
-Editors such as VS Code will still generally "grey out" unused variables even if `noUnusedLocals` and `noUnusedParameters` are not enabled in a project.
-:::

package/backend/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-use-before-define.md

@@ -1,87 +0,0 @@
----
-description: 'Disallow the use of variables before they are defined.'
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/no-use-before-define** for documentation.
-
-This rule extends the base [`eslint/no-use-before-define`](https://eslint.org/docs/rules/no-use-before-define) rule.
-It adds support for `type`, `interface` and `enum` declarations.
-
-## Options
-
-This rule adds the following options:
-
-```ts
-interface Options extends BaseNoUseBeforeDefineOptions {
-  enums?: boolean;
-  typedefs?: boolean;
-  ignoreTypeReferences?: boolean;
-}
-
-const defaultOptions: Options = {
-  ...baseNoUseBeforeDefineDefaultOptions,
-  enums: true,
-  typedefs: true,
-  ignoreTypeReferences: true,
-};
-```
-
-### `enums`
-
-If this is `true`, this rule warns every reference to a enum before the enum declaration.
-If this is `false`, this rule will ignore references to enums, when the reference is in a child scope.
-
-Examples of code for the `{ "enums": true }` option:
-
-<!--tabs-->
-
-#### ❌ Incorrect
-
-```ts option='{ "enums": true }'
-const x = Foo.FOO;
-
-enum Foo {
-  FOO,
-}
-```
-
-#### ✅ Correct
-
-```ts option='{ "enums": false }'
-function foo() {
-  return Foo.FOO;
-}
-
-enum Foo {
-  FOO,
-}
-```
-
-### `typedefs`
-
-If this is `true`, this rule warns every reference to a type before the type declaration.
-If this is `false`, this rule will ignore references to types.
-
-Examples of **correct** code for the `{ "typedefs": false }` option:
-
-```ts option='{ "typedefs": false }' showPlaygroundButton
-let myVar: StringOrNumber;
-type StringOrNumber = string | number;
-```
-
-### `ignoreTypeReferences`
-
-If this is `true`, this rule ignores all type references, such as in type annotations and assertions.
-If this is `false`, this will will check all type references.
-
-Examples of **correct** code for the `{ "ignoreTypeReferences": true }` option:
-
-```ts option='{ "ignoreTypeReferences": true }' showPlaygroundButton
-let var1: StringOrNumber;
-type StringOrNumber = string | number;
-
-let var2: Enum;
-enum Enum {}
-```

package/backend/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-useless-constructor.md

@@ -1,19 +0,0 @@
----
-description: 'Disallow unnecessary constructors.'
----
-
-> 🛑 This file is source code, not the primary documentation location! 🛑
->
-> See **https://typescript-eslint.io/rules/no-useless-constructor** for documentation.
-
-This rule extends the base [`eslint/no-useless-constructor`](https://eslint.org/docs/rules/no-useless-constructor) rule.
-It adds support for:
-
-- constructors marked as `protected` / `private` (i.e. marking a constructor as non-public),
-- `public` constructors when there is no superclass,
-- constructors with only parameter properties.
-
-### Caveat
-
-This lint rule will report on constructors whose sole purpose is to change visibility of a parent constructor.
-See [discussion on this rule's lack of type information](https://github.com/typescript-eslint/typescript-eslint/issues/3820#issuecomment-917821240) for context.