xo 0.51.0 → 0.52.2

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/ban-ts-comment.md

@@ -1,6 +1,10 @@
-# `ban-ts-comment`
+---
+description: 'Disallow `@ts-<directive>` comments or require descriptions after directive.'
+---
 
-Disallows `@ts-<directive>` comments or requires descriptions after directive.
+> 🛑 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.
@@ -17,32 +21,10 @@ The directive comments supported by TypeScript are:
 ## Rule Details
 
 This rule lets you set which directive comments you want to allow in your codebase.
-By default, only `@ts-check` is allowed, as it enables rather than suppresses errors.
-
-The configuration looks like this:
 
-```ts
-type DirectiveConfig =
-  | boolean
-  | 'allow-with-description'
-  | { descriptionFormat: string };
-
-interface Options {
-  'ts-expect-error'?: DirectiveConfig;
-  'ts-ignore'?: DirectiveConfig;
-  'ts-nocheck'?: DirectiveConfig;
-  'ts-check'?: DirectiveConfig;
-  minimumDescriptionLength?: number;
-}
+## Options
 
-const defaultOptions: Options = {
-  'ts-expect-error': 'allow-with-description',
-  'ts-ignore': true,
-  'ts-nocheck': true,
-  'ts-check': false,
-  minimumDescriptionLength: 3,
-};
-```
+By default, only `@ts-check` is allowed, as it enables rather than suppresses errors.
 
 ### `ts-expect-error`, `ts-ignore`, `ts-nocheck`, `ts-check` directives
 

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/ban-tslint-comment.md

@@ -1,6 +1,10 @@
-# `ban-tslint-comment`
+---
+description: 'Disallow `// tslint:<rule-flag>` comments.'
+---
 
-Disallows `// tslint:<rule-flag>` comments.
+> 🛑 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`).
 
@@ -30,19 +34,6 @@ someCode(); // tslint:disable-line
 someCode(); // This is a comment that just happens to mention tslint
 ```
 
-## Options
-
-```jsonc
-// .eslintrc.json
-{
-  "rules": {
-    "@typescript-eslint/ban-tslint-comment": "warn"
-  }
-}
-```
-
-This rule is not configurable.
-
 ## When Not To Use It
 
 If you are still using TSLint.

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/ban-types.md

@@ -1,8 +1,12 @@
-# `ban-types`
+---
+description: 'Disallow certain types.'
+---
 
-Disallows certain types.
+> 🛑 This file is source code, not the primary documentation location! 🛑
+>
+> See **https://typescript-eslint.io/rules/ban-types** for documentation.
 
-Some builtin types have aliases, some types are considered dangerous or harmful.
+Some built-in types have aliases, while some types are considered dangerous or harmful.
 It's often a good idea to ban certain types to help with consistency and safety.
 
 ## Rule Details
@@ -10,72 +14,53 @@ It's often a good idea to ban certain types to help with consistency and safety.
 This rule bans specific types and can suggest alternatives.
 Note that it does not ban the corresponding runtime objects from being used.
 
-## Options
-
-```ts
-type Options = {
-  types?: {
-    [typeName: string]:
-      | false
-      | string
-      | {
-          message: string;
-          fixWith?: string;
-        };
-  };
-  extendDefaults?: boolean;
-};
-```
-
-The rule accepts a single object as options.
-
-### `types`
+Examples of code with the default options:
 
-An object whose keys are the types you want to ban, and the values are error messages.
+<!--tabs-->
 
-The type can either be a type name literal (`Foo`), a type name with generic parameter instantiation(s) (`Foo<Bar>`), the empty object literal (`{}`), or the empty tuple type (`[]`).
+### ❌ Incorrect
 
-The values can be:
+```ts
+// use lower-case primitives for consistency
+const str: String = 'foo';
+const bool: Boolean = true;
+const num: Number = 1;
+const symb: Symbol = Symbol('foo');
+const bigInt: BigInt = 1n;
 
-- A string, which is the error message to be reported; or
-- `false` to specifically un-ban this type (useful when you are using `extendDefaults`); or
-- An object with the following properties:
-  - `message: string` - the message to display when the type is matched.
-  - `fixWith?: string` - a string to replace the banned type with when the fixer is run. If this is omitted, no fix will be done.
+// use a proper function type
+const func: Function = () => 1;
 
-### `extendDefaults`
+// use safer object types
+const lowerObj: Object = {};
+const capitalObj: Object = { a: 'string' };
 
-If you're specifying custom `types`, you can set this to `true` to extend the default `types` configuration. This is a convenience option to save you copying across the defaults when adding another type.
+const curly1: {} = 1;
+const curly2: {} = { a: 'string' };
+```
 
