@typescript-eslint/eslint-plugin 7.2.1-alpha.2 → 7.2.1-alpha.3

package/docs/rules/{ban-ts-comment.md → ban-ts-comment.mdx}

@@ -2,6 +2,9 @@
 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.
@@ -29,9 +32,8 @@ By default, only `@ts-check` is allowed, as it enables rather than suppresses er
 
 A value of `true` for a particular directive means that this rule will report if it finds any usage of said directive.
 
-<!--tabs-->
-
-#### ❌ Incorrect
+<Tabs>
+<TabItem value="❌ Incorrect">
 
 ```ts option='{ "ts-ignore": true }'
 if (false) {
@@ -46,7 +48,8 @@ if (false) {
 }
 ```
 
-#### ✅ Correct
+</TabItem>
+<TabItem value="✅ Correct">
 
 ```ts option='{ "ts-ignore": true }'
 if (false) {
@@ -55,15 +58,17 @@ if (false) {
 }
 ```
 
+</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-->
-
-#### ❌ Incorrect
+<Tabs>
+<TabItem value="❌ Incorrect">
 
 ```ts option='{ "ts-expect-error": "allow-with-description" }'
 if (false) {
@@ -76,7 +81,8 @@ if (false) {
 }
 ```
 
-#### ✅ Correct
+</TabItem>
+<TabItem value="✅ Correct">
 
 ```ts option='{ "ts-expect-error": "allow-with-description" }'
 if (false) {
@@ -91,39 +97,43 @@ if (false) {
 }
 ```
 
+</TabItem>
+</Tabs>
 ### `descriptionFormat`
 
 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-->
+<Tabs>
+<TabItem value="❌ Incorrect">
 
-#### ❌ Incorrect
-
-<!-- prettier-ignore -->
+{/* prettier-ignore */}
 ```ts option='{ "ts-expect-error": { "descriptionFormat": "^: TS\\\\d+ because .+$" } }'
 // @ts-expect-error: the library definition is wrong
 const a = doSomething('hello');
 ```
 
-#### ✅ Correct
+</TabItem>
+<TabItem value="✅ Correct">
 
-<!-- prettier-ignore -->
+{/* 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`
 
 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-->
-
-#### ❌ Incorrect
+<Tabs>
+<TabItem value="❌ Incorrect">
 
 ```ts option='{ "ts-expect-error": "allow-with-description", "minimumDescriptionLength": 10 }'
 if (false) {
@@ -132,7 +142,8 @@ if (false) {
 }
 ```
 
-#### ✅ Correct
+</TabItem>
+<TabItem value="✅ Correct">
 
 ```ts option='{ "ts-expect-error": "allow-with-description", "minimumDescriptionLength": 10 }'
 if (false) {
@@ -141,6 +152,9 @@ if (false) {
 }
 ```
 
+</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.

package/docs/rules/{ban-tslint-comment.md → ban-tslint-comment.mdx}

@@ -2,6 +2,9 @@
 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.
@@ -12,9 +15,8 @@ Useful when migrating from TSLint to ESLint. Once TSLint has been removed, this
 
 ## Examples
 
-<!--tabs-->
-
-### ❌ Incorrect
+<Tabs>
+<TabItem value="❌ Incorrect">
 
 ```ts
 /* tslint:disable */
@@ -26,7 +28,8 @@ someCode(); // tslint:disable-line
 // tslint:disable-next-line:rule1 rule2 rule3...
 ```
 
-### ✅ Correct
+</TabItem>
+<TabItem value="✅ Correct">
 
 ```ts
 // This is a comment that just happens to mention tslint
@@ -34,6 +37,9 @@ someCode(); // tslint:disable-line
 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 → ban-types.mdx}

@@ -2,6 +2,9 @@
 description: 'Disallow certain types.'
 ---
 
+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-types** for documentation.
@@ -16,9 +19,8 @@ Note that it does not ban the corresponding runtime objects from being used.
 
 Examples of code with the default options:
 
-<!--tabs-->
-
-### ❌ Incorrect
+<Tabs>
+<TabItem value="❌ Incorrect">
 
 ```ts
 // use lower-case primitives for consistency
@@ -39,7 +41,8 @@ const curly1: {} = 1;
 const curly2: {} = { a: 'string' };
 ```
 
-### ✅ Correct
+</TabItem>
+<TabItem value="✅ Correct">
 
 ```ts
 // use lower-case primitives for consistency
@@ -60,6 +63,9 @@ const curly1: number = 1;
 const curly2: Record<'a', string> = { a: 'string' };
 ```
 
+</TabItem>
+</Tabs>
+
 ## Options
 
 The default options provide a set of "best practices", intended to provide safety and standardization in your codebase:
