typescript-eslint · JoshuaKGoldberg · Mar 17, 2024 · Jan 7, 2024 · Jan 7, 2024 · Jan 7, 2024
diff --git a/CONTRIBUTORS.md b/CONTRIBUTORS.md
@@ -90,6 +90,7 @@ Thanks goes to these wonderful people:
     <td align="center"><a href="https://github.com/pablobirukov"><img src="https://avatars.githubusercontent.com/u/1861546?v=4&size=100" width="100px;" alt=""/><br /><sub><b>Pavel Birukov </b></sub></a></td>
     <td align="center"><a href="https://github.com/mightyiam"><img src="https://avatars.githubusercontent.com/u/635591?v=4&size=100" width="100px;" alt=""/><br /><sub><b>Shahar "Dawn" Or</b></sub></a></td>
     <td align="center"><a href="https://github.com/kirkwaiblinger"><img src="https://avatars.githubusercontent.com/u/53019676?v=4&size=100" width="100px;" alt=""/><br /><sub><b>kirkwaiblinger</b></sub></a></td>
+  </tr>
 </table>
 
 <!-- markdownlint-restore -->

diff --git a/docs/contributing/Pull_Requests.mdx b/docs/contributing/Pull_Requests.mdx
@@ -51,7 +51,7 @@ Within the body of your PR, make sure you reference the issue that you have work
 
 Must be one of the following:
 
-<!-- Keep this synchronized with /.github/workflows/semantic-pr-titles.yml -->
+{/* Keep this synchronized with /.github/workflows/semantic-pr-titles.yml */}
 
 - `docs` - if you only change documentation, and not shipped code
 - `feat` - for any new functionality additions

