@typescript-eslint/eslint-plugin 8.33.1-alpha.5 → 8.33.1

package/docs/rules/ban-ts-comment.mdx

@@ -1,165 +0,0 @@
----
-description: 'Disallow `@ts-<directive>` comments or require descriptions after directives.'
----
-
-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/ban-ts-comment** for documentation.
-
-TypeScript provides several directive comments that can be used to alter how it processes files.
-Using these to suppress TypeScript compiler errors reduces the effectiveness of TypeScript overall.
-Instead, it's generally better to correct the types of code, to make directives unnecessary.
-
-The directive comments supported by TypeScript are:
-
-```ts
-// @ts-expect-error
-// @ts-ignore
-// @ts-nocheck
-// @ts-check
-```
-
-This rule lets you set which directive comments you want to allow in your codebase.
-
-## Options
-
-By default, only `@ts-check` is allowed, as it enables rather than suppresses errors.
-
-### `ts-expect-error`, `ts-ignore`, `ts-nocheck`, `ts-check` directives
-
-A value of `true` for a particular directive means that this rule will report if it finds any usage of said directive.
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts option='{ "ts-ignore": true }'
-if (false) {
-  // @ts-ignore: Unreachable code error
-  console.log('hello');
-}
-if (false) {
-  /* @ts-ignore: Unreachable code error */
-  console.log('hello');
-}
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts option='{ "ts-ignore": true }'
-if (false) {
-  // Compiler warns about unreachable code error
-  console.log('hello');
-}
-```
-
-</TabItem>
-</Tabs>
-
-### `allow-with-description`
-
-A value of `'allow-with-description'` for a particular directive means that this rule will report if it finds a directive that does not have a description following the directive (on the same line).
-
-For example, with `{ 'ts-expect-error': 'allow-with-description' }`:
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts option='{ "ts-expect-error": "allow-with-description" }'
-if (false) {
-  // @ts-expect-error
-  console.log('hello');
-}
-if (false) {
-  /* @ts-expect-error */
-  console.log('hello');
-}
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts option='{ "ts-expect-error": "allow-with-description" }'
-if (false) {
-  // @ts-expect-error: Unreachable code error
-  console.log('hello');
-}
-if (false) {
-  /* @ts-expect-error: Unreachable code error */
-  console.log('hello');
-}
-```
-
-</TabItem>
-</Tabs>
-### `descriptionFormat`
-
-{/* insert option description */}
-
-For each directive type, you can specify a custom format in the form of a regular expression. Only description that matches the pattern will be allowed.
-
-For example, with `{ 'ts-expect-error': { descriptionFormat: '^: TS\\d+ because .+$' } }`:
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-{/* prettier-ignore */}
-```ts option='{ "ts-expect-error": { "descriptionFormat": "^: TS\\\\d+ because .+$" } }'
-// @ts-expect-error: the library definition is wrong
-const a = doSomething('hello');
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-{/* prettier-ignore */}
-```ts option='{ "ts-expect-error": { "descriptionFormat": "^: TS\\\\d+ because .+$" } }'
-// @ts-expect-error: TS1234 because the library definition is wrong
-const a = doSomething('hello');
-```
-
-</TabItem>
-</Tabs>
-
-### `minimumDescriptionLength`
-
-{/* insert option description */}
-
-Use `minimumDescriptionLength` to set a minimum length for descriptions when using the `allow-with-description` option for a directive.
-
-For example, with `{ 'ts-expect-error': 'allow-with-description', minimumDescriptionLength: 10 }` the following pattern is:
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts option='{ "ts-expect-error": "allow-with-description", "minimumDescriptionLength": 10 }'
-if (false) {
-  // @ts-expect-error: TODO
-  console.log('hello');
-}
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts option='{ "ts-expect-error": "allow-with-description", "minimumDescriptionLength": 10 }'
-if (false) {
-  // @ts-expect-error The rationale for this override is described in issue #1337 on GitLab
-  console.log('hello');
-}
-```
-
-</TabItem>
-</Tabs>
-
-## When Not To Use It
-
-If your project or its dependencies were not architected with strong type safety in mind, it can be difficult to always adhere to proper TypeScript semantics.
-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
-
-- TypeScript [Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html)

package/docs/rules/ban-tslint-comment.mdx

