@alexlit/lint-kit 111.0.0 → 112.0.0

package/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/camelcase.md

@@ -0,0 +1,11 @@
+:::danger Deprecated
+
+This rule has been deprecated in favour of the [`naming-convention`](./naming-convention.mdx) rule.
+
+:::
+
+<!-- This doc file has been left on purpose because `camelcase` is a core ESLint
+rule. This exists to help direct people to the replacement rule.
+
+Note that there is no actual way to get to this page in the normal navigation,
+so end-users will only be able to get to this page from the search bar. -->

package/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/class-literal-property-style.mdx

@@ -0,0 +1,112 @@
+---
+description: 'Enforce that literals on classes are exposed in a consistent style.'
+---
+
+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/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>
+<TabItem value="❌ Incorrect">
+
+```ts option='"fields"'
+class Mx {
+  public static get myField1() {
+    return 1;
+  }
+
+  private get ['myField2']() {
+    return 'hello world';
+  }
+}
+```
+
+</TabItem>
+<TabItem value="✅ 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}`;
+  }
+}
+```
+
+</TabItem>
+</Tabs>
+
+### `"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.mdx) 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>
+<TabItem value="❌ Incorrect">
+
+```ts option='"getters"'
+class Mx {
+  readonly myField1 = 1;
+  readonly myField2 = `hello world`;
+  private readonly myField3 = 'hello world';
+}
+```
+
+</TabItem>
+<TabItem value="✅ 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';
+  }
+}
+```
+
+</TabItem>
+</Tabs>
+
+## 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/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/class-methods-use-this.mdx

@@ -0,0 +1,102 @@
+---
+description: 'Enforce that class methods utilize `this`.'
+---
+
+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/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 correct code when `ignoreClassesThatImplementAnInterface` is set to `true`:
+
+```ts option='{ "ignoreClassesThatImplementAnInterface": true }' showPlaygroundButton
+class X implements Y {
+  method() {}
+  property = () => {};
+}
+```
+
+#### `'public-fields'`
+
+Example of incorrect code when `ignoreClassesThatImplementAnInterface` is set to `'public-fields'`:
+
+<Tabs>
+<TabItem value="❌ Incorrect">
+
+```ts
+class X implements Y {
+  method() {}
+  property = () => {};
+
+  private privateMethod() {}
+  private privateProperty = () => {};
+
+  protected privateMethod() {}
+  protected privateProperty = () => {};
+}
+```
+
+</TabItem>
+<TabItem value="✅ Correct">
+
+```ts
+class X implements Y {
+  method() {}
+  property = () => {};
+}
+```
+
+</TabItem>
+</Tabs>
+
+## 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/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/comma-dangle.mdx

@@ -0,0 +1,23 @@
+---
+description: 'Require or disallow trailing commas.'
+---
+
+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/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/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/comma-spacing.mdx

@@ -0,0 +1,13 @@
+---
+description: 'Enforce consistent spacing before and after commas.'
+---
+
+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/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/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/consistent-generic-constructors.mdx

@@ -0,0 +1,85 @@
+---
+description: 'Enforce specifying generic type arguments on type annotation or constructor name of a constructor call.'
+---
+
+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/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>
+<TabItem value="❌ Incorrect">
+
+```ts option='"constructor"'
+const map: Map<string, number> = new Map();
+const set: Set<string> = new Set();
+```
+
+</TabItem>
+<TabItem value="✅ 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>();
+```
+
+</TabItem>
+</Tabs>
+
+### `type-annotation`
+
+<Tabs>
+<TabItem value="❌ Incorrect">
+
+```ts option='"type-annotation"'
+const map = new Map<string, number>();
+const set = new Set<string>();
+```
+
+</TabItem>
+<TabItem value="✅ 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>();
+```
+
+</TabItem>
+</Tabs>
+
+## 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/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/consistent-indexed-object-style.mdx

@@ -0,0 +1,89 @@
+---
+description: 'Require or disallow the `Record` type.'
+---
+
+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/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>
+<TabItem value="❌ Incorrect">
+
+```ts option='"record"'
+interface Foo {
+  [key: string]: unknown;
+}
+
+type Foo = {
+  [key: string]: unknown;
+};
+```
+
+</TabItem>
+<TabItem value="✅ Correct">
+
+```ts option='"record"'
+type Foo = Record<string, unknown>;
+```
+
+</TabItem>
+</Tabs>
+
+### `index-signature`
+
+<Tabs>
+<TabItem value="❌ Incorrect">
+
+```ts option='"index-signature"'
+type Foo = Record<string, unknown>;
+```
+
+</TabItem>
+<TabItem value="✅ Correct">
+
+```ts option='"index-signature"'
+interface Foo {
+  [key: string]: unknown;
+}
+
+type Foo = {
+  [key: string]: unknown;
+};
+```
+
+</TabItem>
+</Tabs>
+
+## 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/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/consistent-return.mdx

@@ -0,0 +1,48 @@
+---
+description: 'Require `return` statements to either always or never specify values.'
+---
+
+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/consistent-return** for documentation.
+
+This rule extends the base [`eslint/consistent-return`](https://eslint.org/docs/rules/consistent-return) rule.
+This version adds support for functions that return `void` or `Promise<void>`.
+
+<Tabs>
+<TabItem value="❌ Incorrect">
+
+```ts
+function foo(): undefined {}
+function bar(flag: boolean): undefined {
+  if (flag) return foo();
+  return;
+}
+
+async function baz(flag: boolean): Promise<undefined> {
+  if (flag) return;
+  return foo();
+}
+```
+
+</TabItem>
+<TabItem value="✅ Correct">
+
+```ts
+function foo(): void {}
+function bar(flag: boolean): void {
+  if (flag) return foo();
+  return;
+}
+
+async function baz(flag: boolean): Promise<void | number> {
+  if (flag) return 42;
+  return;
+}
+```
+
+</TabItem>
+</Tabs>

package/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/consistent-type-assertions.mdx

@@ -0,0 +1,118 @@
+---
+description: 'Enforce consistent usage of type assertions.'
+---
+
+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/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>
+<TabItem value="❌ Incorrect">
+
+```ts option='{ "assertionStyle": "as", "objectLiteralTypeAssertions": "never" }'
+const x = { foo: 1 } as T;
+
+function bar() {
+  return { foo: 1 } as T;
+}
+```
+
+</TabItem>
+<TabItem value="✅ 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 };
+}
+```
+
+</TabItem>
+</Tabs>
+
+Examples of code for `{ assertionStyle: 'as', objectLiteralTypeAssertions: 'allow-as-parameter' }`:
+
+<Tabs>
+<TabItem value="❌ Incorrect">
+
+```ts option='{ "assertionStyle": "as", "objectLiteralTypeAssertions": "allow-as-parameter" }'
+const x = { foo: 1 } as T;
+
+function bar() {
+  return { foo: 1 } as T;
+}
+```
+
+</TabItem>
+<TabItem value="✅ 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} />;
+```
+
+</TabItem>
+</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/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/consistent-type-definitions.mdx

@@ -0,0 +1,90 @@
+---
+description: 'Enforce type definitions to consistently use either `interface` or `type`.'
+---
+
+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/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>
+<TabItem value="❌ Incorrect">
+
+```ts option='"interface"'
+type T = { x: number };
+```
+
+</TabItem>
+<TabItem value="✅ Correct">
+
+```ts option='"interface"'
+type T = string;
+type Foo = string | {};
+
+interface T {
+  x: number;
+}
+```
+
+</TabItem>
+</Tabs>
+
+### `type`
+
+<Tabs>
+<TabItem value="❌ Incorrect">
+
+```ts option='"type"'
+interface T {
+  x: number;
+}
+```
+
+</TabItem>
+<TabItem value="✅ Correct">
+
+```ts option='"type"'
+type T = { x: number };
+```
+
+</TabItem>
+</Tabs>
+
+## 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.