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

package/docs/rules/no-namespace.mdx

@@ -1,157 +0,0 @@
----
-description: 'Disallow TypeScript namespaces.'
----
-
-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-namespace** for documentation.
-
-TypeScript historically allowed a form of code organization called "custom modules" (`module Example {}`), later renamed to "namespaces" (`namespace Example`).
-Namespaces are an outdated way to organize TypeScript code.
-ES2015 module syntax is now preferred (`import`/`export`).
-
-> This rule does not report on the use of TypeScript module declarations to describe external APIs (`declare module 'foo' {}`).
-
-## Examples
-
-Examples of code with the default options:
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts
-module foo {}
-namespace foo {}
-
-declare module foo {}
-declare namespace foo {}
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts
-declare module 'foo' {}
-
-// anything inside a d.ts file
-```
-
-</TabItem>
-</Tabs>
-
-## Options
-
-### `allowDeclarations`
-
-{/* insert option description */}
-
-Examples of code with the `{ "allowDeclarations": true }` option:
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts option='{ "allowDeclarations": true }'
-module foo {}
-namespace foo {}
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts option='{ "allowDeclarations": true }'
-declare module 'foo' {}
-declare module foo {}
-declare namespace foo {}
-
-declare global {
-  namespace foo {}
-}
-
-declare module foo {
-  namespace foo {}
-}
-```
-
-</TabItem>
-</Tabs>
-
-Examples of code for the `{ "allowDeclarations": false }` option:
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts option='{ "allowDeclarations": false }'
-module foo {}
-namespace foo {}
-declare module foo {}
-declare namespace foo {}
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts option='{ "allowDeclarations": false }'
-declare module 'foo' {}
-```
-
-</TabItem>
-</Tabs>
-
-### `allowDefinitionFiles`
-
-{/* insert option description */}
-
-Examples of code for the `{ "allowDefinitionFiles": true }` option:
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts option='{ "allowDefinitionFiles": true }'
-// if outside a d.ts file
-module foo {}
-namespace foo {}
-
-// if outside a d.ts file and allowDeclarations = false
-module foo {}
-namespace foo {}
-declare module foo {}
-declare namespace foo {}
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts option='{ "allowDefinitionFiles": true }'
-declare module 'foo' {}
-
-// anything inside a d.ts file
-```
-
-</TabItem>
-</Tabs>
-
-## When Not To Use It
-
-If your project uses TypeScript's CommonJS export syntax (`export = ...`), you may need to use namespaces in order to export types from your module.
-You can learn more about this at:
-
-- [TypeScript#52203](https://github.com/microsoft/TypeScript/pull/52203), the pull request introducing [`verbatimModuleSyntax`](https://www.typescriptlang.org/tsconfig/#verbatimModuleSyntax)
-- [TypeScript#60852](https://github.com/microsoft/TypeScript/issues/60852), an issue requesting syntax to export types from a CommonJS module.
-
-If your project uses this syntax, either because it was architected before modern modules and namespaces, or because a module option such as `verbatimModuleSyntax` requires it, it may be difficult to migrate off of namespaces.
-In that case you may not be able to use this rule for parts of your project.
-
-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.
-
-## Further Reading
-
-{/* cspell:disable-next-line */}
-
-- [FAQ: I get errors from the `@typescript-eslint/no-namespace` and/or `no-var` rules about declaring global variables](/troubleshooting/faqs/eslint#i-get-errors-from-the-typescript-eslintno-namespace-andor-no-var-rules-about-declaring-global-variables)
-- [FAQ: How should I handle reports that conflict with verbatimModuleSyntax?](/troubleshooting/faqs/typescript#how-should-i-handle-reports-that-conflict-with-verbatimmodulesyntax)
-- [TypeScript handbook entry on Modules](https://www.typescriptlang.org/docs/handbook/modules.html)
-- [TypeScript handbook entry on Namespaces](https://www.typescriptlang.org/docs/handbook/namespaces.html)
-- [TypeScript handbook entry on Namespaces and Modules](https://www.typescriptlang.org/docs/handbook/namespaces-and-modules.html)

package/docs/rules/no-non-null-asserted-nullish-coalescing.mdx

@@ -1,60 +0,0 @@
----
-description: 'Disallow non-null assertions in the left operand of a nullish coalescing operator.'
----
-
-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-non-null-asserted-nullish-coalescing** for documentation.
-
-The `??` nullish coalescing runtime operator allows providing a default value when dealing with `null` or `undefined`.
-Using a `!` non-null assertion type operator in the left operand of a nullish coalescing operator is redundant, and likely a sign of programmer error or confusion over the two operators.
-
-## Examples
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts
-foo! ?? bar;
-foo.bazz! ?? bar;
-foo!.bazz! ?? bar;
-foo()! ?? bar;
-
-let x!: string;
-x! ?? '';
-
-let x: string;
-x = foo();
-x! ?? '';
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts
-foo ?? bar;
-foo ?? bar!;
-foo!.bazz ?? bar;
-foo!.bazz ?? bar!;
-foo() ?? bar;
-
-// This is considered correct code because there's no way for the user to satisfy it.
-let x: string;
-x! ?? '';
-```
-
-</TabItem>
-</Tabs>
-
-## When Not To Use It
-
-If your project's types don't yet fully describe whether certain values may be nullable, such as if you're transitioning to `strictNullChecks`, this rule might create many false reports.
-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.
-
-## Further Reading
-
-- [TypeScript 3.7 Release Notes](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html)
-- [Nullish Coalescing Proposal](https://github.com/tc39/proposal-nullish-coalescing)

package/docs/rules/no-non-null-asserted-optional-chain.mdx

@@ -1,46 +0,0 @@
----
-description: 'Disallow non-null assertions after an optional chain expression.'
----
-
-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-non-null-asserted-optional-chain** for documentation.
-
-`?.` optional chain expressions provide `undefined` if an object is `null` or `undefined`.
-Using a `!` non-null assertion to assert the result of an `?.` optional chain expression is non-nullable is likely wrong.
-
-> Most of the time, either the object was not nullable and did not need the `?.` for its property lookup, or the `!` is incorrect and introducing a type safety hole.
-
-## Examples
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts
-foo?.bar!;
-foo?.bar()!;
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts
-foo?.bar;
-foo?.bar();
-```
-
-</TabItem>
-</Tabs>
-
-## When Not To Use It
-
-If your project's types don't yet fully describe whether certain values may be nullable, such as if you're transitioning to `strictNullChecks`, this rule might create many false reports.
-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.
-
-## Further Reading
-
-- [TypeScript 3.7 Release Notes](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html)
-- [Optional Chaining Proposal](https://github.com/tc39/proposal-optional-chaining/)

package/docs/rules/no-non-null-assertion.mdx

@@ -1,48 +0,0 @@
----
-description: 'Disallow non-null assertions using the `!` postfix operator.'
----
-
-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-non-null-assertion** for documentation.
-
-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.
-
-## Examples
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts
-interface Example {
-  property?: string;
-}
-
-declare const example: Example;
-const includesBaz = example.property!.includes('baz');
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts
-interface Example {
-  property?: string;
-}
-
-declare const example: Example;
-const includesBaz = example.property?.includes('baz') ?? false;
-```
-
-</TabItem>
-</Tabs>
-
-## When Not To Use It
-
-If your project's types don't yet fully describe whether certain values may be nullable, such as if you're transitioning to `strictNullChecks`, this rule might create many false reports.
-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.

package/docs/rules/no-parameter-properties.mdx

@@ -1,16 +0,0 @@
----
-displayed_sidebar: rulesSidebar
----
-
-:::danger Deprecated
-
-This rule has been deprecated in favour of the [`parameter-properties`](https://typescript-eslint.io/rules/parameter-properties/) rule.
-
-:::
-
-<!--
-This doc file has been left on purpose to help direct people to the replacement rule.
-
-Note that there is no actual way to get to this page in the normal navigation,
-so end-users will only be able to get to this page from the search bar.
--->

package/docs/rules/no-redeclare.mdx

@@ -1,79 +0,0 @@
----
-description: 'Disallow variable redeclaration.'
----
-
-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-redeclare** for documentation.
-
-import TypeScriptOverlap from '@site/src/components/TypeScriptOverlap';
-
-<TypeScriptOverlap />
-
-It adds support for TypeScript function overloads, and declaration merging.
-
-## Options
-
-This rule adds the following options:
-
-```ts
-interface Options extends BaseNoRedeclareOptions {
-  ignoreDeclarationMerge?: boolean;
-}
-
-const defaultOptions: Options = {
-  ...baseNoRedeclareDefaultOptions,
-  ignoreDeclarationMerge: true,
-};
-```
-
-### `ignoreDeclarationMerge`
-
-{/* insert option description */}
-
-The following sets will be ignored when this option is enabled:
-
-- interface + interface
-- namespace + namespace
-- class + interface
-- class + namespace
-- class + interface + namespace
-- function + namespace
-- enum + namespace
-
-Examples of **correct** code with `{ ignoreDeclarationMerge: true }`:
-
-```ts option='{ "ignoreDeclarationMerge": true }' showPlaygroundButton
-interface A {
-  prop1: 1;
-}
-interface A {
-  prop2: 2;
-}
-
-namespace Foo {
-  export const a = 1;
-}
-namespace Foo {
-  export const b = 2;
-}
-
-class Bar {}
-namespace Bar {}
-
-function Baz() {}
-namespace Baz {}
-```
-
-**Note:** Even with this option set to true, this rule will report if you name a type and a variable the same name. **_This is intentional_**.
-Declaring a variable and a type the same is usually an accident, and it can lead to hard-to-understand code.
-If you have a rare case where you're intentionally naming a type the same name as a variable, use a disable comment. For example:
-
-```ts option='{ "ignoreDeclarationMerge": true }' showPlaygroundButton
-type something = string;
-// eslint-disable-next-line @typescript-eslint/no-redeclare -- intentionally naming the variable the same as the type
-const something = 2;
-```

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

@@ -1,102 +0,0 @@
----
-description: 'Disallow members of unions and intersections that do nothing or override type information.'
----
-
-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-redundant-type-constituents** for documentation.
-
-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.
-
-Within `|` unions:
-
-- `any` and `unknown` "override" all other union members
-- `never` is dropped from unions in any position except when in a return type position
-- primitive types such as `string` "override" any of their literal types such as `""`
-
-Within `&` intersections:
-
-- `any` and `never` "override" all other intersection members
-- `unknown` is dropped from intersections
-- literal types "override" any primitive types in an intersection
-- literal types such as `""` "override" any of their primitive types such as `string`
-
-## Examples
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts
-type UnionAny = any | 'foo';
-type UnionUnknown = unknown | 'foo';
-type UnionNever = never | 'foo';
-
-type UnionBooleanLiteral = boolean | false;
-type UnionNumberLiteral = number | 1;
-type UnionStringLiteral = string | 'foo';
-
-type IntersectionAny = any & 'foo';
-type IntersectionUnknown = string & unknown;
-type IntersectionNever = string | never;
-
-type IntersectionBooleanLiteral = boolean & false;
-type IntersectionNumberLiteral = number & 1;
-type IntersectionStringLiteral = string & 'foo';
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts
-type UnionAny = any;
-type UnionUnknown = unknown;
-type UnionNever = never;
-
-type UnionBooleanLiteral = boolean;
-type UnionNumberLiteral = number;
-type UnionStringLiteral = string;
-
-type IntersectionAny = any;
-type IntersectionUnknown = string;
-type IntersectionNever = string;
-
-type IntersectionBooleanLiteral = false;
-type IntersectionNumberLiteral = 1;
-type IntersectionStringLiteral = 'foo';
-```
-
-</TabItem>
-</Tabs>
-
-## Limitations
-
-This rule plays it safe and only works with bottom types, top types, and comparing literal types to primitive types.
-
-## When Not To Use It
-
-Some projects choose to occasionally intentionally include a redundant type constituent for documentation purposes.
-For example, the following code includes `string` in a union even though the `unknown` makes it redundant:
-
-```ts
-/**
- * Normally a string name, but sometimes arbitrary unknown data.
- */
-type NameOrOther = string | unknown;
-```
-
-If you strongly feel a preference for these unnecessary type constituents, this rule might not be for you.
-
-## Further Reading
-
-- [Union Types](https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#union-types)
-- [Intersection Types](https://www.typescriptlang.org/docs/handbook/2/objects.html#intersection-types)
-- [Bottom Types](https://en.wikipedia.org/wiki/Bottom_type)
-- [Top Types](https://en.wikipedia.org/wiki/Top_type)
-
-## Related To
-
-- [no-duplicate-type-constituents](./no-duplicate-type-constituents.mdx)

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

@@ -1,114 +0,0 @@
----
-description: 'Disallow invocation of `require()`.'
----
-
-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-require-imports** for documentation.
-
-Depending on your TSConfig settings and whether you're authoring ES Modules or CommonJS, TS may allow both `import` and `require()` to be used, even within a single file.
-
-This rule enforces that you use the newer ES Module `import` syntax over CommonJS `require()`.
-
-## Examples
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts
-const lib1 = require('lib1');
-const { lib2 } = require('lib2');
-import lib3 = require('lib3');
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts
-import * as lib1 from 'lib1';
-import { lib2 } from 'lib2';
-import * as lib3 from 'lib3';
-```
-
-</TabItem>
-</Tabs>
-
-## Options
-
-### `allow`
-
-{/* insert option description */}
-
-These strings will be compiled into regular expressions with the `u` flag and be used to test against the imported path. A common use case is to allow importing `package.json`. This is because `package.json` commonly lives outside of the TS root directory, so statically importing it would lead to root directory conflicts, especially with `resolveJsonModule` enabled. You can also use it to allow importing any JSON if your environment doesn't support JSON modules, or use it for other cases where `import` statements cannot work.
-
-With `{ allow: ['/package\\.json$'] }`:
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts option='{ "allow": ["/package.json$"] }'
-console.log(require('../data.json').version);
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts option='{ "allow": ["/package.json$"] }'
-console.log(require('../package.json').version);
-```
-
-</TabItem>
-</Tabs>
-
-### `allowAsImport`
-
-{/* insert option description */}
-
-When set to `true`, `import ... = require(...)` declarations won't be reported.
-This is beneficial if you use certain module options that require strict CommonJS interop semantics, such as [verbatimModuleSyntax](https://www.typescriptlang.org/tsconfig/#verbatimModuleSyntax).
-
-With `{ allowAsImport: true }`:
-
-<Tabs>
-<TabItem value="❌ Incorrect">
-
-```ts option='{ "allowAsImport": true }'
-var foo = require('foo');
-const foo = require('foo');
-let foo = require('foo');
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts option='{ "allowAsImport": true }'
-import foo = require('foo');
-import foo from 'foo';
-```
-
-</TabItem>
-</Tabs>
-
-## Usage with CommonJS
-
-While this rule is primarily intended to promote ES Module syntax, it still makes sense to enable this rule when authoring CommonJS modules.
-
-If you prefer to use TypeScript's built-in `import ... from ...` ES Module syntax, which is transformed to `require()` calls during transpilation when outputting CommonJS, you can use the rule's default behavior.
-
-If, instead, you prefer to use `require()` syntax, we recommend you use this rule with [`allowAsImport`](#allowAsImport) enabled.
-That way, you still enforce usage of `import ... = require(...)` rather than bare `require()` calls, which are not statically analyzed by TypeScript.
-We don't directly a way to _prohibit_ ES Module syntax from being used; consider instead using TypeScript's [`verbatimModuleSyntax`](https://www.typescriptlang.org/tsconfig/#verbatimModuleSyntax) option if you find yourself in a situation where you would want this.
-
-## When Not To Use It
-
-If you are authoring CommonJS modules _and_ your project frequently uses dynamic `require`s, then this rule might not be applicable to you.
-Otherwise the `allowAsImport` option probably suits your needs.
-
-If only a subset of your project uses dynamic `require`s 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.
-
-## Related To
-
-- [`no-var-requires`](./no-var-requires.mdx)