@typescript-eslint/eslint-plugin 8.33.1-alpha.5 → 8.33.1

package/docs/rules/no-duplicate-type-constituents.mdx

@@ -1,89 +0,0 @@
----
-description: 'Disallow duplicate constituents of union or intersection types.'
----
-
-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/no-duplicate-type-constituents** for documentation.
-
-TypeScript supports types ("constituents") within union and intersection types being duplicates of each other.
-However, developers typically expect each constituent to be unique within its intersection or union.
-Duplicate values make the code overly verbose and generally reduce readability.
-
-This rule disallows duplicate union or intersection constituents.
-We consider types to be duplicate if they evaluate to the same result in the type system.
-For example, given `type A = string` and `type T = string | A`, this rule would flag that `A` is the same type as `string`.
-
-This rule also disallows explicitly listing `undefined` in a type union when a function parameter is marked as optional.
-Doing so is unnecessary.
-Please note that this check only applies to parameters, not properties.
-Therefore, it does not conflict with the [`exactOptionalPropertyTypes`](https://www.typescriptlang.org/tsconfig/#exactOptionalPropertyTypes) TypeScript compiler setting.
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts
-type T1 = 'A' | 'A';
-
-type T2 = string | string | number;
-
-type T3 = { a: string } & { a: string };
-
-type T4 = [1, 2, 3] | [1, 2, 3];
-
-type StringA = string;
-type StringB = string;
-type T5 = StringA | StringB;
-
-const fn = (a?: string | undefined) => {};
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts
-type T1 = 'A' | 'B';
-
-type T2 = string | number | boolean;
-
-type T3 = { a: string } & { b: string };
-
-type T4 = [1, 2, 3] | [1, 2, 3, 4];
-
-type StringA = string;
-type NumberB = number;
-type T5 = StringA | NumberB;
-
-const fn = (a?: string) => {};
-```
-
-</TabItem>
-</Tabs>
-
-## Options
-
-### `ignoreIntersections`
-
-{/* insert option description */}
-
-When set to true, duplicate checks on intersection type constituents are ignored.
-
-### `ignoreUnions`
-
-{/* insert option description */}
-
-When set to true, duplicate checks on union type constituents are ignored.
-
-## When Not To Use It
-
-It can sometimes be useful for the sake of documentation to include aliases for the same type.
-You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.
-
-> In some of those cases, [branded types](https://basarat.gitbook.io/typescript/main-1/nominaltyping#using-interfaces) might be a type-safe way to represent the underlying data types.
-
-## Related To
-
-- [no-redundant-type-constituents](./no-redundant-type-constituents.mdx)

package/docs/rules/no-dynamic-delete.mdx

@@ -1,64 +0,0 @@
----
-description: 'Disallow using the `delete` operator on computed key expressions.'
----
-
-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/no-dynamic-delete** for documentation.
-
-Deleting dynamically computed keys can be dangerous and in some cases not well optimized.
-Using the `delete` operator on keys that aren't runtime constants could be a sign that you're using the wrong data structures.
-Consider using a `Map` or `Set` if you’re using an object as a key-value collection.
-
-Dynamically adding and removing keys from objects can cause occasional edge case bugs. For example, some objects use "hidden properties" (such as `__data`) for private storage, and deleting them can break the object's internal state. Furthermore, [`delete`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/delete) cannot remove inherited properties or non-configurable properties. This makes it interact badly with anything more complicated than a plain object:
-
-- The [`length`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/length) of an array is non-configurable, and deleting it is a runtime error.
-- You can't remove properties on the prototype of an object, such as deleting methods from class instances.
-- Sometimes, `delete` only removes the own property, leaving the inherited property intact. For example, deleting the [`name`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/name) property of a function only removes the own property, but there's also a `Function.prototype.name` property that remains.
-
-## Examples
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts
-// Dynamic, difficult-to-reason-about lookups
-const name = 'name';
-delete container[name];
-delete container[name.toUpperCase()];
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts
-const container: { [i: string]: number } = {
-  /* ... */
-};
-
-// Constant runtime lookups by string index
-delete container.aaa;
-
-// Constants that must be accessed by []
-delete container[7];
-delete container[-1];
-
-// All strings are allowed, to be compatible with the noPropertyAccessFromIndexSignature
-// TS compiler option
-delete container['aaa'];
-delete container['Infinity'];
-```
-
-</TabItem>
-</Tabs>
-
-## When Not To Use It
-
-When you know your keys are safe to delete, this rule can be unnecessary.
-You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.
-
-Do not consider this rule as performance advice before profiling your code's bottlenecks.
-Even repeated minor performance slowdowns likely do not significantly affect your application's general perceived speed.

package/docs/rules/no-empty-function.mdx

@@ -1,94 +0,0 @@
----
-description: 'Disallow empty functions.'
----
-
-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/no-empty-function** for documentation.
-
-It adds support for handling TypeScript specific code that would otherwise trigger the rule.
-
-One example of valid TypeScript specific code that would otherwise trigger the `no-empty-function` rule is the use of [parameter properties](https://www.typescriptlang.org/docs/handbook/classes.html#parameter-properties) in constructor functions.
-
-## Options
-
-This rule adds the following options:
-
-```ts
-type AdditionalAllowOptionEntries =
-  | 'private-constructors'
-  | 'protected-constructors'
-  | 'decoratedFunctions'
-  | 'overrideMethods';
-
-type AllowOptionEntries =
-  | BaseNoEmptyFunctionAllowOptionEntries
-  | AdditionalAllowOptionEntries;
-
-interface Options extends BaseNoEmptyFunctionOptions {
-  allow?: Array<AllowOptionEntries>;
-}
-const defaultOptions: Options = {
-  ...baseNoEmptyFunctionDefaultOptions,
-  allow: [],
-};
-```
-
-### allow: `private-constructors`
-
-Examples of correct code for the `{ "allow": ["private-constructors"] }` option:
-
-```ts option='{ "allow": ["private-constructors"] }' showPlaygroundButton
-class Foo {
-  private constructor() {}
-}
-```
-
-### allow: `protected-constructors`
-
-Examples of correct code for the `{ "allow": ["protected-constructors"] }` option:
-
-```ts option='{ "allow": ["protected-constructors"] }' showPlaygroundButton
-class Foo {
-  protected constructor() {}
-}
-```
-
-### allow: `decoratedFunctions`
-
-Examples of correct code for the `{ "allow": ["decoratedFunctions"] }` option:
-
-```ts option='{ "allow": ["decoratedFunctions"] }' showPlaygroundButton
-class Foo {
-  @decorator()
-  foo() {}
-}
-```
-
-### allow: `overrideMethods`
-
-Examples of correct code for the `{ "allow": ["overrideMethods"] }` option:
-
-```ts option='{ "allow": ["overrideMethods"] }' showPlaygroundButton
-abstract class Base {
-  protected greet(): void {
-    console.log('Hello!');
-  }
-}
-
-class Foo extends Base {
-  protected override greet(): void {}
-}
-```
-
-## When Not To Use It
-
-If you are working with external APIs that require functions even if they do nothing, then you may want to avoid this rule.
-You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.
-
-Test code often violates this rule as well.
-If your testing setup doesn't support "mock" or "spy" functions such as [`jest.fn()`](https://jestjs.io/docs/mock-functions), [`sinon.spy()`](https://sinonjs.org/releases/latest/spies), or [`vi.fn()`](https://vitest.dev/guide/mocking.html), you may wish to disable this rule in test files.
-Again, if those cases aren't extremely common, you might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule in test files.

package/docs/rules/no-empty-interface.mdx

@@ -1,75 +0,0 @@
----
-description: 'Disallow the declaration of empty interfaces.'
----
-
-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/no-empty-interface** for documentation.
-
-:::danger Deprecated
-
-This rule has been deprecated in favour of the more comprehensive [`@typescript-eslint/no-empty-object-type`](./no-empty-object-type.mdx) rule.
-
-:::
-
-An empty interface in TypeScript does very little: any non-nullable value is assignable to `{}`.
-Using an empty interface is often a sign of programmer error, such as misunderstanding the concept of `{}` or forgetting to fill in fields.
-
-This rule aims to ensure that only meaningful interfaces are declared in the code.
-
-## Examples
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts
-// an empty interface
-interface Foo {}
-
-// an interface with only one supertype (Bar === Foo)
-interface Bar extends Foo {}
-
-// an interface with an empty list of supertypes
-interface Baz {}
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts
-// an interface with any number of members
-interface Foo {
-  name: string;
-}
-
-// same as above
-interface Bar {
-  age: number;
-}
-
-// an interface with more than one supertype
-// in this case the interface can be used as a replacement of an intersection type.
-interface Baz extends Foo, Bar {}
-```
-
-</TabItem>
-</Tabs>
-
-## Options
-
-### `allowSingleExtends`
-
-{/* insert option description */}
-
-`allowSingleExtends: true` will silence warnings about extending a single interface without adding additional members.
-
-## When Not To Use It
-
-If you don't care about having empty/meaningless interfaces, then you will not need this rule.
-
-## Related To
-
-- [`no-empty-object-type`](./no-empty-object-type.mdx)

package/docs/rules/no-empty-object-type.mdx

@@ -1,150 +0,0 @@
----
-description: 'Disallow accidentally using the "empty object" type.'
----
-
-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/no-empty-object-type** for documentation.
-
-The `{}`, or "empty object" type in TypeScript is a common source of confusion for developers unfamiliar with TypeScript's structural typing.
-`{}` represents any _non-nullish value_, including literals like `0` and `""`:
-
-```ts
-let anyNonNullishValue: {} = 'Intentionally allowed by TypeScript.';
-```
-
-Often, developers writing `{}` actually mean either:
-
-- `object`: representing any _object_ value
-- `unknown`: representing any value at all, including `null` and `undefined`
-
-In other words, the "empty object" type `{}` really means _"any value that is defined"_.
-That includes arrays, class instances, functions, and primitives such as `string` and `symbol`.
-
-To avoid confusion around the `{}` type allowing any _non-nullish value_, this rule bans usage of the `{}` type.
-That includes interfaces and object type aliases with no fields.
-
-:::tip
-If you do have a use case for an API allowing `{}`, you can always configure the [rule's options](#options), use an [ESLint disable comment](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1), or [disable the rule in your ESLint config](https://eslint.org/docs/latest/use/configure/rules#using-configuration-files-1).
-:::
-
-Note that this rule does not report on:
-
-- `{}` as a type constituent in an intersection type (e.g. types like TypeScript's built-in `type NonNullable<T> = T & {}`), as this can be useful in type system operations.
-- Interfaces that extend from multiple other interfaces.
-
-## Examples
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts
-let anyObject: {};
-let anyValue: {};
-
-interface AnyObjectA {}
-interface AnyValueA {}
-
-type AnyObjectB = {};
-type AnyValueB = {};
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts
-let anyObject: object;
-let anyValue: unknown;
-
-type AnyObjectA = object;
-type AnyValueA = unknown;
-
-type AnyObjectB = object;
-type AnyValueB = unknown;
-
-let objectWith: { property: boolean };
-
-interface InterfaceWith {
-  property: boolean;
-}
-
-type TypeWith = { property: boolean };
-```
-
-</TabItem>
-</Tabs>
-
-## Options
-
-By default, this rule flags both interfaces and object types.
-
-### `allowInterfaces`
-
-{/* insert option description */}
-
-Allowed values are:
-
-- `'always'`: to always allow interfaces with no fields
-- `'never'` _(default)_: to never allow interfaces with no fields
-- `'with-single-extends'`: to allow empty interfaces that `extend` from a single base interface
-
-Examples of **correct** code for this rule with `{ allowInterfaces: 'with-single-extends' }`:
-
-```ts option='{ "allowInterfaces": "with-single-extends" }' showPlaygroundButton
-interface Base {
-  value: boolean;
-}
-
-interface Derived extends Base {}
-```
-
-### `allowObjectTypes`
-
-{/* insert option description */}
-
-Allowed values are:
-
-- `'always'`: to always allow object type literals with no fields
-- `'never'` _(default)_: to never allow object type literals with no fields
-
-### `allowWithName`
-
-{/* insert option description */}
-
-This can be useful if your existing code style includes a pattern of declaring empty types with `{}` instead of `object`.
-
-Examples of code for this rule with `{ allowWithName: 'Props$' }`:
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts option='{ "allowWithName": "Props$" }' showPlaygroundButton
-interface InterfaceValue {}
-
-type TypeValue = {};
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts option='{ "allowWithName": "Props$" }' showPlaygroundButton
-interface InterfaceProps {}
-
-type TypeProps = {};
-```
-
-</TabItem>
-</Tabs>
-
-## When Not To Use It
-
-If your code commonly needs to represent the _"any non-nullish value"_ type, this rule may not be for you.
-Projects that extensively use type operations such as conditional types and mapped types oftentimes benefit from disabling this rule.
-
-## Further Reading
-
-- [Enhancement: [ban-types] Split the {} ban into a separate, better-phrased rule](https://github.com/typescript-eslint/typescript-eslint/issues/8700)
-- [The Empty Object Type in TypeScript](https://www.totaltypescript.com/the-empty-object-type-in-typescript)

package/docs/rules/no-explicit-any.mdx

@@ -1,177 +0,0 @@
----
-description: 'Disallow the `any` type.'
----
-
-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/no-explicit-any** 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.
-This rule reports on explicit uses of the `any` keyword as a type annotation.
-
-Preferable alternatives to `any` include:
-
-- If the type is known, describing it in an `interface` or `type`
-- If the type is not known, using the safer `unknown` type
-
-> TypeScript's `--noImplicitAny` compiler option prevents an implied `any`, but doesn't prevent `any` from being explicitly used the way this rule does.
-
-## Examples
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts
-const age: any = 'seventeen';
-```
-
-```ts
-const ages: any[] = ['seventeen'];
-```
-
-```ts
-const ages: Array<any> = ['seventeen'];
-```
-
-```ts
-function greet(): any {}
-```
-
-```ts
-function greet(): any[] {}
-```
-
-```ts
-function greet(): Array<any> {}
-```
-
-```ts
-function greet(): Array<Array<any>> {}
-```
-
-```ts
-function greet(param: Array<any>): string {}
-```
-
-```ts
-function greet(param: Array<any>): Array<any> {}
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts
-const age: number = 17;
-```
-
-```ts
-const ages: number[] = [17];
-```
-
-```ts
-const ages: Array<number> = [17];
-```
-
-```ts
-function greet(): string {}
-```
-
-```ts
-function greet(): string[] {}
-```
-
-```ts
-function greet(): Array<string> {}
-```
-
-```ts
-function greet(): Array<Array<string>> {}
-```
-
-```ts
-function greet(param: Array<string>): string {}
-```
-
-```ts
-function greet(param: Array<string>): Array<string> {}
-```
-
-</TabItem>
-</Tabs>
-
-## Options
-
-### `fixToUnknown`
-
-{/* insert option description */}
-
-By default, this rule will not provide automatic ESLint _fixes_: only opt-in _suggestions_.
-Switching types to `unknown` is safer but is likely to cause additional type errors.
-
-Enabling `{ "fixToUnknown": true }` gives the rule an auto-fixer to replace `: any` with `: unknown`.
-
-### `ignoreRestArgs`
-
-{/* insert option description */}
-
-The examples below are **incorrect** when `{ignoreRestArgs: false}`, but **correct** when `{ignoreRestArgs: true}`.
-
-```ts option='{ "ignoreRestArgs": false }' showPlaygroundButton
-function foo1(...args: any[]): void {}
-function foo2(...args: readonly any[]): void {}
-function foo3(...args: Array<any>): void {}
-function foo4(...args: ReadonlyArray<any>): void {}
-
-declare function bar(...args: any[]): void;
-
-const baz = (...args: any[]) => {};
-const qux = function (...args: any[]) {};
-
-type Quux = (...args: any[]) => void;
-type Quuz = new (...args: any[]) => void;
-
-interface Grault {
-  (...args: any[]): void;
-}
-interface Corge {
-  new (...args: any[]): void;
-}
-interface Garply {
-  f(...args: any[]): void;
-}
-```
-
-## When Not To Use It
-
-`any` is always a dangerous escape hatch.
-Whenever possible, it is always safer to avoid it.
-TypeScript's `unknown` is almost always preferable to `any`.
-
-However, there are occasional situations where it can be necessary to use `any`.
-Most commonly:
-
-- If your project isn't fully onboarded to TypeScript yet, `any` can be temporarily used in places where types aren't yet known or representable
-- If an external package doesn't yet have typings and you want to use `any` pending adding a `.d.ts` for it
-- You're working with particularly complex or nuanced code that can't yet be represented in the TypeScript type system
-
-You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.
-
-## Related To
-
-- [Avoiding `any`s with Linting and TypeScript](/blog/avoiding-anys)
-- [`no-unsafe-argument`](./no-unsafe-argument.mdx)
-- [`no-unsafe-assignment`](./no-unsafe-assignment.mdx)
-- [`no-unsafe-call`](./no-unsafe-call.mdx)
-- [`no-unsafe-member-access`](./no-unsafe-member-access.mdx)
-- [`no-unsafe-return`](./no-unsafe-return.mdx)
-
-## Further Reading
-
-- TypeScript [`any` type](https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#any)
-- TypeScript's [`unknown` type](https://www.typescriptlang.org/docs/handbook/2/functions.html#unknown)
-- TypeScript [`any` type documentation](https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#any)
-- TypeScript [`unknown` type release notes](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-0.html#new-unknown-top-type)