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

package/docs/rules/consistent-indexed-object-style.mdx

@@ -1,105 +0,0 @@
----
-description: 'Require or disallow the `Record` 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/consistent-indexed-object-style** for documentation.
-
-TypeScript supports defining arbitrary object keys using an index signature or mapped type.
-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:
-
-```ts
-interface IndexSignatureInterface {
-  [key: string]: unknown;
-}
-
-type IndexSignatureType = {
-  [key: string]: unknown;
-};
-
-type MappedType = {
-  [key in string]: unknown;
-};
-
-type RecordType = Record<string, unknown>;
-```
-
-Using one declaration form consistently improves code readability.
-
-## Options
-
-- `'record'` _(default)_: only allow the `Record` type.
-- `'index-signature'`: only allow index signatures.
-
-### `'record'`
-
-{/* insert option description */}
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts option='"record"'
-interface IndexSignatureInterface {
-  [key: string]: unknown;
-}
-
-type IndexSignatureType = {
-  [key: string]: unknown;
-};
-
-type MappedType = {
-  [key in string]: unknown;
-};
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts option='"record"'
-type RecordType = Record<string, unknown>;
-```
-
-</TabItem>
-</Tabs>
-
-### `'index-signature'`
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts option='"index-signature"'
-type RecordType = Record<string, unknown>;
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts option='"index-signature"'
-interface IndexSignatureInterface {
-  [key: string]: unknown;
-}
-
-type IndexSignatureType = {
-  [key: string]: unknown;
-};
-
-type MappedType = {
-  [key in string]: unknown;
-};
-```
-
-</TabItem>
-</Tabs>
-
-## When Not To Use It
-
-This rule is purely a stylistic rule for maintaining consistency in your project.
-You can turn it off if you don't want to keep a consistent style for indexed object types.
-
-However, keep in mind that inconsistent style can harm readability in a project.
-We recommend picking a single option for this rule that works best for your project.

package/docs/rules/consistent-return.mdx

