@alexlit/lint-kit 111.0.0 → 112.0.0

package/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-unsafe-assignment.mdx

@@ -0,0 +1,100 @@
+---
+description: 'Disallow assigning a value with type `any` to variables and properties.'
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+> 🛑 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>
+<TabItem value="❌ 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>>>();
+```
+
+</TabItem>
+<TabItem value="✅ 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>>>();
+```
+
+</TabItem>
+</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.mdx)
+- [`no-unsafe-argument`](./no-unsafe-argument.mdx)
+- [`no-unsafe-call`](./no-unsafe-call.mdx)
+- [`no-unsafe-member-access`](./no-unsafe-member-access.mdx)
+- [`no-unsafe-return`](./no-unsafe-return.mdx)

package/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-unsafe-call.mdx

@@ -0,0 +1,74 @@
+---
+description: 'Disallow calling a value with type `any`.'
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+> 🛑 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>
+<TabItem value="❌ 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`;
+```
+
+</TabItem>
+<TabItem value="✅ Correct">
+
+```ts
+declare const typedVar: () => void;
+declare const typedNested: { prop: { a: () => void } };
+
+typedVar();
+typedNested.prop.a();
+
+(() => {})();
+
+new Map();
+
+String.raw`foo`;
+```
+
+</TabItem>
+</Tabs>
+
+## 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.mdx)
+- [`no-unsafe-argument`](./no-unsafe-argument.mdx)
+- [`no-unsafe-assignment`](./no-unsafe-assignment.mdx)
+- [`no-unsafe-member-access`](./no-unsafe-member-access.mdx)
+- [`no-unsafe-return`](./no-unsafe-return.mdx)

package/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-unsafe-declaration-merging.mdx

@@ -0,0 +1,65 @@
+---
+description: 'Disallow unsafe declaration merging.'
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+> 🛑 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>
+<TabItem value="❌ Incorrect">
+
+```ts
+interface Foo {}
+
+class Foo {}
+```
+
+</TabItem>
+<TabItem value="✅ Correct">
+
+```ts
+interface Foo {}
+class Bar implements Foo {}
+
+namespace Baz {}
+namespace Baz {}
+enum Baz {}
+
+namespace Qux {}
+function Qux() {}
+```
+
+</TabItem>
+</Tabs>
+
+## 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/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-unsafe-enum-comparison.mdx

@@ -0,0 +1,86 @@
+---
+description: 'Disallow comparing an enum value with a non-enum value.'
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+> 🛑 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>
+<TabItem value="❌ Incorrect">
+
+```ts
+enum Fruit {
+  Apple,
+}
+
+declare let fruit: Fruit;
+
+fruit === 0;
+```
+
+```ts
+enum Vegetable {
+  Asparagus = 'asparagus',
+}
+
+declare let vegetable: Vegetable;
+
+vegetable === 'asparagus';
+```
+
+</TabItem>
+<TabItem value="✅ Correct">
+
+```ts
+enum Fruit {
+  Apple,
+}
+
+declare let fruit: Fruit;
+
+fruit === Fruit.Apple;
+```
+
+```ts
+enum Vegetable {
+  Asparagus = 'asparagus',
+}
+
+declare let vegetable: Vegetable;
+
+vegetable === Vegetable.Asparagus;
+```
+
+</TabItem>
+</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/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-unsafe-member-access.mdx

@@ -0,0 +1,80 @@
+---
+description: 'Disallow member access on a value with type `any`.'
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+> 🛑 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>
+<TabItem value="❌ 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];
+```
+
+</TabItem>
+<TabItem value="✅ 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++];
+```
+
+</TabItem>
+</Tabs>
+
+## 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.mdx)
+- [`no-unsafe-argument`](./no-unsafe-argument.mdx)
+- [`no-unsafe-assignment`](./no-unsafe-assignment.mdx)
+- [`no-unsafe-call`](./no-unsafe-call.mdx)
+- [`no-unsafe-return`](./no-unsafe-return.mdx)

package/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-unsafe-return.mdx

@@ -0,0 +1,117 @@
+---
+description: 'Disallow returning a value with type `any` from a function.'
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+> 🛑 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>
+<TabItem value="❌ 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]);
+```
+
+</TabItem>
+<TabItem value="✅ 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']);
+```
+
+</TabItem>
+</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.mdx)
+- [`no-unsafe-argument`](./no-unsafe-argument.mdx)
+- [`no-unsafe-assignment`](./no-unsafe-assignment.mdx)
+- [`no-unsafe-call`](./no-unsafe-call.mdx)
+- [`no-unsafe-member-access`](./no-unsafe-member-access.mdx)

package/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-unsafe-unary-minus.mdx

@@ -0,0 +1,60 @@
+---
+description: 'Require unary negation to take a number.'
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+> 🛑 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
+
+<Tabs>
+<TabItem value="❌ Incorrect">
+
+```ts
+declare const a: string;
+-a;
+
+declare const b: {};
+-b;
+```
+
+</TabItem>
+<TabItem value="✅ 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;
+```
+
+</TabItem>
+</Tabs>
+
+{/* Intentionally Omitted: When Not To Use It */}

package/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-unused-expressions.mdx

@@ -0,0 +1,13 @@
+---
+description: 'Disallow unused expressions.'
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+> 🛑 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/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-unused-vars.mdx

@@ -0,0 +1,49 @@
+---
+description: 'Disallow unused variables.'
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+> 🛑 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 `_`.
+    If you would like to emulate the TypeScript style of exempting names starting with `_`, you can use this configuration (this includes errors as well):
+    ```json
+    {
+      "rules": {
+        "@typescript-eslint/no-unused-vars": [
+          "error",
+          {
+            "args": "all",
+            "argsIgnorePattern": "^_",
+            "caughtErrors": "all",
+            "caughtErrorsIgnorePattern": "^_",
+            "destructuredArrayIgnorePattern": "^_",
+            "varsIgnorePattern": "^_",
+            "ignoreRestSiblings": true
+          }
+        ]
+      }
+    }
+    ```
+- [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.
+:::