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

package/docs/rules/no-restricted-imports.mdx

@@ -1,84 +0,0 @@
----
-description: 'Disallow specified modules when loaded by `import`.'
----
-
-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-restricted-imports** for documentation.
-
-It adds support for type import syntaxes:
-
-- `import type X from "..."`
-- `import { type X } from "..."`
-- `import x = require("...")`
-
-## Options
-
-This rule adds the following options:
-
-### `allowTypeImports`
-
-{/* insert option description */}
-
-Whether to allow type-only imports for a path.
-Default: `false`.
-
-You can specify this option for a specific path or pattern as follows:
-
-```jsonc
-{
-  "rules": {
-    "@typescript-eslint/no-restricted-imports": [
-      "error",
-      {
-        "paths": [
-          {
-            "name": "import-foo",
-            "message": "Please use import-bar instead.",
-            "allowTypeImports": true,
-          },
-          {
-            "name": "import-baz",
-            "message": "Please use import-quux instead.",
-            "allowTypeImports": true,
-          },
-        ],
-      },
-    ],
-  },
-}
-```
-
-Whether to allow [Type-Only Imports](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-8.html#type-only-imports-and-export).
-
-Examples of code with the above config:
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts option='{"paths":[{"name":"import-foo","message":"Please use import-bar instead.","allowTypeImports":true},{"name":"import-baz","message":"Please use import-quux instead.","allowTypeImports":true}]}'
-import foo from 'import-foo';
-export { Foo } from 'import-foo';
-
-import baz from 'import-baz';
-export { Baz } from 'import-baz';
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts option='{"paths":[{"name":"import-foo","message":"Please use import-bar instead.","allowTypeImports":true},{"name":"import-baz","message":"Please use import-quux instead.","allowTypeImports":true}]}'
-import { foo } from 'other-module';
-
-import type foo from 'import-foo';
-export type { Foo } from 'import-foo';
-
-import type baz from 'import-baz';
-export type { Baz } from 'import-baz';
-```
-
-</TabItem>
-</Tabs>

package/docs/rules/no-restricted-types.mdx

@@ -1,70 +0,0 @@
----
-description: 'Disallow certain 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-restricted-types** for documentation.
-
-It can sometimes be useful to ban specific types from being used in type annotations.
-For example, a project might be migrating from using one type to another, and want to ban references to the old type.
-
-This rule can be configured to ban a list of specific types and can suggest alternatives.
-Note that it does not ban the corresponding runtime objects from being used.
-
-## Options
-
-### `types`
-
-{/* insert option description */}
-
-The type can either be a type name literal (`OldType`) or a a type name with generic parameter instantiation(s) (`OldType<MyArgument>`).
-
-The values can be:
-
-- A string, which is the error message to be reported; 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.
-  - `suggest?: string[]`: a list of suggested replacements for the banned type.
-
-Example configuration:
-
-```jsonc
-{
-  "@typescript-eslint/no-restricted-types": [
-    "error",
-    {
-      "types": {
-        // add a custom message to help explain why not to use it
-        "OldType": "Don't use OldType because it is unsafe",
-
-        // add a custom message, and tell the plugin how to fix it
-        "OldAPI": {
-          "message": "Use NewAPI instead",
-          "fixWith": "NewAPI",
-        },
-
-        // add a custom message, and tell the plugin how to suggest a fix
-        "SoonToBeOldAPI": {
-          "message": "Use NewAPI instead",
-          "suggest": ["NewAPIOne", "NewAPITwo"],
-        },
-      },
-    },
-  ],
-}
-```
-
-## When Not To Use It
-
-If you have no need to ban specific types from being used in type annotations, you don't need this rule.
-
-## Related To
-
-- [`no-empty-object-type`](./no-empty-object-type.mdx)
-- [`no-unsafe-function-type`](./no-unsafe-function-type.mdx)
-- [`no-wrapper-object-types`](./no-wrapper-object-types.mdx)

package/docs/rules/no-shadow.mdx

@@ -1,143 +0,0 @@
----
-description: 'Disallow variable declarations from shadowing variables declared in the outer scope.'
----
-
-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-shadow** for documentation.
-
-It adds support for TypeScript's `this` parameters and global augmentation, and adds options for TypeScript features.
-
-## Options
-
-This rule adds the following options:
-
-```ts
-type AdditionalHoistOptionEntries = 'types' | 'functions-and-types';
-
-type HoistOptionEntries =
-  | BaseNoShadowHoistOptionEntries
-  | AdditionalHoistOptionEntries;
-
-interface Options extends BaseNoShadowOptions {
-  hoist?: HoistOptionEntries;
-  ignoreTypeValueShadow?: boolean;
-  ignoreFunctionTypeParameterNameValueShadow?: boolean;
-}
-
-const defaultOptions: Options = {
-  ...baseNoShadowDefaultOptions,
-  hoist: 'functions-and-types',
-  ignoreTypeValueShadow: true,
-  ignoreFunctionTypeParameterNameValueShadow: true,
-};
-```
-
-### hoist: `types`
-
-Examples of incorrect code for the `{ "hoist": "types" }` option:
-
-```ts option='{ "hoist": "types" }' showPlaygroundButton
-type Bar<Foo> = 1;
-type Foo = 1;
-```
-
-### hoist: `functions-and-types`
-
-Examples of incorrect code for the `{ "hoist": "functions-and-types" }` option:
-
-```ts option='{ "hoist": "functions-and-types" }' showPlaygroundButton
-// types
-type Bar<Foo> = 1;
-type Foo = 1;
-
-// functions
-if (true) {
-  let b = 6;
-}
-
-function b() {}
-```
-
-### `ignoreTypeValueShadow`
-
-{/* insert option description */}
-
-This is generally safe because you cannot use variables in type locations without a `typeof` operator, so there's little risk of confusion.
-
-Examples of **correct** code with `{ ignoreTypeValueShadow: true }`:
-
-```ts option='{ "ignoreTypeValueShadow": true }' showPlaygroundButton
-type Foo = number;
-interface Bar {
-  prop: number;
-}
-
-function f() {
-  const Foo = 1;
-  const Bar = 'test';
-}
-```
-
-:::note
-
-_Shadowing_ specifically refers to two identical identifiers that are in different, nested scopes. This is different from _redeclaration_, which is when two identical identifiers are in the same scope. Redeclaration is covered by the [`no-redeclare`](./no-redeclare.mdx) rule instead.
-
-:::
-
-### `ignoreFunctionTypeParameterNameValueShadow`
-
-{/* insert option description */}
-
-Each of a function type's arguments creates a value variable within the scope of the function type. This is done so that you can reference the type later using the `typeof` operator:
-
-```ts
-type Func = (test: string) => typeof test;
-
-declare const fn: Func;
-const result = fn('str'); // typeof result === string
-```
-
-This means that function type arguments shadow value variable names in parent scopes:
-
-```ts
-let test = 1;
-type TestType = typeof test; // === number
-type Func = (test: string) => typeof test; // this "test" references the argument, not the variable
-
-declare const fn: Func;
-const result = fn('str'); // typeof result === string
-```
-
-If you do not use the `typeof` operator in a function type return type position, you can safely turn this option on.
-
-Examples of **correct** code with `{ ignoreFunctionTypeParameterNameValueShadow: true }`:
-
-```ts option='{ "ignoreFunctionTypeParameterNameValueShadow": true }' showPlaygroundButton
-const test = 1;
-type Func = (test: string) => typeof test;
-```
-
-## FAQ
-
-### Why does the rule report on enum members that share the same name as a variable in a parent scope?
-
-Reporting on this case isn't a bug - it is completely intentional and correct reporting! The rule reports due to a relatively unknown feature of enums - enum members create a variable within the enum scope so that they can be referenced within the enum without a qualifier.
-
-To illustrate this with an example:
-
-```ts
-const A = 2;
-enum Test {
-  A = 1,
-  B = A,
-}
-
-console.log(Test.B);
-// what should be logged?
-```
-
-Naively looking at the above code, it might look like the log should output `2`, because the outer variable `A`'s value is `2` - however, the code instead outputs `1`, which is the value of `Test.A`. This is because the unqualified code `B = A` is equivalent to the fully-qualified code `B = Test.A`. Due to this behavior, the enum member has **shadowed** the outer variable declaration.

package/docs/rules/no-this-alias.mdx

@@ -1,124 +0,0 @@
----
-description: 'Disallow aliasing `this`.'
----
-
-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-this-alias** for documentation.
-
-Assigning a variable to `this` instead of properly using arrow lambdas may be a symptom of pre-ES6 practices
-or not managing scope well.
-
-## Examples
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts
-const self = this;
-
-setTimeout(function () {
-  self.doWork();
-});
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts
-setTimeout(() => {
-  this.doWork();
-});
-```
-
-</TabItem>
-</Tabs>
-
-## Options
-
-### `allowDestructuring`
-
-{/* insert option description */}
-
-It can sometimes be useful to destructure properties from a class instance, such as retrieving multiple properties from the instance in one of its methods.
-`allowDestructuring` allows those destructures and is `true` by default.
-You can explicitly disallow them by setting `allowDestructuring` to `false`.
-
-Examples of code for the `{ "allowDestructuring": false }` option:
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts option='{ "allowDestructuring": false }'
-class ComponentLike {
-  props: unknown;
-  state: unknown;
-
-  render() {
-    const { props, state } = this;
-
-    console.log(props);
-    console.log(state);
-  }
-}
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts option='{ "allowDestructuring": false }'
-class ComponentLike {
-  props: unknown;
-  state: unknown;
-
-  render() {
-    console.log(this.props);
-    console.log(this.state);
-  }
-}
-```
-
-</TabItem>
-</Tabs>
-
-### `allowedNames`
-
-{/* insert option description */}
-
-`no-this-alias` can alternately be used to allow only a specific list of names as `this` aliases.
-We recommend against this except as a transitory step towards fixing all rule violations.
-
-Examples of code for the `{ "allowedNames": ["self"] }` option:
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts option='{ "allowedNames": ["self"] }'
-class Example {
-  method() {
-    const that = this;
-  }
-}
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts option='{ "allowedNames": ["self"] }'
-class Example {
-  method() {
-    const self = this;
-  }
-}
-```
-
-</TabItem>
-</Tabs>
-
-## When Not To Use It
-
-If your project is structured in a way that it needs to assign `this` to variables, this rule is likely not for you.
-If only a subset of your project assigns `this` to variables then 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.