@@ -1,51 +0,0 @@
----
-description: 'Require `return` statements to either always or never specify values.'
----
-
-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/consistent-return** for documentation.
-
-It adds support for functions that return `void` or `Promise<void>`.
-
-:::danger warning
-If possible, it is recommended to use tsconfig's [`noImplicitReturns`](https://www.typescriptlang.org/tsconfig/#noImplicitReturns) option rather than this rule. `noImplicitReturns` is powered by TS's type information and control-flow analysis so it has better coverage than this rule.
-:::
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts
-function foo(): undefined {}
-function bar(flag: boolean): undefined {
-  if (flag) return foo();
-  return;
-}
-
-async function baz(flag: boolean): Promise<undefined> {
-  if (flag) return;
-  return foo();
-}
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts
-function foo(): void {}
-function bar(flag: boolean): void {
-  if (flag) return foo();
-  return;
-}
-
-async function baz(flag: boolean): Promise<void | number> {
-  if (flag) return 42;
-  return;
-}
-```
-
-</TabItem>
-</Tabs>

package/docs/rules/consistent-type-assertions.mdx

@@ -1,196 +0,0 @@
----
-description: 'Enforce consistent usage of type assertions.'
----
-
-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/consistent-type-assertions** for documentation.
-
-TypeScript provides two syntaxes for "type assertions":
-
-- Angle brackets: `<Type>value`
-- As: `value as Type`
-
-This rule aims to standardize the use of type assertion style across the codebase.
-Keeping to one syntax consistently helps with code readability.
-
-:::note
-Type assertions are also commonly referred as "type casting" in TypeScript.
-However, that term is technically slightly different to what is understood by type casting in other languages.
-Type assertions are a way to say to the TypeScript compiler, _"I know better than you, it's actually this different type!"_.
-:::
-
-[`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
-
-### `assertionStyle`
-
-{/* 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>...`
-- `never` will enforce that you do not do any type assertions.
-
-Most codebases will want to enforce not using `angle-bracket` style because it conflicts with JSX syntax, and is confusing when paired with generic syntax.
-
-Some codebases like to go for an extra level of type safety, and ban assertions altogether via the `never` option.
-
-### `objectLiteralTypeAssertions`
-
-{/* 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.
-
-The compiler will warn for excess properties with this syntax, but not missing _required_ fields. For example: `const x: { foo: number } = {};` will fail to compile, but `const x = {} as { foo: number }` will succeed.
-
-The const assertion `const x = { foo: 1 } as const`, introduced in TypeScript 3.4, is considered beneficial and is ignored by this option.
-
-Assertions to `any` are also ignored by this option.
-
-Examples of code for `{ assertionStyle: 'as', objectLiteralTypeAssertions: 'never' }`:
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts option='{ "assertionStyle": "as", "objectLiteralTypeAssertions": "never" }'
-const x = { foo: 1 } as T;
-
-function bar() {
-  return { foo: 1 } as T;
-}
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts option='{ "assertionStyle": "as", "objectLiteralTypeAssertions": "never" }'
-const x: T = { foo: 1 };
-const y = { foo: 1 } as any;
-const z = { foo: 1 } as unknown;
-
-function bar(): T {
-  return { foo: 1 };
-}
-```
-
-</TabItem>
-</Tabs>
-
-Examples of code for `{ assertionStyle: 'as', objectLiteralTypeAssertions: 'allow-as-parameter' }`:
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts option='{ "assertionStyle": "as", "objectLiteralTypeAssertions": "allow-as-parameter" }'
-const x = { foo: 1 } as T;
-
-function bar() {
-  return { foo: 1 } as T;
-}
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```tsx option='{ "assertionStyle": "as", "objectLiteralTypeAssertions": "allow-as-parameter" }'
-const x: T = { foo: 1 };
-const y = { foo: 1 } as any;
-const z = { foo: 1 } as unknown;
-bar({ foo: 1 } as T);
-new Clazz({ foo: 1 } as T);
-function bar() {
-  throw { foo: 1 } as Foo;
-}
-const foo = <Foo props={{ bar: 1 } as Bar} />;
-```
-
-</TabItem>
-</Tabs>
-
-### `arrayLiteralTypeAssertions`
-
-{/* insert option description */}
-
-For example, this would prefer `const x: T[] = [ ... ];` to `const x = [ ... ] as T[];` (or similar with angle brackets).
-
-The compiler will warn for excess properties of elements with this syntax, but not missing _required_ fields of those objects.
-For example: `const x: {foo: number}[] = [{}];` will fail to compile, but `const x = [{}] as [{ foo: number }]` will succeed.
-
-The const assertion `const x = [1, 2, 3] as const`, introduced in TypeScript 3.4, is considered beneficial and is ignored by this option.
-
-Assertions to `any` are also ignored by this option.
-
-Examples of code for `{ assertionStyle: 'as', arrayLiteralTypeAssertions: 'never' }`:
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts option='{ "assertionStyle": "as", "arrayLiteralTypeAssertions": "never" }'
-const x = ['foo'] as T;
-
-function bar() {
-  return ['foo'] as T;
-}
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts option='{ "assertionStyle": "as", "arrayLiteralTypeAssertions": "never" }'
-const x: T = ['foo'];
-const y = ['foo'] as any;
-const z = ['foo'] as unknown;
-
-function bar(): T {
-  return ['foo'];
-}
-```
-
-</TabItem>
-</Tabs>
-
-Examples of code for `{ assertionStyle: 'as', arrayLiteralTypeAssertions: 'allow-as-parameter' }`:
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts option='{ "assertionStyle": "as", "arrayLiteralTypeAssertions": "allow-as-parameter" }'
-const x = ['foo'] as T;
-
-function bar() {
-  return ['foo'] as T;
-}
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```tsx option='{ "assertionStyle": "as", "arrayLiteralTypeAssertions": "allow-as-parameter" }'
-const x: T = ['foo'];
-const y = ['foo'] as any;
-const z = ['foo'] as unknown;
-bar(['foo'] as T);
-new Clazz(['foo'] as T);
-function bar() {
-  throw ['foo'] as Foo;
-}
-const foo = <Foo props={['foo'] as Bar} />;
-```
-
-</TabItem>
-</Tabs>
-
-## When Not To Use It
-
-If you do not want to enforce consistent type assertions.
-
-However, keep in mind that inconsistent style can harm readability in a project.
-We recommend picking a single option for this rule that works best for your project.

package/docs/rules/consistent-type-definitions.mdx

@@ -1,133 +0,0 @@
----
-description: 'Enforce type definitions to consistently use either `interface` or `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/consistent-type-definitions** for documentation.
-
-TypeScript provides two common ways to define an object type: `interface` and `type`.
-
-```ts
-// type alias
-type T1 = {
-  a: string;
-  b: number;
-};
-
-// interface keyword
-interface T2 {
-  a: string;
-  b: number;
-}
-```
-
-The two are generally very similar, and can often be used interchangeably.
-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'`
-
-{/* insert option description */}
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts option='"interface"'
-type T = { x: number };
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts option='"interface"'
-type T = string;
-type Foo = string | {};
-
-interface T {
-  x: number;
-}
-```
-
-</TabItem>
-</Tabs>
-
-### `'type'`
-
-{/* insert option description */}
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts option='"type"'
-interface T {
-  x: number;
-}
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts option='"type"'
-type T = { x: number };
-```
-
-</TabItem>
-</Tabs>
-
-## FAQs
-
-### What are the differences between `interface` and `type`?
-
-There are very few differences between interfaces and object types in TypeScript.
-Other than type aliases being used to represent union types, it is rare that you will need to choose one over the other.
-
-| Feature               | Interfaces | Object Types | Explanation                                                                                            |
-| --------------------- | ---------- | ------------ | ------------------------------------------------------------------------------------------------------ |
-| Object shapes         | ✅         | ✅           | Both can be used to represent general object shapes.                                                   |
-| General performance   | ✅         | ✅           | Both are optimized for performance in TypeScript's type checker.                                       |
-| Edge case performance | ✅         |              | Large, complex logical types can be optimized better with interfaces by TypeScript's type checker.     |
-| Traditional semantics | ✅         |              | Interfaces are typically the default in much -though not all- of the TypeScript community.             |
-| Non-object shapes     |            | ✅           | Object types may describe literals, primitives, unions, and intersections.                             |
-| Logical types         |            | ✅           | Object types may include conditional and mapped types.                                                 |
-| Merging               | Allowed    | Not allowed  | Interfaces of the same name are treated as one interface ("merged"); type aliases may not share names. |
-
-We recommend choosing one definition style, using it when possible, and falling back to the other style when needed.
-The benefits of remaining consistent within a codebase almost always outweigh the benefits of either definition style.
-
-### When do the performance differences between `interface` and `type` matter?
-
-Almost never.
-Most TypeScript projects do not -and should not- utilize types that exercise the performance differences between the two kinds of definitions.
-
-If you are having problems with type checking performance, see the [TypeScript Wiki's Performance page](https://github.com/microsoft/TypeScript/wiki/Performance).
-
-### Why is the default `interface`?
-
-Interfaces are the prevailing, most common style in the TypeScript.
-`interface` has traditionally been TypeScript's intended ("semantic") way to convey _"an object with these fields"_.
-
-We generally recommend staying with the default, `'interface'`, to be stylistically consistent with the majority of TypeScript projects.
-If you strongly prefer `'type'`, that's fine too.
-
-## When Not To Use It
-
-If you specifically want to manually choose whether to use an interface or type literal for stylistic reasons each time you define a type, you can avoid this rule.
-
-However, keep in mind that inconsistent style can harm readability in a project.
-We recommend picking a single option for this rule that works best for your project.
-
-You might occasionally need to a different definition type in specific cases, such as if your project is a dependency or dependent of another project that relies on a specific type definition style.
-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.
-
-## Further Reading
-
-- [TypeScript Handbook > Everyday Types > Differences Between Type Aliases and Interfaces](https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#differences-between-type-aliases-and-interfaces)
-- [StackOverflow: Interfaces vs Types in TypeScript](https://stackoverflow.com/questions/37233735/interfaces-vs-types-in-typescript)

package/docs/rules/consistent-type-exports.mdx

@@ -1,97 +0,0 @@
----
-description: 'Enforce consistent usage of type exports.'
----
-
-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/consistent-type-exports** for documentation.
-
-TypeScript allows specifying a `type` keyword on exports to indicate that the export exists only in the type system, not at runtime.
-This allows transpilers to drop exports without knowing the types of the dependencies.
-
-> See [Blog > Consistent Type Exports and Imports: Why and How](/blog/consistent-type-imports-and-exports-why-and-how) for more details.
-
-## Examples
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts
-interface ButtonProps {
-  onClick: () => void;
-}
-
-class Button implements ButtonProps {
-  onClick = () => console.log('button!');
-}
-
-export { Button, ButtonProps };
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts
-interface ButtonProps {
-  onClick: () => void;
-}
-
-class Button implements ButtonProps {
-  onClick = () => console.log('button!');
-}
-
-export { Button };
-export type { ButtonProps };
-```
-
-</TabItem>
-</Tabs>
-
-## Options
-
-### `fixMixedExportsWithInlineTypeSpecifier`
-
-{/* 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:
-
-```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 };
-```
-
-## When Not To Use It
-
-If you use `--isolatedModules` the compiler would error if a type is not re-exported using `export type`.
-This rule may be less useful in those cases.
-
-If you specifically want to use both export kinds for stylistic reasons, or don't wish to enforce one style over the other, you can avoid this rule.
-
-However, keep in mind that inconsistent style can harm readability in a project.
-We recommend picking a single option for this rule that works best for your project.