diff --git a/docs/packages/Parser.mdx b/docs/packages/Parser.mdx
@@ -90,7 +90,7 @@ More details can be found in the [TypeScript handbook's JSX docs](https://www.ty
 
 **NOTE:** this setting does not affect known file types (`.js`, `.mjs`, `.cjs`, `.jsx`, `.ts`, `.mts`, `.cts`, `.tsx`, `.json`) because the TypeScript compiler has its own internal handling for known file extensions.
 
-<!-- https://github.com/microsoft/TypeScript/blob/d6e483b8dabd8fd37c00954c3f2184bb7f1eb90c/src/compiler/utilities.ts#L6281-L6285 -->
+{/* https://github.com/microsoft/TypeScript/blob/d6e483b8dabd8fd37c00954c3f2184bb7f1eb90c/src/compiler/utilities.ts#L6281-L6285 */}
 
 The exact behavior is as follows:
 

diff --git a/packages/eslint-plugin/docs/rules/TEMPLATE.md b/packages/eslint-plugin/docs/rules/TEMPLATE.md
@@ -2,6 +2,9 @@
 description: '<Description from rule metadata here>'
 ---
 
+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/RULE_NAME_REPLACEME** for documentation.
@@ -10,20 +13,23 @@ description: '<Description from rule metadata here>'
 
 To fill out: tell us more about this rule.
 
-<!--tabs-->
-
-### ❌ Incorrect
+<Tabs>
+<TabItem value="❌ Incorrect">
 
 ```ts
 // To fill out: incorrect code
 ```
 
-### ✅ Correct
+</TabItem>
+<TabItem value="✅ Correct">
 
 ```ts
 // To fill out: correct code
 ```
 
+</TabItem>
+</Tabs>
+
 ## When Not To Use It
 
 To fill out: why wouldn't you want to use this rule?

diff --git a/...ocs/rules/adjacent-overload-signatures.md → ...cs/rules/adjacent-overload-signatures.mdx b/...ocs/rules/adjacent-overload-signatures.md → ...cs/rules/adjacent-overload-signatures.mdx
@@ -2,6 +2,9 @@
 description: 'Require that function overload signatures be consecutive.'
 ---
 
+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/adjacent-overload-signatures** for documentation.
@@ -12,9 +15,8 @@ If Signatures placed elsewhere in the type are easier to be missed by future dev
 
 ## Examples
 
-<!--tabs-->
-
-### ❌ Incorrect
+<Tabs>
+<TabItem value="❌ Incorrect">
 
 ```ts
 declare namespace Foo {
@@ -51,7 +53,8 @@ export function bar(): void;
 export function foo(sn: string | number): void;
 ```
 
-### ✅ Correct
+</TabItem>
+<TabItem value="✅ Correct">
 
 ```ts
 declare namespace Foo {
@@ -88,6 +91,9 @@ export function foo(n: number): void;
 export function foo(sn: string | number): void;
 ```
 
+</TabItem>
+</Tabs>
+
 ## When Not To Use It
 
 It can sometimes be useful to place overload signatures alongside other meaningful parts of a type.
@@ -96,4 +102,4 @@ You might consider using [ESLint disable comments](https://eslint.org/docs/lates
 
 ## Related To
 
-- [`unified-signatures`](./unified-signatures.md)
+- [`unified-signatures`](./unified-signatures.mdx)
diff --git a/...es/eslint-plugin/docs/rules/array-type.md → ...s/eslint-plugin/docs/rules/array-type.mdx b/...es/eslint-plugin/docs/rules/array-type.md → ...s/eslint-plugin/docs/rules/array-type.mdx
@@ -2,6 +2,9 @@
 description: 'Require consistently using either `T[]` or `Array<T>` for arrays.'
 ---
 
+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/array-type** for documentation.
@@ -18,50 +21,55 @@ The default config will enforce that all mutable and readonly arrays use the `'a
 
 Always use `T[]` or `readonly T[]` for all array types.
 
-<!--tabs-->
-
-#### ❌ Incorrect
+<Tabs>
+<TabItem value="❌ Incorrect">
 
 ```ts option='{ "default": "array" }'
 const x: Array<string> = ['a', 'b'];
 const y: ReadonlyArray<string> = ['a', 'b'];
 ```
 
-#### ✅ Correct
+</TabItem>
+<TabItem value="✅ Correct">
 
 ```ts option='{ "default": "array" }'
 const x: string[] = ['a', 'b'];
 const y: readonly string[] = ['a', 'b'];
 ```
 
+</TabItem>
+</Tabs>
+
 ### `"generic"`
 
 Always use `Array<T>` or `ReadonlyArray<T>` for all array types.
 
-<!--tabs-->
-
-#### ❌ Incorrect
+<Tabs>
+<TabItem value="❌ Incorrect">
 
 ```ts option='{ "default": "generic" }'
 const x: string[] = ['a', 'b'];
 const y: readonly string[] = ['a', 'b'];
 ```
 
-#### ✅ Correct
+</TabItem>
+<TabItem value="✅ Correct">
 
 ```ts option='{ "default": "generic" }'
 const x: Array<string> = ['a', 'b'];
 const y: ReadonlyArray<string> = ['a', 'b'];
 ```
 
+</TabItem>
+</Tabs>
+
 ### `"array-simple"`
 
 Use `T[]` or `readonly T[]` for simple types (i.e. types which are just primitive names or type references).
 Use `Array<T>` or `ReadonlyArray<T>` for all other types (union types, intersection types, object types, function types, etc).
 
-<!--tabs-->
-
-#### ❌ Incorrect
+<Tabs>
+<TabItem value="❌ Incorrect">
 
 ```ts option='{ "default": "array-simple" }'
 const a: (string | number)[] = ['a', 'b'];
@@ -72,7 +80,8 @@ const e: Array<string> = ['a', 'b'];
 const f: ReadonlyArray<string> = ['a', 'b'];
 ```
 
-#### ✅ Correct
+</TabItem>
+<TabItem value="✅ Correct">
 
 ```ts option='{ "default": "array-simple" }'
 const a: Array<string | number> = ['a', 'b'];
@@ -83,6 +92,9 @@ const e: string[] = ['a', 'b'];
 const f: readonly string[] = ['a', 'b'];
 ```
 
+</TabItem>
+</Tabs>
+
 ## Combination Matrix
 
 This matrix lists all possible option combinations and their expected results for different types of Arrays.

diff --git a/...slint-plugin/docs/rules/await-thenable.md → ...lint-plugin/docs/rules/await-thenable.mdx b/...slint-plugin/docs/rules/await-thenable.md → ...lint-plugin/docs/rules/await-thenable.mdx
@@ -2,6 +2,9 @@
 description: 'Disallow awaiting a value that is not a Thenable.'
 ---
 
+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/await-thenable** for documentation.
@@ -14,9 +17,8 @@ While doing so is valid JavaScript, it is often a programmer error, such as forg
 
 ## Examples
 
-<!--tabs-->
-
-### ❌ Incorrect
+<Tabs>
+<TabItem value="❌ Incorrect">
 
 ```ts
 await 'value';
@@ -25,7 +27,8 @@ const createValue = () => 'value';
 await createValue();
 ```
 
-### ✅ Correct
+</TabItem>
+<TabItem value="✅ Correct">
 
 ```ts
 await Promise.resolve('value');
@@ -34,6 +37,9 @@ const createValue = async () => 'value';
 await createValue();
 ```
 
+</TabItem>
+</Tabs>
+
 ## When Not To Use It
 
 If you want to allow code to `await` non-Promise values.

diff --git a/...slint-plugin/docs/rules/ban-ts-comment.md → ...lint-plugin/docs/rules/ban-ts-comment.mdx b/...slint-plugin/docs/rules/ban-ts-comment.md → ...lint-plugin/docs/rules/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.