-If this is `false`, the rule will _only_ use the types defined in your configuration.
+### ✅ Correct
 
-Example configuration:
+```ts
+// use lower-case primitives for consistency
+const str: string = 'foo';
+const bool: boolean = true;
+const num: number = 1;
+const symb: symbol = Symbol('foo');
+const bigInt: bigint = 1n;
 
-```jsonc
-{
-  "@typescript-eslint/ban-types": [
-    "error",
-    {
-      "types": {
-        // add a custom message to help explain why not to use it
-        "Foo": "Don't use Foo because it is unsafe",
+// use a proper function type
+const func: () => number = () => 1;
 
-        // add a custom message, AND tell the plugin how to fix it
-        "OldAPI": {
-          "message": "Use NewAPI instead",
-          "fixWith": "NewAPI"
-        },
+// use safer object types
+const lowerObj: object = {};
+const capitalObj: { a: string } = { a: 'string' };
 
-        // un-ban a type that's banned by default
-        "{}": false
-      },
-      "extendDefaults": true
-    }
-  ]
-}
+const curly1: number = 1;
+const curly2: Record<'a', string> = { a: 'string' };
 ```
 
-### Default Options
+## Options
 
 The default options provide a set of "best practices", intended to provide safety and standardization in your codebase:
 
@@ -118,7 +103,6 @@ const defaultTypes = {
     message: 'Use bigint instead',
     fixWith: 'bigint',
   },
-
   Function: {
     message: [
       'The `Function` type accepts any function-like value.',
@@ -127,7 +111,6 @@ const defaultTypes = {
       'If you are expecting the function to accept certain arguments, you should explicitly define the function shape.',
     ].join('\n'),
   },
-
   // object typing
   Object: {
     message: [
@@ -148,52 +131,48 @@ const defaultTypes = {
 
 </details>
 
-### Examples
-
-Examples of code with the default options:
-
-<!--tabs-->
+### `types`
 
-#### ❌ Incorrect
+An object whose keys are the types you want to ban, and the values are error messages.
 
-```ts
-// use lower-case primitives for consistency
-const str: String = 'foo';
-const bool: Boolean = true;
-const num: Number = 1;
-const symb: Symbol = Symbol('foo');
-const bigInt: BigInt = 1n;
+The type can either be a type name literal (`Foo`), a type name with generic parameter instantiation(s) (`Foo<Bar>`), the empty object literal (`{}`), or the empty tuple type (`[]`).
 
-// use a proper function type
-const func: Function = () => 1;
+The values can be:
 
-// use safer object types
-const capitalObj1: Object = 1;
-const capitalObj2: Object = { a: 'string' };
+- A string, which is the error message to be reported; or
+- `false` to specifically un-ban this type (useful when you are using `extendDefaults`); or
+- An object with the following properties:
+  - `message: string` - the message to display when the type is matched.
+  - `fixWith?: string` - a string to replace the banned type with when the fixer is run. If this is omitted, no fix will be done.
 
-const curly1: {} = 1;
-const curly2: {} = { a: 'string' };
-```
+### `extendDefaults`
 
-#### ✅ Correct
+If you're specifying custom `types`, you can set this to `true` to extend the default `types` configuration. This is a convenience option to save you copying across the defaults when adding another type.
 
-```ts
-// use lower-case primitives for consistency
-const str: string = 'foo';
-const bool: boolean = true;
-const num: number = 1;
-const symb: symbol = Symbol('foo');
-const bigInt: bigint = 1n;
+If this is `false`, the rule will _only_ use the types defined in your configuration.
 
-// use a proper function type
-const func: () => number = () => 1;
+Example configuration:
 
-// use safer object types
-const lowerObj: object = {};
+```jsonc
+{
+  "@typescript-eslint/ban-types": [
+    "error",
+    {
+      "types": {
+        // add a custom message to help explain why not to use it
+        "Foo": "Don't use Foo because it is unsafe",
 
-const capitalObj1: number = 1;
-const capitalObj2: { a: string } = { a: 'string' };
+        // add a custom message, AND tell the plugin how to fix it
+        "OldAPI": {
+          "message": "Use NewAPI instead",
+          "fixWith": "NewAPI"
+        },
 
-const curly1: number = 1;
-const curly2: Record<'a', string> = { a: 'string' };
+        // un-ban a type that's banned by default
+        "{}": false
+      },
+      "extendDefaults": true
+    }
+  ]
+}
 ```

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/brace-style.md

@@ -1,28 +1,12 @@
-# `brace-style`
+---
+description: 'Enforce consistent brace style for blocks.'
+---
 
