xo 0.52.4 → 0.53.1

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-non-null-assertion.md

@@ -6,36 +6,37 @@ description: 'Disallow non-null assertions using the `!` postfix operator.'
 >
 > See **https://typescript-eslint.io/rules/no-non-null-assertion** for documentation.
 
-## Rule Details
+TypeScript's `!` non-null assertion operator asserts to the type system that an expression is non-nullable, as in not `null` or `undefined`.
+Using assertions to tell the type system new information is often a sign that code is not fully type-safe.
+It's generally better to structure program logic so that TypeScript understands when values may be nullable.
 
-Using non-null assertions cancels the benefits of the strict null-checking mode.
-
-Examples of code for this rule:
+## Examples
 
 <!--tabs-->
 
 ### ❌ Incorrect
 
 ```ts
-interface Foo {
-  bar?: string;
+interface Example {
+  property?: string;
 }
 
-const foo: Foo = getFoo();
-const includesBaz: boolean = foo.bar!.includes('baz');
+declare const example: Example;
+const includesBaz = foo.property!.includes('baz');
 ```
 
 ### ✅ Correct
 
 ```ts
-interface Foo {
-  bar?: string;
+interface Example {
+  property?: string;
 }
 
-const foo: Foo = getFoo();
-const includesBaz: boolean = foo.bar?.includes('baz') ?? false;
+declare const example: Example;
+const includesBaz = foo.property?.includes('baz') ?? false;
 ```
 
 ## When Not To Use It
 
-If you don't care about strict null-checking, then you will not need this rule.
+If your project does not use the `strictNullChecks` compiler option, this rule is likely useless to you.
+If your code is often wildly incorrect with respect to strict null-checking, your code may not yet be ready for this rule.

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-parameter-properties.md

