xo 0.46.4 → 0.49.0

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

@@ -1,4 +1,6 @@
-# Bans specific types from being used (`ban-types`)
+# `ban-types`
+
+Bans specific types from being used.
 
 Some builtin types have aliases, some types are considered dangerous or harmful.
 It's often a good idea to ban certain types to help with consistency and safety.
@@ -76,7 +78,11 @@ The default options provide a set of "best practices", intended to provide safet
   - This is a point of confusion for many developers, who think it means "any object type".
   - See [this comment for more information](https://github.com/typescript-eslint/typescript-eslint/issues/2063#issuecomment-675156492).
 
-**_Important note:_** the default options suggest using `Record<string, unknown>`; this was a stylistic decision, as the built-in `Record` type is considered to look cleaner.
+:::important
+
+The default options suggest using `Record<string, unknown>`; this was a stylistic decision, as the built-in `Record` type is considered to look cleaner.
+
+:::
 
 <details>
 <summary>Default Options</summary>
@@ -99,6 +105,10 @@ const defaultTypes = {
     message: 'Use symbol instead',
     fixWith: 'symbol',
   },
+  BigInt: {
+    message: 'Use bigint instead',
+    fixWith: 'bigint',
+  },
 
   Function: {
     message: [
@@ -131,7 +141,11 @@ const defaultTypes = {
 
 ### Examples
 
-Examples of **incorrect** code with the default options:
+Examples of code with the default options:
+
+<!--tabs-->
+
+#### ❌ Incorrect
 
 ```ts
 // use lower-case primitives for consistency
@@ -139,6 +153,7 @@ const str: String = 'foo';
 const bool: Boolean = true;
 const num: Number = 1;
 const symb: Symbol = Symbol('foo');
+const bigInt: BigInt = 1n;
 
 // use a proper function type
 const func: Function = () => 1;
@@ -151,7 +166,7 @@ const curly1: {} = 1;
 const curly2: {} = { a: 'string' };
 ```
 
-Examples of **correct** code with the default options:
+#### ✅ Correct
 
 ```ts
 // use lower-case primitives for consistency
@@ -159,6 +174,7 @@ const str: string = 'foo';
 const bool: boolean = true;
 const num: number = 1;
 const symb: symbol = Symbol('foo');
+const bigInt: bigint = 1n;
 
 // use a proper function type
 const func: () => number = () => 1;
@@ -173,12 +189,14 @@ const curly1: number = 1;
 const curly2: Record<'a', string> = { a: 'string' };
 ```
 
-## Compatibility
+## Related To
 
 - TSLint: [ban-types](https://palantir.github.io/tslint/rules/ban-types)
 
 ## Attributes
 
-- [x] ✅ Recommended
+- Configs:
+  - [x] ✅ Recommended
+  - [x] 🔒 Strict
 - [x] 🔧 Fixable
 - [ ] 💭 Requires type information

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

@@ -1,11 +1,13 @@
-# Enforce consistent brace style for blocks (`brace-style`)
+# `brace-style`
+
+Enforce consistent brace style for blocks.
 
 ## 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
+## How to Use
 
 ```jsonc
 {
@@ -19,10 +21,16 @@ It adds support for `enum`, `interface`, `namespace` and `module` declarations.
 
 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/master/docs/rules/brace-style.md)</sup>
+<sup>
+
+Taken with ❤️ [from ESLint core](https://github.com/eslint/eslint/blob/main/docs/rules/brace-style.md)
+
+</sup>
 
 ## Attributes
 
-- [ ] ✅ Recommended
+- Configs:
+  - [ ] ✅ Recommended
+  - [ ] 🔒 Strict
 - [x] 🔧 Fixable
 - [ ] 💭 Requires type information

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

@@ -1,4 +1,6 @@
-# Ensures that literals on classes are exposed in a consistent style (`class-literal-property-style`)
+# `class-literal-property-style`
+
+Ensures that literals on classes are exposed in a consistent style.
 
 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.
@@ -8,44 +10,52 @@ When writing TypeScript libraries that could be used by JavaScript users however
 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.
 
-Note that 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.
+:::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.
 
+:::
+
 ### The `fields` style
 
 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 **correct** code with the `fields` style:
+Examples of code with the `fields` style:
+
+<!--tabs-->
+
+#### ❌ Incorrect
 
 ```ts
 /* eslint @typescript-eslint/class-literal-property-style: ["error", "fields"] */
 
 class Mx {
-  public readonly myField1 = 1;
-
-  // not a literal
-  public readonly myField2 = [1, 2, 3];
-
-  private readonly ['myField3'] = 'hello world';
+  public static get myField1() {
+    return 1;
+  }
 
-  public get myField4() {
-    return `hello from ${window.location.href}`;
+  private get ['myField2']() {
+    return 'hello world';
   }
 }
 ```
 
-Examples of **incorrect** code with the `fields` style:
+#### ✅ Correct
 
 ```ts
 /* eslint @typescript-eslint/class-literal-property-style: ["error", "fields"] */
 
 class Mx {
-  public static get myField1() {
-    return 1;
-  }
+  public readonly myField1 = 1;
 
-  private get ['myField2']() {
-    return 'hello world';
+  // not a literal
+  public readonly myField2 = [1, 2, 3];
+
+  private readonly ['myField3'] = 'hello world';
+
+  public get myField4() {
+    return `hello from ${window.location.href}`;
   }
 }
 ```
@@ -56,7 +66,23 @@ This style checks for any `readonly` fields that are assigned literal values, an
 This style pairs well with the [`@typescript-eslint/prefer-readonly`](prefer-readonly.md) rule,
 as it will identify fields that can be `readonly`, and thus should be made into getters.
 
-Examples of **correct** code with the `getters` style:
+Examples of code with the `getters` style:
+
+<!--tabs-->
+
+#### ❌ Incorrect
+
+```ts
+/* eslint @typescript-eslint/class-literal-property-style: ["error", "getters"] */
+
+class Mx {
+  readonly myField1 = 1;
+  readonly myField2 = `hello world`;
+  private readonly myField3 = 'hello world';
+}
+```
+
+#### ✅ Correct
 
 ```ts
 /* eslint @typescript-eslint/class-literal-property-style: ["error", "getters"] */
@@ -78,18 +104,6 @@ class Mx {
 }
 ```
 
-Examples of **incorrect** code with the `getters` style:
-
-```ts
-/* eslint @typescript-eslint/class-literal-property-style: ["error", "getters"] */
-
-class Mx {
-  readonly myField1 = 1;
-  readonly myField2 = `hello world`;
-  private readonly myField3 = 'hello world';
-}
-```
-
 ## When Not To Use It
 
 When you have no strong preference, or do not wish to enforce a particular style
@@ -97,6 +111,8 @@ for how literal values are exposed by your classes.
 
 ## Attributes
 
-- [ ] ✅ Recommended
+- Configs:
+  - [ ] ✅ Recommended
+  - [x] 🔒 Strict
 - [x] 🔧 Fixable
 - [ ] 💭 Requires type information

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

@@ -1,4 +1,6 @@
-# Require or disallow trailing comma (`comma-dangle`)
+# `comma-dangle`
+
+Require or disallow trailing comma.
 
 ## Rule Details
 
@@ -9,7 +11,7 @@ See the [ESLint documentation](https://eslint.org/docs/rules/comma-dangle) for m
 
 ## Rule Changes
 
-```cjson
+```jsonc
 {
   // note you must disable the base rule as it can report incorrect errors
   "comma-dangle": "off",
@@ -29,12 +31,18 @@ This rule has a string option and an object option.
   - `"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://github.com/eslint/eslint/blob/master/docs/rules/comma-dangle.md#options)
+- [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>Taken with ❤️ [from ESLint core](https://github.com/eslint/eslint/blob/master/docs/rules/comma-dangle.md)</sup>
+</sup>
 
 ## Attributes
 
-- [ ] ✅ Recommended
+- Configs:
+  - [ ] ✅ Recommended
+  - [ ] 🔒 Strict
 - [x] 🔧 Fixable
 - [ ] 💭 Requires type information

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

@@ -1,11 +1,13 @@
-# Enforces consistent spacing before and after commas (`comma-spacing`)
+# `comma-spacing`
+
+Enforces consistent spacing before and after commas.
 
 ## 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
+## How to Use
 
 ```jsonc
 {
@@ -19,10 +21,16 @@ It adds support for trailing comma in a types parameters list.
 
 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/master/docs/rules/comma-spacing.md)</sup>
+<sup>
+
+Taken with ❤️ [from ESLint core](https://github.com/eslint/eslint/blob/main/docs/rules/comma-spacing.md)
+
+</sup>
 
 ## Attributes
 
-- [ ] ✅ Recommended
+- Configs:
+  - [ ] ✅ Recommended
+  - [ ] 🔒 Strict
 - [x] 🔧 Fixable
 - [ ] 💭 Requires type information

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

@@ -1,4 +1,6 @@
-# Enforce or disallow the use of the record type (`consistent-indexed-object-style`)
+# `consistent-indexed-object-style`
+
+Enforce or disallow the use of the record type.
 
 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:
 
@@ -20,17 +22,26 @@ type Foo = Record<string, unknown>;
 
 For example:
 
-```CJSON
+```json
 {
-    "@typescript-eslint/consistent-indexed-object-style": ["error", "index-signature"]
+  "@typescript-eslint/consistent-indexed-object-style": [
+    "error",
+    "index-signature"
+  ]
 }
 ```
 
-## Rule details
+## Rule Details
 
 This rule enforces a consistent way to define records.
 
-Examples of **incorrect** code with `record` option.
+### `record`
+
+Examples of code with `record` option.
+
+<!--tabs-->
+
+#### ❌ Incorrect
 
 ```ts
 interface Foo {
@@ -42,19 +53,25 @@ type Foo = {
 };
 ```
 
-Examples of **correct** code with `record` option.
+#### ✅ Correct
 
 ```ts
 type Foo = Record<string, unknown>;
 ```
 
-Examples of **incorrect** code with `index-signature` option.
+### `index-signature`
+
+Examples of code with `index-signature` option.
+
+<!--tabs-->
+
+#### ❌ Incorrect
 
 ```ts
 type Foo = Record<string, unknown>;
 ```
 
-Examples of **correct** code with `index-signature` option.
+#### ✅ Correct
 
 ```ts
 interface Foo {
@@ -68,6 +85,8 @@ type Foo = {
 
 ## Attributes
 
-- [ ] ✅ Recommended
+- Configs:
+  - [ ] ✅ Recommended
+  - [x] 🔒 Strict
 - [x] 🔧 Fixable
 - [ ] 💭 Requires type information

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

@@ -1,4 +1,6 @@
-# Enforces consistent usage of type assertions (`consistent-type-assertions`)
+# `consistent-type-assertions`
+
+Enforces consistent usage of type assertions.
 
 ## Rule Details
 
@@ -50,7 +52,11 @@ The const assertion `const x = { foo: 1 } as const`, introduced in TypeScript 3.
 
 Assertions to `any` are also ignored by this option.
 
-Examples of **incorrect** code for `{ assertionStyle: 'as', objectLiteralTypeAssertions: 'never' }` (and for `{ assertionStyle: 'as', objectLiteralTypeAssertions: 'allow-as-parameter' }`)
+Examples of code for `{ assertionStyle: 'as', objectLiteralTypeAssertions: 'never' }`
+
+<!--tabs-->
+
+#### ❌ Incorrect
 
 ```ts
 const x = { ... } as T;
@@ -60,7 +66,7 @@ function foo() {
 }
 ```
 
-Examples of **correct** code for `{ assertionStyle: 'as', objectLiteralTypeAssertions: 'never' }`.
+#### ✅ Correct
 
 ```ts
 const x: T = { ... };
@@ -72,7 +78,23 @@ function foo(): T {
 }
 ```
 
-Examples of **correct** code for `{ assertionStyle: 'as', objectLiteralTypeAssertions: 'allow-as-parameter' }`.
+<!--/tabs-->
+
+Examples of code for `{ assertionStyle: 'as', objectLiteralTypeAssertions: 'allow-as-parameter' }`
+
+<!--tabs-->
+
+#### ❌ Incorrect
+
+```ts
+const x = { ... } as T;
+
+function foo() {
+  return { ... } as T;
+}
+```
+
+#### ✅ Correct
 
 ```tsx
 const x: T = { ... };
@@ -84,17 +106,21 @@ function foo() { throw { bar: 5 } as Foo }
 const foo = <Foo props={{ ... } as Bar}/>;
 ```
 
+<!--/tabs-->
+
 ## When Not To Use It
 
 If you do not want to enforce consistent type assertions.
 
-## Compatibility
+## Related To
 
 - TSLint: [no-angle-bracket-type-assertion](https://palantir.github.io/tslint/rules/no-angle-bracket-type-assertion/)
 - TSLint: [no-object-literal-type-assertion](https://palantir.github.io/tslint/rules/no-object-literal-type-assertion/)
 
 ## Attributes
 
-- [ ] ✅ Recommended
+- Configs:
+  - [ ] ✅ Recommended
+  - [x] 🔒 Strict
 - [ ] 🔧 Fixable
 - [ ] 💭 Requires type information

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

@@ -1,4 +1,6 @@
-# Consistent with type definition either `interface` or `type` (`consistent-type-definitions`)
+# `consistent-type-definitions`
+
+Consistent with type definition either `interface` or `type`.
 
 There are two ways to define a type.
 
@@ -32,15 +34,19 @@ For example:
 }
 ```
 
-## Rule Details
+### `interface`
+
+Examples of code with `interface` option.
+
+<!--tabs-->
 
-Examples of **incorrect** code with `interface` option.
+#### ❌ Incorrect
 
 ```ts
 type T = { x: number };
 ```
 
-Examples of **correct** code with `interface` option.
+#### ✅ Correct
 
 ```ts
 type T = string;
@@ -51,7 +57,13 @@ interface T {
 }
 ```
 
-Examples of **incorrect** code with `type` option.
+### `type`
+
+Examples of code with `type` option.
+
+<!--tabs-->
+
+#### ❌ Incorrect
 
 ```ts
 interface T {
@@ -59,7 +71,7 @@ interface T {
 }
 ```
 
-Examples of **correct** code with `type` option.
+#### ✅ Correct
 
 ```ts
 type T = { x: number };
@@ -69,12 +81,14 @@ type T = { x: number };
 
 If you specifically want to use an interface or type literal for stylistic reasons, you can disable this rule.
 
-## Compatibility
+## Related To
 
 - TSLint: [interface-over-type-literal](https://palantir.github.io/tslint/rules/interface-over-type-literal/)
 
 ## Attributes
 
-- [ ] ✅ Recommended
+- Configs:
+  - [ ] ✅ Recommended
+  - [x] 🔒 Strict
 - [x] 🔧 Fixable
 - [ ] 💭 Requires type information

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

@@ -1,4 +1,6 @@
-# Enforces consistent usage of type exports (`consistent-type-exports`)
+# `consistent-type-exports`
+
+Enforces consistent usage of type exports.
 
 TypeScript 3.8 added support for type-only exports.
 
@@ -9,26 +11,109 @@ transpilers to drop exports without knowing the types of the dependencies.
 
 This rule aims to standardize the use of type exports style across a codebase.
 
-Given a class `Button`, and an interface `ButtonProps`, examples of **correct** code:
+Given a class `Button`, and an interface `ButtonProps`, examples of code:
+
+<!--tabs-->
+
+### ❌ Incorrect
+
+```ts
+interface ButtonProps {
+  onClick: () => void;
+}
+class Button implements ButtonProps {
+  onClick() {
+    console.log('button!');
+  }
+}
+export { Button, ButtonProps };
+```
+
+### ✅ Correct
+
+```ts
+interface ButtonProps {
+  onClick: () => void;
+}
+class Button implements ButtonProps {
+  onClick() {
+    console.log('button!');
+  }
+}
+export { Button };
+export type { ButtonProps };
+```
+
+## Options
+
+```ts
+interface Options {
+  fixMixedExportsWithInlineTypeSpecifier?: boolean;
+}
+
+const defaultOptions: Options = {
+  fixMixedExportsWithInlineTypeSpecifier: false,
+};
+```
+
+### `fixMixedExportsWithInlineTypeSpecifier`
+
+When this is set to true, the rule will autofix "mixed" export cases using TS 4.5's "inline type specifier".
+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:
+
+```ts
+const x = 1;
+type T = number;
+
+export { x, T };
+```
+
+With `{fixMixedExportsWithInlineTypeSpecifier: true}` will be fixed to:
+
+```ts
+const x = 1;
+type T = number;
+
+export { x, type T };
+```
+
+With `{fixMixedExportsWithInlineTypeSpecifier: false}` will be fixed to:
+
+```ts
+const x = 1;
+type T = number;
+
+export type { T };
+export { x };
+```
+
+<!--tabs-->
+
+### ❌ Incorrect
 
 ```ts
 export { Button } from 'some-library';
 export type { ButtonProps } from 'some-library';
 ```
 
-Examples of **incorrect** code:
+### ✅ Correct
 
 ```ts
-export { Button, ButtonProps } from 'some-library';
+export { Button, type ButtonProps } from 'some-library';
 ```
 
 ## When Not To Use It
 
 - If you are using a TypeScript version less than 3.8, then you will not be able to use this rule as type exports are not supported.
 - If you specifically want to use both export kinds for stylistic reasons, you can disable this rule.
+- If you use `--isolatedModules` the compiler would error if a type is not re-exported using `export type`. If you also don't wish to enforce one style over the other, you can disable this rule.
 
 ## Attributes
 
-- [ ] ✅ Recommended
+- Configs:
+  - [ ] ✅ Recommended
+  - [ ] 🔒 Strict
 - [x] 🔧 Fixable
 - [x] 💭 Requires type information

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

@@ -1,4 +1,6 @@
-# Enforces consistent usage of type imports (`consistent-type-imports`)
+# `consistent-type-imports`
+
+Enforces consistent usage of type imports.
 
 TypeScript 3.8 added support for type-only imports.
 Type-only imports allow you to specify that an import can only be used in a type location, allowing certain optimizations within compilers.
@@ -65,6 +67,8 @@ const x: import('Bar') = 1;
 
 ## Attributes
 
-- [ ] ✅ Recommended
+- Configs:
+  - [ ] ✅ Recommended
+  - [ ] 🔒 Strict
 - [x] 🔧 Fixable
 - [ ] 💭 Requires type information