-Enforces consistent brace style for blocks.
+> 🛑 This file is source code, not the primary documentation location! 🛑
+>
+> See **https://typescript-eslint.io/rules/brace-style** for documentation.
 
 ## Rule Details
 
 This rule extends the base [`eslint/brace-style`](https://eslint.org/docs/rules/brace-style) rule.
 It adds support for `enum`, `interface`, `namespace` and `module` declarations.
-
-## How to Use
-
-```jsonc
-{
-  // note you must disable the base rule as it can report incorrect errors
-  "brace-style": "off",
-  "@typescript-eslint/brace-style": ["error"]
-}
-```
-
-## Options
-
-See [`eslint/brace-style` options](https://eslint.org/docs/rules/brace-style#options).
-
-<sup>
-
-Taken with ❤️ [from ESLint core](https://github.com/eslint/eslint/blob/main/docs/rules/brace-style.md)
-
-</sup>

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

@@ -1,7 +1,9 @@
-## DEPRECATED
+:::danger Deprecated
 
 This rule has been deprecated in favour of the [`naming-convention`](./naming-convention.md) 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.

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/class-literal-property-style.md

@@ -1,11 +1,15 @@
-# `class-literal-property-style`
+---
+description: 'Enforce that literals on classes are exposed in a consistent style.'
+---
 
-Enforces that literals on classes are exposed in a consistent style.
+> 🛑 This file is source code, not the primary documentation location! 🛑
+>
+> See **https://typescript-eslint.io/rules/class-literal-property-style** for documentation.
 
 When writing TypeScript applications, it's typically safe to 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.
 
-## Rule Details
+## Options
 
 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.
@@ -17,7 +21,7 @@ This is because these types can be mutated and carry with them more complex impl
 
 :::
 
-### The `fields` style
+### `"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.
 
@@ -60,7 +64,7 @@ class Mx {
 }
 ```
 
-### The `getters` style
+### `"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,

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/comma-dangle.md

@@ -1,6 +1,10 @@
-# `comma-dangle`
+---
+description: 'Require or disallow trailing commas.'
+---
 
-Requires or disallows trailing commas.
+> 🛑 This file is source code, not the primary documentation location! 🛑
+>
+> See **https://typescript-eslint.io/rules/comma-dangle** for documentation.
 
 ## Rule Details
 
@@ -11,30 +15,8 @@ See the [ESLint documentation](https://eslint.org/docs/rules/comma-dangle) for m
 
 ## How to Use
 
-```jsonc
-{
-  // note you must disable the base rule as it can report incorrect errors
-  "comma-dangle": "off",
-  "@typescript-eslint/comma-dangle": ["error"]
-}
-```
-
 In addition to the options supported by the `comma-dangle` rule in ESLint core, the rule adds the following options:
 
-## Options
-
-This rule has a string option and an object option.
-
-- Object option:
-
-  - `"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,]`)
-
-- [See the other options allowed](https://eslint.org/docs/rules/comma-dangle#options)
-
-<sup>
-
-Taken with ❤️ [from ESLint core](https://github.com/eslint/eslint/blob/main/docs/rules/comma-dangle.md)
-
-</sup>
+- `"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/node_modules/@typescript-eslint/eslint-plugin/docs/rules/comma-spacing.md

@@ -1,28 +1,12 @@
-# `comma-spacing`
+---
+description: 'Enforce consistent spacing before and after commas.'
+---
 
-Enforces consistent spacing before and after commas.
+> 🛑 This file is source code, not the primary documentation location! 🛑
+>
+> See **https://typescript-eslint.io/rules/comma-spacing** for documentation.
 
 ## Rule Details
 
 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.
-
-## How to Use
-
-```jsonc
-{
-  // note you must disable the base rule as it can report incorrect errors
-  "comma-spacing": "off",
-  "@typescript-eslint/comma-spacing": ["error"]
-}
-```
-
-## Options
-
-See [`eslint/comma-spacing` options](https://eslint.org/docs/rules/comma-spacing#options).
-
-<sup>
-
-Taken with ❤️ [from ESLint core](https://github.com/eslint/eslint/blob/main/docs/rules/comma-spacing.md)
-
-</sup>

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/consistent-generic-constructors.md

@@ -1,6 +1,10 @@
-# `consistent-generic-constructors`
+---
+description: 'Enforce specifying generic type arguments on type annotation or constructor name of a constructor call.'
+---
 
-Enforces specifying generic type arguments on type annotation or constructor name of a constructor call.
+> 🛑 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):
 
@@ -14,28 +18,15 @@ const map = new Map<string, number>();
 
 This rule ensures that type arguments appear consistently on one side of the declaration.
 
-## Options
-
-```jsonc
-{
-  "rules": {
-    "@typescript-eslint/consistent-generic-constructors": [
-      "error",
-      "constructor"
-    ]
-  }
-}
-```
-
-This rule takes a string option:
-
-- If it's set to `constructor` (default), type arguments that **only** appear on the type annotation are disallowed.
-- If it's set to `type-annotation`, type arguments that **only** appear on the constructor are disallowed.
-
 ## Rule Details
 
 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-->

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/consistent-indexed-object-style.md

@@ -1,6 +1,10 @@
-# `consistent-indexed-object-style`
+---
+description: 'Require or disallow the `Record` type.'
+---
 
-Requires or disallows the `Record` type.
+> 🛑 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 object show keys can be flexible 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:
 
@@ -16,34 +20,24 @@ type Foo = {
 type Foo = Record<string, unknown>;
 ```
 
-## Options
-
-- `"record"`: Set to `"record"` to only allow the `Record` type. Set to `"index-signature"` to only allow index signatures. (Defaults to `"record"`)
-
-For example:
-
-```json
-{
-  "@typescript-eslint/consistent-indexed-object-style": [
-    "error",
-    "index-signature"
-  ]
-}
-```
-
 ## Rule Details
 
 This rule enforces a consistent way to define records.
 
-### `record`
+## Options
+
+- `"record"` _(default)_: only allow the `Record` type.
+- `"index-signature"`: only allow index signatures.
 
-Examples of code with `record` option.
+### `record`
 
 <!--tabs-->
 
 #### ❌ Incorrect
 
 ```ts
+/* eslint @typescript-eslint/consistent-indexed-object-style: ["error", "record"] */
+
 interface Foo {
   [key: string]: unknown;
 }
@@ -56,24 +50,28 @@ type Foo = {
 #### ✅ Correct
 
 ```ts
+/* eslint @typescript-eslint/consistent-indexed-object-style: ["error", "record"] */
+
 type Foo = Record<string, unknown>;
 ```
 
 ### `index-signature`
 
-Examples of code with `index-signature` option.
-
 <!--tabs-->
 
 #### ❌ Incorrect
 
 ```ts
+/* eslint @typescript-eslint/consistent-indexed-object-style: ["error", "index-signature"] */
+
 type Foo = Record<string, unknown>;
 ```
 
 #### ✅ Correct
 
 ```ts
+/* eslint @typescript-eslint/consistent-indexed-object-style: ["error", "index-signature"] */
+
 interface Foo {
   [key: string]: unknown;
 }

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/consistent-type-assertions.md

@@ -1,6 +1,10 @@
-# `consistent-type-assertions`
+---
+description: 'Enforce consistent usage of type assertions.'
+---
 
-Enforces consistent usage of type assertions.
+> 🛑 This file is source code, not the primary documentation location! 🛑
+>
+> See **https://typescript-eslint.io/rules/consistent-type-assertions** for documentation.
 
 ## Rule Details
 
@@ -10,26 +14,10 @@ Type assertions are also commonly referred as "type casting" in TypeScript (even
 
 In addition to ensuring that type assertions are written in a consistent way, this rule also helps make your codebase more type-safe.
 
-`const` assertions, [introduced in TypeScript 3.4](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-4.html#const-assertions), is always allowed by this rule. Examples of it include `let x = "hello" as const;` and `let x = <const>"hello";`.
+[`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
 
-```ts
-type Options =
-  | {
-      assertionStyle: 'as' | 'angle-bracket';
-      objectLiteralTypeAssertions: 'allow' | 'allow-as-parameter' | 'never';
-    }
-  | {
-      assertionStyle: 'never';
-    };
-
-const defaultOptions: Options = {
-  assertionStyle: 'as',
-  objectLiteralTypeAssertions: 'allow',
-};
-```
-
 ### `assertionStyle`
 
 This option defines the expected assertion style. Valid values for `assertionStyle` are:
@@ -52,7 +40,7 @@ The const assertion `const x = { foo: 1 } as const`, introduced in TypeScript 3.
 
 Assertions to `any` are also ignored by this option.
 
-Examples of code for `{ assertionStyle: 'as', objectLiteralTypeAssertions: 'never' }`
+Examples of code for `{ assertionStyle: 'as', objectLiteralTypeAssertions: 'never' }`:
 
 <!--tabs-->
 
@@ -80,7 +68,7 @@ function foo(): T {
 
 <!--/tabs-->
 
-Examples of code for `{ assertionStyle: 'as', objectLiteralTypeAssertions: 'allow-as-parameter' }`
+Examples of code for `{ assertionStyle: 'as', objectLiteralTypeAssertions: 'allow-as-parameter' }`:
 
 <!--tabs-->