@@ -14,7 +14,7 @@ This rule has been deprecated in favour of the equivalent, better named [`parame
 Parameter properties can be confusing to those new to TypeScript as they are less explicit than other ways
 of declaring and initializing class members.
 
-## Rule Details
+## Examples
 
 This rule disallows the use of parameter properties in constructors, forcing the user to explicitly
 declare all properties in the class.

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

@@ -6,7 +6,7 @@ description: 'Disallow variable redeclaration.'
 >
 > See **https://typescript-eslint.io/rules/no-redeclare** for documentation.
 
-## Rule Details
+## Examples
 
 This rule extends the base [`eslint/no-redeclare`](https://eslint.org/docs/rules/no-redeclare) rule.
 It adds support for TypeScript function overloads, and declaration merging.

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-redundant-type-constituents.md

@@ -6,8 +6,6 @@ description: 'Disallow members of unions and intersections that do nothing or ov
 >
 > See **https://typescript-eslint.io/rules/no-redundant-type-constituents** for documentation.
 
-## Rule Details
-
 Some types can override some other types ("constituents") in a union or intersection and/or be overridden by some other types.
 TypeScript's set theory of types includes cases where a constituent type might be useless in the parent union or intersection.
 
@@ -24,7 +22,7 @@ Within `&` intersections:
 - literal types "override" any primitive types in an intersection
 - literal types such as `""` "override" any of their primitive types such as `string`
 
-Examples of code for this rule:
+## Examples
 
 <!--tabs-->
 
@@ -66,14 +64,11 @@ type IntersectionNever = string;
 type IntersectionBooleanLiteral = false;
 type IntersectionNumberLiteral = 1;
 type IntersectionStringLiteral = 'foo';
-
-type ReturnUnionNever = () => string | never;
 ```
 
 ## Limitations
 
 This rule plays it safe and only works with bottom types, top types, and comparing literal types to primitive types.
-It also does not provide an auto-fixer just yet.
 
 ## Further Reading
 

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-require-imports.md

@@ -8,33 +8,30 @@ description: 'Disallow invocation of `require()`.'
 
 Prefer the newer ES6-style imports over `require()`.
 
-## Rule Details
-
-Examples of code for this rule:
+## Examples
 
 <!--tabs-->
 
 ### ❌ Incorrect
 
 ```ts
-var lib = require('lib');
-let lib2 = require('lib2');
-var lib5 = require('lib5'),
-  lib6 = require('lib6');
-import lib8 = require('lib8');
+const lib1 = require('lib1');
+const { lib2 } = require('lib2');
+import lib3 = require('lib3');
 ```
 
 ### ✅ Correct
 
 ```ts
-import { l } from 'lib';
-var lib3 = load('not_an_import');
-var lib4 = lib2.subImport;
-var lib7 = 700;
-import lib9 = lib2.anotherSubImport;
-import lib10 from 'lib10';
+import * as lib1 from 'lib1';
+import { lib2 } from 'lib2';
+import * as lib3 from 'lib3';
 ```
 
 ## When Not To Use It
 
-If you don't care about TypeScript module syntax, then you will not need this rule.
+If you don't care about using newer module syntax, then you will not need this rule.
+
+## Related To
+
+- [`no-var-requires`](./no-var-requires.md)

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-restricted-imports.md

@@ -6,7 +6,7 @@ description: 'Disallow specified modules when loaded by `import`.'
 >
 > See **https://typescript-eslint.io/rules/no-restricted-imports** for documentation.
 
-## Rule Details
+## Examples
 
 This rule extends the base [`eslint/no-restricted-imports`](https://eslint.org/docs/rules/no-restricted-imports) rule.
 

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

@@ -6,7 +6,7 @@ description: 'Disallow variable declarations from shadowing variables declared i
 >
 > See **https://typescript-eslint.io/rules/no-shadow** for documentation.
 
-## Rule Details
+## Examples
 
 This rule extends the base [`eslint/no-shadow`](https://eslint.org/docs/rules/no-shadow) rule.
 It adds support for TypeScript's `this` parameters and global augmentation, and adds options for TypeScript features.

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-this-alias.md

@@ -6,24 +6,24 @@ description: 'Disallow aliasing `this`.'
 >
 > See **https://typescript-eslint.io/rules/no-this-alias** for documentation.
 
-This rule prohibits assigning variables to `this`.
-
-## Rule Details
-
 Assigning a variable to `this` instead of properly using arrow lambdas may be a symptom of pre-ES6 practices
 or not managing scope well.
 
-Instead of storing a reference to `this` and using it inside a `function () {`:
+## Examples
+
+<!--tabs-->
+
+### ❌ Incorrect
 
 ```js
 const self = this;
->
+
 setTimeout(function () {
-    self.doWork();
+  self.doWork();
 });
 ```
 
-Use `() =>` arrow lambdas, as they preserve `this` scope for you:
+### ✅ Correct
 
 ```js
 setTimeout(() => {
@@ -31,13 +31,7 @@ setTimeout(() => {
 });
 ```
 
-Examples of **incorrect** code for this rule:
-
-(see the rationale above)
-
-Examples of **correct** code for this rule:
-
-(see the rationale above)
+## Options
 
 ## When Not To Use It
 

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-throw-literal.md

@@ -11,12 +11,10 @@ The fundamental benefit of `Error` objects is that they automatically keep track
 
 This rule restricts what can be thrown as an exception. When it was first created, it only prevented literals from being thrown (hence the name), but it has now been expanded to only allow expressions which have a possibility of being an `Error` object. With the `allowThrowingAny` and `allowThrowingUnknown`, it can be configured to only allow throwing values which are guaranteed to be an instance of `Error`.
 
-## Rule Details
+## Examples
 
 This rule is aimed at maintaining consistency when throwing exception by disallowing to throw literals and other expressions which cannot possibly be an `Error` object.
 
-Examples of code for this rule:
-
 <!--tabs-->
 
 ### ❌ Incorrect

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-type-alias.md

@@ -78,7 +78,7 @@ On the other hand, using a type alias as an interface can limit your ability to:
 Finally, mapping types is an advanced technique and leaving it open can quickly become a pain point
 in your application.
 
-## Rule Details
+## Examples
 
 This rule disallows the use of type aliases in favor of interfaces
 and simplified types (primitives, tuples, unions, intersections, etc).

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-unnecessary-boolean-literal-compare.md

@@ -6,25 +6,20 @@ description: 'Disallow unnecessary equality comparisons against boolean literals
 >
 > See **https://typescript-eslint.io/rules/no-unnecessary-boolean-literal-compare** for documentation.
 
-Comparing boolean values to boolean literals is unnecessary, those comparisons result in the same booleans. Using the boolean values directly, or via a unary negation (`!value`), is more concise and clearer.
-
-## Rule Details
+Comparing boolean values to boolean literals is unnecessary: those comparisons result in the same booleans.
+Using the boolean values directly, or via a unary negation (`!value`), is more concise and clearer.
 
 This rule ensures that you do not include unnecessary comparisons with boolean literals.
 A comparison is considered unnecessary if it checks a boolean literal against any variable with just the `boolean` type.
-A comparison is **_not_** considered unnecessary if the type is a union of booleans (`string | boolean`, `someObject | boolean`).
-
-**Warning**: Do not use this rule when `strictNullChecks` is disabled.
-ESLint is not able to distinguish between `false` and `undefined` or `null` values.
-This can cause unintended code changes when using autofix.
+A comparison is **_not_** considered unnecessary if the type is a union of booleans (`string | boolean`, `SomeObject | boolean`, etc.).
 
-**Note**: Throughout this page, only strict equality (`===` and `!==`) are
-used in the examples. However, the implementation of the rule does not
-distinguish between strict and loose equality. Any example below that uses
-`===` would be treated the same way if `==` was used, and any example below
-that uses `!==` would be treated the same way if `!=` was used.
+## Examples
 
-Examples of code for this rule:
+:::note
+Throughout this page, only strict equality (`===` and `!==`) are used in the examples.
+However, the implementation of the rule does not distinguish between strict and loose equality.
+Any example below that uses `===` would be treated the same way if `==` was used, and `!==` would be treated the same way if `!=` was used.
+:::
 
 <!--tabs-->
 
@@ -130,3 +125,9 @@ if (!(someNullCondition ?? true)) {
 | `nullableBooleanVar !== true`  | `!nullableBooleanVar`           | Only checked/fixed if the `allowComparingNullableBooleansToTrue` option is `false`  |
 | `nullableBooleanVar === false` | `nullableBooleanVar ?? true`    | Only checked/fixed if the `allowComparingNullableBooleansToFalse` option is `false` |
 | `nullableBooleanVar !== false` | `!(nullableBooleanVar ?? true)` | Only checked/fixed if the `allowComparingNullableBooleansToFalse` option is `false` |
+
+## Not To Use It
+
+Do not use this rule when `strictNullChecks` is disabled.
+ESLint is not able to distinguish between `false` and `undefined` or `null` values.
+This can cause unintended code changes when using autofix.

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-unnecessary-condition.md

@@ -6,7 +6,8 @@ description: 'Disallow conditionals where the type is always truthy or always fa
 >
 > See **https://typescript-eslint.io/rules/no-unnecessary-condition** for documentation.
 
-Any expression being used as a condition must be able to evaluate as truthy or falsy in order to be considered "necessary". Conversely, any expression that always evaluates to truthy or always evaluates to falsy, as determined by the type of the expression, is considered unnecessary and will be flagged by this rule.
+Any expression being used as a condition must be able to evaluate as truthy or falsy in order to be considered "necessary".
+Conversely, any expression that always evaluates to truthy or always evaluates to falsy, as determined by the type of the expression, is considered unnecessary and will be flagged by this rule.
 
 The following expressions are checked:
 
@@ -14,9 +15,7 @@ The following expressions are checked:
 - Conditions for `if`, `for`, `while`, and `do-while` statements
 - Base values of optional chain expressions
 
-## Rule Details
-
-Examples of code for this rule:
+## Examples
 
 <!--tabs-->
 

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-unnecessary-qualifier.md

@@ -6,31 +6,16 @@ description: 'Disallow unnecessary namespace qualifiers.'
 >
 > See **https://typescript-eslint.io/rules/no-unnecessary-qualifier** for documentation.
 
-## Rule Details
+Members of TypeScript enums and namespaces are generally retrieved as qualified property lookups: e.g. `Enum.member`.
+However, when accessed within their parent enum or namespace, the qualifier is unnecessary: e.g. just `member` instead of `Enum.member`.
+This rule reports when an enum or namespace qualifier is unnecessary.
 
-This rule aims to let users know when a namespace or enum qualifier is unnecessary,
-whether used for a type or for a value.
-
-Examples of code for this rule:
+## Examples
 
 <!--tabs-->
 
 ### ❌ Incorrect
 
-```ts
-namespace A {
-  export type B = number;
-  const x: A.B = 3;
-}
-```
-
-```ts
-namespace A {
-  export const x = 3;
-  export const y = A.x;
-}
-```
-
 ```ts
 enum A {
   B,
@@ -40,46 +25,27 @@ enum A {
 
 ```ts
 namespace A {
-  export namespace B {
-    export type T = number;
-    const x: A.B.T = 3;
-  }
+  export type B = number;
+  const x: A.B = 3;
 }
 ```
 
 ### ✅ Correct
 
-```ts
-namespace X {
-  export type T = number;
-}
-
-namespace Y {
-  export const x: X.T = 3;
-}
-```
-
 ```ts
 enum A {
-  X,
-  Y,
-}
-
-enum B {
-  Z = A.X,
+  B,
+  C = B,
 }
 ```
 
 ```ts
-namespace X {
-  export type T = number;
-  namespace Y {
-    type T = string;
-    const x: X.T = 0;
-  }
+namespace A {
+  export type B = number;
+  const x: B = 3;
 }
 ```
 
 ## When Not To Use It
 
-If you don't care about having unneeded namespace or enum qualifiers, then you don't need to use this rule.
+If you don't care about having unneeded enum or namespace qualifiers, then you don't need to use this rule.

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-unnecessary-type-arguments.md

@@ -6,20 +6,17 @@ description: 'Disallow type arguments that are equal to the default.'
 >
 > See **https://typescript-eslint.io/rules/no-unnecessary-type-arguments** for documentation.
 
-Warns if an explicitly specified type argument is the default for that type parameter.
-
-## Rule Details
-
 Type parameters in TypeScript may specify a default value.
 For example:
 
 ```ts
-function f<T = number>() {}
+function f<T = number>(...) {...}
 ```
 
-It is redundant to provide an explicit type parameter equal to that default.
+It is redundant to provide an explicit type parameter equal to that default: e.g. calling `f<number>(...)`.
+This rule reports when an explicitly specified type argument is the default for that type parameter.
 
-Examples of code for this rule:
+## Examples
 
 <!--tabs-->
 
@@ -28,15 +25,21 @@ Examples of code for this rule:
 ```ts
 function f<T = number>() {}
 f<number>();
+```
 
+```ts
 function g<T = number, U = string>() {}
 g<string, string>();
+```
 
+```ts
 class C<T = number> {}
-function h(c: C<number>) {}
 new C<number>();
+
 class D extends C<number> {}
+```
 
+```ts
 interface I<T = number> {}
 class Impl implements I<number> {}
 ```
@@ -45,15 +48,26 @@ class Impl implements I<number> {}
 
 ```ts
 function f<T = number>() {}
+f();
 f<string>();
+```
 
+```ts
 function g<T = number, U = string>() {}
+g<string>();
 g<number, number>();
+```
 
+```ts
 class C<T = number> {}
+new C();
 new C<string>();
+
+class D extends C {}
 class D extends C<string> {}
+```
 
+```ts
 interface I<T = number> {}
 class Impl implements I<string> {}
 ```

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-unnecessary-type-assertion.md

@@ -6,13 +6,11 @@ description: 'Disallow type assertions that do not change the type of an express
 >
 > See **https://typescript-eslint.io/rules/no-unnecessary-type-assertion** for documentation.
 
-This rule prohibits using a type assertion that does not change the type of an expression.
+TypeScript can be told an expression is a different type than expected using `as` type assertions.
+Leaving `as` assertions in the codebase increases visual clutter and harms code readability, so it's generally best practice to remove them if they don't change the type of an expression.
+This rule reports when a type assertion does not change the type of an expression.
 
-## Rule Details
-
-This rule aims to prevent unnecessary type assertions.
-
-Examples of code for this rule:
+## Examples
 
 <!--tabs-->
 

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-unnecessary-type-constraint.md

@@ -6,17 +6,11 @@ description: 'Disallow unnecessary constraints on generic types.'
 >
 > See **https://typescript-eslint.io/rules/no-unnecessary-type-constraint** for documentation.
 
-## Rule Details
+Generic type parameters (`<T>`) in TypeScript may be "constrained" with an [`extends` keyword](https://www.typescriptlang.org/docs/handbook/generics.html#generic-constraints).
+When no `extends` is provided, type parameters default a constraint to `any`.
+It is therefore redundant to `extend` from `any`.
 
-Type parameters (`<T>`) may be "constrained" with an `extends` keyword ([docs](https://www.typescriptlang.org/docs/handbook/generics.html#generic-constraints)).
-When not provided, type parameters happen to default to:
-
-- As of TypeScript 3.9: `unknown` ([docs](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-9.html#type-parameters-that-extend-any-no-longer-act-as-any))
-- Before that, as of 3.5: `any` ([docs](https://devblogs.microsoft.com/typescript/announcing-typescript-3-5/#breaking-changes))
-
-It is therefore redundant to `extend` from these types in later versions of TypeScript.
-
-Examples of code for this rule:
+## Examples
 
 <!--tabs-->
 
@@ -24,24 +18,16 @@ Examples of code for this rule:
 
 ```ts
 interface FooAny<T extends any> {}
-interface FooUnknown<T extends unknown> {}
 
 type BarAny<T extends any> = {};
-type BarUnknown<T extends unknown> = {};
 
 class BazAny<T extends any> {
-  quxUnknown<U extends unknown>() {}
-}
-
-class BazUnknown<T extends unknown> {
-  quxUnknown<U extends unknown>() {}
+  quxAny<U extends any>() {}
 }
 
 const QuuxAny = <T extends any>() => {};
-const QuuxUnknown = <T extends unknown>() => {};
 
 function QuuzAny<T extends any>() {}
-function QuuzUnknown<T extends unknown>() {}
 ```
 
 ### ✅ Correct
@@ -52,7 +38,7 @@ interface Foo<T> {}
 type Bar<T> = {};
 
 class Baz<T> {
-    qux<U> { }
+  qux<U> { }
 }
 
 const Quux = <T>() => {};

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-unsafe-argument.md

@@ -6,16 +6,19 @@ description: 'Disallow calling a function with a value with type `any`.'
 >
 > See **https://typescript-eslint.io/rules/no-unsafe-argument** for documentation.
 
+The `any` type in TypeScript is a dangerous "escape hatch" from the type system.
+Using `any` disables many type checking rules and is generally best used only as a last resort or when prototyping code.
+
 Despite your best intentions, the `any` type can sometimes leak into your codebase.
-Call a function with `any` typed argument are not checked at all by TypeScript, so it creates a potential safety hole, and source of bugs in your codebase.
+Calling a function with an `any` typed argument creates a potential safety hole and source of bugs.
 
-## Rule Details
+This rule disallows calling a function with `any` in its arguments.
+That includes spreading arrays or tuples with `any` typed elements as function arguments.
 
-This rule disallows calling a function with `any` in its arguments, and it will disallow spreading `any[]`.
-This rule also disallows spreading a tuple type with one of its elements typed as `any`.
-This rule also compares the argument's type to the variable's type to ensure you don't pass an unsafe `any` in a generic position to a receiver that's expecting a specific type. For example, it will error if you assign `Set<any>` to an argument declared as `Set<string>`.
+This rule also compares generic type argument types to ensure you don't pass an unsafe `any` in a generic position to a receiver that's expecting a specific type.
+For example, it will error if you pass `Set<any>` as an argument to a parameter declared as `Set<string>`.
 
-Examples of code for this rule:
+## Examples
 
 <!--tabs-->
 
@@ -68,7 +71,7 @@ foo(new Set<string>(), new Map<string, string>());
 
 There are cases where the rule allows passing an argument of `any` to `unknown`.
 
-Example of `any` to `unknown` assignment that are allowed.
+Example of `any` to `unknown` assignment that are allowed:
 
 ```ts
 declare function foo(arg1: unknown, arg2: Set<unkown>, arg3: unknown[]): void;

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-unsafe-assignment.md

@@ -6,15 +6,18 @@ description: 'Disallow assigning a value with type `any` to variables and proper
 >
 > See **https://typescript-eslint.io/rules/no-unsafe-assignment** for documentation.
 
-Despite your best intentions, the `any` type can sometimes leak into your codebase.
-Assigning an `any` typed value to a variable can be hard to pick up on, particularly if it leaks in from an external library. Operations on the variable will not be checked at all by TypeScript, so it creates a potential safety hole, and source of bugs in your codebase.
+The `any` type in TypeScript is a dangerous "escape hatch" from the type system.
+Using `any` disables many type checking rules and is generally best used only as a last resort or when prototyping code.
 
-## Rule Details
+Despite your best intentions, the `any` type can sometimes leak into your codebase.
+Assigning an `any` typed value to a variable can be hard to pick up on, particularly if it leaks in from an external library.
 
 This rule disallows assigning `any` to a variable, and assigning `any[]` to an array destructuring.
-This rule also compares the assigned type to the variable's type to ensure you don't assign an unsafe `any` in a generic position to a receiver that's expecting a specific type. For example, it will error if you assign `Set<any>` to a variable declared as `Set<string>`.
 
-Examples of code for this rule:
+This rule also compares generic type argument types to ensure you don't pass an unsafe `any` in a generic position to a receiver that's expecting a specific type.
+For example, it will error if you assign `Set<any>` to a variable declared as `Set<string>`.
+
+## Examples
 
 <!--tabs-->
 
@@ -70,7 +73,7 @@ const x: Set<Set<Set<string>>> = new Set<Set<Set<string>>>();
 
 There are cases where the rule allows assignment of `any` to `unknown`.
 
-Example of `any` to `unknown` assignment that are allowed.
+Example of `any` to `unknown` assignment that are allowed:
 
 ```ts
 const x: unknown = y as any;

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-unsafe-call.md

@@ -6,14 +6,15 @@ description: 'Disallow calling a value with type `any`.'
 >
 > See **https://typescript-eslint.io/rules/no-unsafe-call** for documentation.
 
-Despite your best intentions, the `any` type can sometimes leak into your codebase.
-The arguments to, and return value of calling an `any` typed variable are not checked at all by TypeScript, so it creates a potential safety hole, and source of bugs in your codebase.
+The `any` type in TypeScript is a dangerous "escape hatch" from the type system.
+Using `any` disables many type checking rules and is generally best used only as a last resort or when prototyping code.
 
-## Rule Details
+Despite your best intentions, the `any` type can sometimes leak into your codebase.
+Calling an `any`-typed value as a function creates a potential type safety hole and source of bugs in your codebase.
 
-This rule disallows calling any variable that is typed as `any`.
+This rule disallows calling any value that is typed as `any`.
 
-Examples of code for this rule:
+## Examples
 
 <!--tabs-->