@@ -1,45 +0,0 @@
----
-description: 'Disallow `// tslint:<rule-flag>` comments.'
----
-
-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/ban-tslint-comment** for documentation.
-
-Useful when migrating from TSLint to ESLint. Once TSLint has been removed, this rule helps locate TSLint annotations (e.g. `// tslint:disable`).
-
-> See the [TSLint rule flags docs](https://palantir.github.io/tslint/usage/rule-flags) for reference.
-
-## Examples
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts
-/* tslint:disable */
-/* tslint:enable */
-/* tslint:disable:rule1 rule2 rule3... */
-/* tslint:enable:rule1 rule2 rule3... */
-// tslint:disable-next-line
-someCode(); // tslint:disable-line
-// tslint:disable-next-line:rule1 rule2 rule3...
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts
-// This is a comment that just happens to mention tslint
-/* This is a multiline comment that just happens to mention tslint */
-someCode(); // This is a comment that just happens to mention tslint
-```
-
-</TabItem>
-</Tabs>
-
-## When Not To Use It
-
-If you are still using TSLint alongside ESLint.

package/docs/rules/ban-types.md

@@ -1,26 +0,0 @@
----
-displayed_sidebar: rulesSidebar
----
-
-:::danger Deprecated
-
-The old `ban-types` rule encompassed multiple areas of functionality, and so has been split into several rules.
-
-**[`no-restricted-types`](./no-restricted-types.mdx)** is the new rule for banning a configurable list of type names.
-It has no options enabled by default and is akin to rules like [`no-restricted-globals`](https://eslint.org/docs/latest/rules/no-restricted-globals), [`no-restricted-properties`](https://eslint.org/docs/latest/rules/no-restricted-properties), and [`no-restricted-syntax`](https://eslint.org/docs/latest/rules/no-restricted-syntax).
-
-The default options from `ban-types` are now covered by:
-
-- **[`no-empty-object-type`](./no-empty-object-type.mdx)**: banning the built-in `{}` type in confusing locations
-- **[`no-unsafe-function-type`](./no-unsafe-function-type.mdx)**: banning the built-in `Function`
-- **[`no-wrapper-object-types`](./no-wrapper-object-types.mdx)**: banning `Object` and built-in class wrappers such as `Number`
-
-`ban-types` itself is removed in typescript-eslint v8.
-See [Announcing typescript-eslint v8 Beta](/blog/announcing-typescript-eslint-v8-beta) for more details.
-:::
-
-<!-- This doc file has been left on purpose because `ban-types` is a well-known
-rule. This exists to help direct people to the replacement rules.
-
-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/docs/rules/block-spacing.md

@@ -1,15 +0,0 @@
----
-displayed_sidebar: rulesSidebar
----
-
-:::danger Deprecated
-
-This rule has been moved to the [ESLint stylistic plugin](https://eslint.style).
-See [#8072](https://github.com/typescript-eslint/typescript-eslint/issues/8072) and [#8074](https://github.com/typescript-eslint/typescript-eslint/issues/8074) for more information.
-
-:::
-
-<!-- This doc file has been left on purpose to help direct people to the stylistic plugin.
-
-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/docs/rules/brace-style.md

@@ -1,15 +0,0 @@
----
-displayed_sidebar: rulesSidebar
----
-
-:::danger Deprecated
-
-This rule has been moved to the [ESLint stylistic plugin](https://eslint.style).
-See [#8072](https://github.com/typescript-eslint/typescript-eslint/issues/8072) and [#8074](https://github.com/typescript-eslint/typescript-eslint/issues/8074) for more information.
-
-:::
-
-<!-- This doc file has been left on purpose to help direct people to the stylistic plugin.
-
-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/docs/rules/camelcase.md

@@ -1,15 +0,0 @@
----
-displayed_sidebar: rulesSidebar
----
-
-:::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/docs/rules/class-literal-property-style.mdx

@@ -1,112 +0,0 @@
----
-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/docs/rules/class-methods-use-this.mdx

@@ -1,135 +0,0 @@
----
-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.
-
-It adds support for ignoring `override` methods and/or methods on classes that implement an interface. It also supports auto-accessor properties.
-
-## 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`
-
-{/* insert option description */}
-
-Example of correct code when `ignoreOverrideMethods` is set to `true`:
-
-```ts option='{ "ignoreOverrideMethods": true }' showPlaygroundButton
-abstract class Base {
-  abstract method(): void;
-  abstract property: () => void;
-}
-
-class Derived extends Base {
-  override method() {}
-  override property = () => {};
-}
-```
-
-### `ignoreClassesThatImplementAnInterface`
-
-{/* insert option description */}
-
-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
-
-Note that this option applies to all class members, not just those defined in the interface.
-
-#### `true`
-
-Examples of code when `ignoreClassesThatImplementAnInterface` is set to `true`:
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts option='{ "ignoreClassesThatImplementAnInterface": true }' showPlaygroundButton
-class Standalone {
-  method() {}
-  property = () => {};
-}
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts option='{ "ignoreClassesThatImplementAnInterface": true }' showPlaygroundButton
-interface Base {
-  method(): void;
-}
-
-class Derived implements Base {
-  method() {}
-  property = () => {};
-}
-```
-
-</TabItem>
-</Tabs>
-
-#### `'public-fields'`
-
-Example of incorrect code when `ignoreClassesThatImplementAnInterface` is set to `'public-fields'`:
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts option='{ "ignoreClassesThatImplementAnInterface": "public-fields" }' showPlaygroundButton
-interface Base {
-  method(): void;
-}
-
-class Derived implements Base {
-  method() {}
-  property = () => {};
-
-  private privateMethod() {}
-  private privateProperty = () => {};
-
-  protected protectedMethod() {}
-  protected protectedProperty = () => {};
-}
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts option='{ "ignoreClassesThatImplementAnInterface": "public-fields" }'
-interface Base {
-  method(): void;
-}
-
-class Derived implements Base {
-  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/docs/rules/comma-dangle.md

@@ -1,15 +0,0 @@
----
-displayed_sidebar: rulesSidebar
----
-
-:::danger Deprecated
-
-This rule has been moved to the [ESLint stylistic plugin](https://eslint.style).
-See [#8072](https://github.com/typescript-eslint/typescript-eslint/issues/8072) and [#8074](https://github.com/typescript-eslint/typescript-eslint/issues/8074) for more information.
-
-:::
-
-<!-- This doc file has been left on purpose to help direct people to the stylistic plugin.
-
-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/docs/rules/comma-spacing.md

@@ -1,15 +0,0 @@
----
-displayed_sidebar: rulesSidebar
----
-
-:::danger Deprecated
-
-This rule has been moved to the [ESLint stylistic plugin](https://eslint.style).
-See [#8072](https://github.com/typescript-eslint/typescript-eslint/issues/8072) and [#8074](https://github.com/typescript-eslint/typescript-eslint/issues/8074) for more information.
-
-:::
-
-<!-- This doc file has been left on purpose to help direct people to the stylistic plugin.
-
-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/docs/rules/consistent-generic-constructors.mdx

@@ -1,87 +0,0 @@
----
-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'`
-
-{/* insert option description */}
-
-<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.