@@ -75,7 +81,7 @@ The default options provide a set of "best practices", intended to provide safet
 <details>
 <summary>Default Options</summary>
 
-<!-- Inject default options -->
+{/* Inject default options */}
 
 </details>
 

package/docs/rules/{block-spacing.md → block-spacing.mdx}

@@ -2,6 +2,9 @@
 description: 'Disallow or enforce spaces inside of blocks after opening block and before closing block.'
 ---
 
+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/block-spacing** for documentation.

package/docs/rules/{brace-style.md → brace-style.mdx}

@@ -2,6 +2,9 @@
 description: 'Enforce consistent brace style for blocks.'
 ---
 
+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/brace-style** for documentation.

package/docs/rules/camelcase.md

@@ -1,13 +1,11 @@
 :::danger Deprecated
 
-This rule has been deprecated in favour of the [`naming-convention`](./naming-convention.md) rule.
+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
+<!-- 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.
--->
+so end-users will only be able to get to this page from the search bar. -->

package/docs/rules/{class-literal-property-style.md → class-literal-property-style.mdx}

@@ -2,6 +2,9 @@
 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.
@@ -15,10 +18,8 @@ By default this rule prefers the `fields` style as it means JS doesn't have to s
 ## 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"`
@@ -27,9 +28,8 @@ This style checks for any getter methods that return literal values, and require
 
 Examples of code with the `fields` style:
 
-<!--tabs-->
-
-#### ❌ Incorrect
+<Tabs>
+<TabItem value="❌ Incorrect">
 
 ```ts option='"fields"'
 class Mx {
@@ -43,7 +43,8 @@ class Mx {
 }
 ```
 
-#### ✅ Correct
+</TabItem>
+<TabItem value="✅ Correct">
 
 ```ts option='"fields"'
 class Mx {
@@ -60,17 +61,19 @@ class Mx {
 }
 ```
 
+</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.md) rule,
+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-->
-
-#### ❌ Incorrect
+<Tabs>
+<TabItem value="❌ Incorrect">
 
 ```ts option='"getters"'
 class Mx {
@@ -80,7 +83,8 @@ class Mx {
 }
 ```
 
-#### ✅ Correct
+</TabItem>
+<TabItem value="✅ Correct">
 
 ```ts option='"getters"'
 class Mx {
@@ -100,6 +104,9 @@ class Mx {
 }
 ```
 
+</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.md → class-methods-use-this.mdx}

@@ -2,6 +2,9 @@
 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.
@@ -51,7 +54,7 @@ It's important to note that this option does not only apply to members defined i
 
 #### `true`
 
