typescript-eslint · JoshuaKGoldberg · Oct 15, 2024 · Sep 3, 2024 · Sep 20, 2024 · Sep 20, 2024
diff --git a/packages/eslint-plugin/docs/rules/ban-ts-comment.mdx b/packages/eslint-plugin/docs/rules/ban-ts-comment.mdx
@@ -97,6 +97,8 @@ if (false) {
 </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 .+$' } }`:
@@ -124,6 +126,8 @@ const a = doSomething('hello');
 
 ### `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:

diff --git a/packages/eslint-plugin/docs/rules/class-methods-use-this.mdx b/packages/eslint-plugin/docs/rules/class-methods-use-this.mdx
@@ -31,6 +31,8 @@ const defaultOptions: Options = {
 
 ### `ignoreOverrideMethods`
 
+{/* insert option description */}
+
 Makes the rule ignore any class member explicitly marked with `override`.
 
 Example of a correct code when `ignoreOverrideMethods` is set to `true`:
@@ -44,7 +46,8 @@ class X {
 
 ### `ignoreClassesThatImplementAnInterface`
 
-Makes the rule ignore class members that are defined within a class that `implements` a type.
+{/* insert option description */}
+
 If specified, it can be either:
 
 - `true`: Ignore all classes that implement an interface

diff --git a/packages/eslint-plugin/docs/rules/consistent-generic-constructors.mdx b/packages/eslint-plugin/docs/rules/consistent-generic-constructors.mdx
@@ -27,10 +27,12 @@ Keeping to one side consistently improve code readability.
 
 ## 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'` _(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`
+### `'constructor'`
+
+{/* insert option description */}
 
 <Tabs>
 <TabItem value="❌ Incorrect">
@@ -54,7 +56,7 @@ const set: Set<string> = new Set<string>();
 </TabItem>
 </Tabs>
 
-### `type-annotation`
+### `'type-annotation'`
 
 <Tabs>
 <TabItem value="❌ Incorrect">

diff --git a/packages/eslint-plugin/docs/rules/consistent-indexed-object-style.mdx b/packages/eslint-plugin/docs/rules/consistent-indexed-object-style.mdx
@@ -27,10 +27,12 @@ Using one declaration form consistently improves code readability.
 
 ## Options
 
-- `"record"` _(default)_: only allow the `Record` type.
-- `"index-signature"`: only allow index signatures.
+- `'record'` _(default)_: only allow the `Record` type.
+- `'index-signature'`: only allow index signatures.
 
-### `record`
+### `'record'`
+
+{/* insert option description */}
 
 <Tabs>
 <TabItem value="❌ Incorrect">
@@ -55,7 +57,7 @@ type Foo = Record<string, unknown>;
 </TabItem>
 </Tabs>
 
-### `index-signature`
+### `'index-signature'`
 
 <Tabs>
 <TabItem value="❌ Incorrect">

diff --git a/packages/eslint-plugin/docs/rules/consistent-type-assertions.mdx b/packages/eslint-plugin/docs/rules/consistent-type-assertions.mdx
@@ -30,7 +30,9 @@ Examples of them include `let x = "hello" as const;` and `let x = <const>"hello"
 
 ### `assertionStyle`
 
-The expected assertion style to enforce. Valid values for `assertionStyle` are:
+{/* insert option description */}
+
+Valid values for `assertionStyle` are:
 
 - `as` will enforce that you always use `... as foo`.
 - `angle-bracket` will enforce that you always use `<foo>...`
@@ -42,7 +44,7 @@ Some codebases like to go for an extra level of type safety, and ban assertions
 
 ### `objectLiteralTypeAssertions`
 
-Whether to always prefer type declarations for object literals used as variable initializers, rather than type assertions.
+{/* insert option description */}
 
 For example, this would 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.

diff --git a/packages/eslint-plugin/docs/rules/consistent-type-definitions.mdx b/packages/eslint-plugin/docs/rules/consistent-type-definitions.mdx
@@ -30,10 +30,12 @@ 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'` _(default)_: enforce using `interface`s for object type definitions.
+- `'type'`: enforce using `type`s for object type definitions.
 
-### `interface`
+### `'interface'`
+
+{/* insert option description */}
 
 <Tabs>
 <TabItem value="❌ Incorrect">
@@ -57,7 +59,9 @@ interface T {
 </TabItem>
 </Tabs>
 
-### `type`
+### `'type'`
+
+{/* insert option description */}
 
 <Tabs>
 <TabItem value="❌ Incorrect">

diff --git a/packages/eslint-plugin/docs/rules/consistent-type-exports.mdx b/packages/eslint-plugin/docs/rules/consistent-type-exports.mdx
@@ -54,7 +54,8 @@ export type { ButtonProps };
 
 ### `fixMixedExportsWithInlineTypeSpecifier`
 
-Whether the rule will autofix "mixed" export cases using TS inline type specifiers.
+{/* insert option description */}
+
 If you are using a TypeScript version less than 4.5, then you will not be able to use this option.
 
 For example the following code:

diff --git a/packages/eslint-plugin/docs/rules/consistent-type-imports.mdx b/packages/eslint-plugin/docs/rules/consistent-type-imports.mdx
@@ -18,7 +18,9 @@ This allows transpilers to drop imports without knowing the types of the depende
 
 ### `prefer`
 
-The expected import kind for type-only imports. Valid values for `prefer` are:
+{/* insert option description */}
+
+Valid values for `prefer` are:
 
 - `type-imports` will enforce that you always use `import type Foo from '...'` except referenced by metadata of decorators. It is the default.
 - `no-type-imports` will enforce that you always use `import Foo from '...'`.
@@ -43,7 +45,9 @@ const x: Bar = 1;
 
 ### `fixStyle`
 
-The expected type modifier to be added when an import is detected as used only in the type position. Valid values for `fixStyle` are:
+{/* insert option description */}
+
+Valid values for `fixStyle` are:
 
 - `separate-type-imports` will add the type keyword after the import keyword `import type { A } from '...'`. It is the default.
 - `inline-type-imports` will inline the type keyword `import { type A } from '...'` and is only available in TypeScript 4.5 and onwards. See [documentation here](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-5.html#type-modifiers-on-import-names 'TypeScript 4.5 documentation on type modifiers and import names').
@@ -83,8 +87,7 @@ const x: Bar = 1;
 
 ### `disallowTypeAnnotations`
 
-Whether to disallow type imports in type annotations (`import()`).
-Default is `true`.
+{/* insert option description */}
 
 Examples of **incorrect** code with `{disallowTypeAnnotations: true}`:
 

diff --git a/packages/eslint-plugin/docs/rules/dot-notation.mdx b/packages/eslint-plugin/docs/rules/dot-notation.mdx
@@ -38,7 +38,8 @@ If the TypeScript compiler option `noPropertyAccessFromIndexSignature` is set to
 
 ### `allowPrivateClassPropertyAccess`
 
-Whether to allow accessing class members marked as `private` with array notation.
+{/* insert option description */}
+
 This can be useful because TypeScript will report a type error on dot notation but not array notation.
 
 Example of a correct code when `allowPrivateClassPropertyAccess` is set to `true`:
@@ -54,7 +55,8 @@ x['priv_prop'] = 123;
 
 ### `allowProtectedClassPropertyAccess`
 
-Whether to allow accessing class members marked as `protected` with array notation.
+{/* insert option description */}
+
 This can be useful because TypeScript will report a type error on dot notation but not array notation.
 
 Example of a correct code when `allowProtectedClassPropertyAccess` is set to `true`:
@@ -70,7 +72,7 @@ x['protected_prop'] = 123;
 
 ### `allowIndexSignaturePropertyAccess`
 
-Whether to allow accessing properties matching an index signature with array notation.
+{/* insert option description */}
 
 Example of correct code when `allowIndexSignaturePropertyAccess` is set to `true`:
 

diff --git a/packages/eslint-plugin/docs/rules/explicit-function-return-type.mdx b/packages/eslint-plugin/docs/rules/explicit-function-return-type.mdx
@@ -98,6 +98,8 @@ If you are working on a codebase within which you lint non-TypeScript code (i.e.
 
 ### `allowExpressions`
 
+{/* insert option description */}
+
 Examples of code for this rule with `{ allowExpressions: true }`:
 
 <Tabs>
@@ -127,6 +129,8 @@ const foo = arr.map(i => i * i);
 
 ### `allowTypedFunctionExpressions`
 
+{/* insert option description */}
+
 Examples of code for this rule with `{ allowTypedFunctionExpressions: true }`:
 
 <Tabs>
@@ -188,6 +192,8 @@ functionWithObjectArg({
 
 ### `allowHigherOrderFunctions`
 
+{/* insert option description */}
+
 Examples of code for this rule with `{ allowHigherOrderFunctions: true }`:
 
 <Tabs>
@@ -217,6 +223,8 @@ function fn() {
 
 ### `allowDirectConstAssertionInArrowFunctions`
 
+{/* insert option description */}
+
 Examples of code for this rule with `{ allowDirectConstAssertionInArrowFunctions: true }`:
 
 <Tabs>
@@ -240,6 +248,8 @@ const func = () => x as const;
 
 ### `allowConciseArrowFunctionExpressionsStartingWithVoid`
 
+{/* insert option description */}
+
 Examples of code for this rule with `{ allowConciseArrowFunctionExpressionsStartingWithVoid: true }`:
 
 <Tabs>
@@ -265,6 +275,8 @@ var log = (message: string) => void console.log(message);
 
 ### `allowFunctionsWithoutTypeParameters`
 
+{/* insert option description */}
+
 Examples of code for this rule with `{ allowFunctionsWithoutTypeParameters: true }`:
 
 <Tabs>
@@ -300,6 +312,8 @@ const allowedArrow = (x: string) => x;
 
 ### `allowedNames`
 
+{/* insert option description */}
+
 You may pass function/method names you would like this rule to ignore, like so:
 
 ```json
@@ -315,6 +329,8 @@ You may pass function/method names you would like this rule to ignore, like so:
 
 ### `allowIIFEs`
 
+{/* insert option description */}
+
 Examples of code for this rule with `{ allowIIFEs: true }`:
 
 <Tabs>

diff --git a/packages/eslint-plugin/docs/rules/explicit-member-accessibility.mdx b/packages/eslint-plugin/docs/rules/explicit-member-accessibility.mdx
@@ -49,6 +49,8 @@ If you are working on a codebase within which you lint non-TypeScript code (i.e.
 
 ### `accessibility`
 
+{/* insert option description */}
+
 This rule in its default state requires no configuration and will enforce that every class member has an accessibility modifier. If you would like to allow for some implicit public members then you have the following options:
 
 ```jsonc
@@ -169,6 +171,8 @@ class Animal {
 
 ### `overrides`
 
+{/* insert option description */}
+
 There are three ways in which an override can be used.
 
 - To disallow the use of public on a given member.
@@ -317,8 +321,9 @@ class Animal {
 
 ### `ignoredMethodNames`
 
-Specific method names that may be ignored.
-Note that this option does not care for the context, and will ignore every method with these names, which could lead to it missing some cases. You should use this sparingly.
+{/* insert option description */}
+
+Note that this option does not care about context, and will ignore every method with these names, which could lead to it missing some cases. You should use this sparingly.
 e.g. `[ { ignoredMethodNames: ['specificMethod', 'whateverMethod'] } ]`
 
 ```ts option='{ "ignoredMethodNames": ["specificMethod", "whateverMethod"] }' showPlaygroundButton