-Example of a correct code when `ignoreClassesThatImplementAnInterface` is set to `true`:
+Example of correct code when `ignoreClassesThatImplementAnInterface` is set to `true`:
 
 ```ts option='{ "ignoreClassesThatImplementAnInterface": true }' showPlaygroundButton
 class X implements Y {
@@ -62,11 +65,10 @@ class X implements Y {
 
 #### `'public-fields'`
 
-Example of a incorrect code when `ignoreClassesThatImplementAnInterface` is set to `'public-fields'`:
-
-<!--tabs-->
+Example of incorrect code when `ignoreClassesThatImplementAnInterface` is set to `'public-fields'`:
 
-##### ❌ Incorrect
+<Tabs>
+<TabItem value="❌ Incorrect">
 
 ```ts
 class X implements Y {
@@ -81,7 +83,8 @@ class X implements Y {
 }
 ```
 
-##### ✅ Correct
+</TabItem>
+<TabItem value="✅ Correct">
 
 ```ts
 class X implements Y {
@@ -90,6 +93,9 @@ class X implements Y {
 }
 ```
 
+</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.

package/docs/rules/{comma-dangle.md → comma-dangle.mdx}

@@ -2,6 +2,9 @@
 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.

package/docs/rules/{comma-spacing.md → comma-spacing.mdx}

@@ -2,6 +2,9 @@
 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.

package/docs/rules/{consistent-generic-constructors.md → consistent-generic-constructors.mdx}

@@ -2,6 +2,9 @@
 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.
@@ -29,16 +32,16 @@ Keeping to one side consistently improve code readability.
 
 ### `constructor`
 
-<!--tabs-->
-
-#### ❌ Incorrect
+<Tabs>
+<TabItem value="❌ Incorrect">
 
 ```ts option='"constructor"'
 const map: Map<string, number> = new Map();
 const set: Set<string> = new Set();
 ```
 
-#### ✅ Correct
+</TabItem>
+<TabItem value="✅ Correct">
 
 ```ts option='"constructor"'
 const map = new Map<string, number>();
@@ -48,18 +51,21 @@ const set = new Set();
 const set: Set<string> = new Set<string>();
 ```
 
-### `type-annotation`
+</TabItem>
+</Tabs>
 
-<!--tabs-->
+### `type-annotation`
 
-#### ❌ Incorrect
+<Tabs>
+<TabItem value="❌ Incorrect">
 
 ```ts option='"type-annotation"'
 const map = new Map<string, number>();
 const set = new Set<string>();
 ```
 
-#### ✅ Correct
+</TabItem>
+<TabItem value="✅ Correct">
 
 ```ts option='"type-annotation"'
 const map: Map<string, number> = new Map();
@@ -68,6 +74,9 @@ 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.

package/docs/rules/{consistent-indexed-object-style.md → consistent-indexed-object-style.mdx}

@@ -2,6 +2,9 @@
 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.
@@ -29,9 +32,8 @@ Keeping to one declaration form consistently improve code readability.
 
 ### `record`
 
-<!--tabs-->
-
-#### ❌ Incorrect
+<Tabs>
+<TabItem value="❌ Incorrect">
 
 ```ts option='"record"'
 interface Foo {
@@ -43,23 +45,27 @@ type Foo = {
 };
 ```
 
-#### ✅ Correct
+</TabItem>
+<TabItem value="✅ Correct">
 
 ```ts option='"record"'
 type Foo = Record<string, unknown>;
 ```
 
-### `index-signature`
+</TabItem>
+</Tabs>
 
-<!--tabs-->
+### `index-signature`
 
-#### ❌ Incorrect
+<Tabs>
+<TabItem value="❌ Incorrect">
 
 ```ts option='"index-signature"'
 type Foo = Record<string, unknown>;
 ```
 
-#### ✅ Correct
+</TabItem>
+<TabItem value="✅ Correct">
 
 ```ts option='"index-signature"'
 interface Foo {
@@ -71,6 +77,9 @@ type Foo = {
 };
 ```
 
+</TabItem>
+</Tabs>
+
 ## When Not To Use It
 
 This rule is purely a stylistic rule for maintaining consistency in your project.

package/docs/rules/{consistent-return.md → consistent-return.mdx}

@@ -2,6 +2,9 @@
 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.
@@ -9,9 +12,8 @@ description: 'Require `return` statements to either always or never specify valu
 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-->
-
-### ❌ Incorrect
+<Tabs>
+<TabItem value="❌ Incorrect">
 
 ```ts
 function foo(): undefined {}
@@ -26,7 +28,8 @@ async function baz(flag: boolean): Promise<undefined> {
 }
 ```
 
-### ✅ Correct
+</TabItem>
+<TabItem value="✅ Correct">
 
 ```ts
 function foo(): void {}
@@ -40,3 +43,6 @@ async function baz(flag: boolean): Promise<void | number> {
   return;
 }
 ```
+
+</TabItem>
+</Tabs>

package/docs/rules/{consistent-type-assertions.md → consistent-type-assertions.mdx}

@@ -2,6 +2,9 @@
 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.
@@ -49,9 +52,8 @@ Assertions to `any` are also ignored by this option.
 
 Examples of code for `{ assertionStyle: 'as', objectLiteralTypeAssertions: 'never' }`:
 
-<!--tabs-->
-
-#### ❌ Incorrect
+<Tabs>
+<TabItem value="❌ Incorrect">
 
 ```ts option='{ "assertionStyle": "as", "objectLiteralTypeAssertions": "never" }'
 const x = { foo: 1 } as T;
@@ -61,7 +63,8 @@ function bar() {
 }
 ```
 
-#### ✅ Correct
+</TabItem>
+<TabItem value="✅ Correct">
 
 ```ts option='{ "assertionStyle": "as", "objectLiteralTypeAssertions": "never" }'
 const x: T = { foo: 1 };
@@ -73,13 +76,13 @@ function bar(): T {
 }
 ```
 
-<!--/tabs-->
+</TabItem>
+</Tabs>
 
 Examples of code for `{ assertionStyle: 'as', objectLiteralTypeAssertions: 'allow-as-parameter' }`:
 
-<!--tabs-->
-
-#### ❌ Incorrect
+<Tabs>
+<TabItem value="❌ Incorrect">
 
 ```ts option='{ "assertionStyle": "as", "objectLiteralTypeAssertions": "allow-as-parameter" }'
 const x = { foo: 1 } as T;
@@ -89,7 +92,8 @@ function bar() {
 }
 ```
 
-#### ✅ Correct
+</TabItem>
+<TabItem value="✅ Correct">
 
 ```tsx option='{ "assertionStyle": "as", "objectLiteralTypeAssertions": "allow-as-parameter" }'
 const x: T = { foo: 1 };
@@ -103,7 +107,8 @@ function bar() {
 const foo = <Foo props={{ bar: 1 } as Bar} />;
 ```
 
-<!--/tabs-->
+</TabItem>
+</Tabs>
 
 ## When Not To Use It