@alexlit/lint-kit 112.0.0 → 112.1.0

package/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-namespace.mdx

@@ -1,142 +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`
-
-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`
-
-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 was architected before modern modules and namespaces, 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
-
-- [Modules](https://www.typescriptlang.org/docs/handbook/modules.html)
-- [Namespaces](https://www.typescriptlang.org/docs/handbook/namespaces.html)
-- [Namespaces and Modules](https://www.typescriptlang.org/docs/handbook/namespaces-and-modules.html)

package/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/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/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/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/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/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/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-parameter-properties.mdx

@@ -1,12 +0,0 @@
-:::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/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-redeclare.mdx

@@ -1,78 +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 />
-
-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.
-
-## Options
-
-This rule adds the following options:
-
-```ts
-interface Options extends BaseNoRedeclareOptions {
-  ignoreDeclarationMerge?: boolean;
-}
-
-const defaultOptions: Options = {
-  ...baseNoRedeclareDefaultOptions,
-  ignoreDeclarationMerge: true,
-};
-```
-
-### `ignoreDeclarationMerge`
-
-When set to `true`, the rule will ignore declaration merges between the following sets:
-
-- 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 and a variable 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/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-redundant-type-constituents.mdx

@@ -1,98 +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)

package/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-require-imports.mdx

@@ -1,69 +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.
-
-Prefer the newer ES6-style imports over `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`
-
-A array of strings. 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
-console.log(require('../data.json').version);
-```
-
-</TabItem>
-<TabItem value="✅ Correct">
-
-```ts
-console.log(require('../package.json').version);
-```
-
-</TabItem>
-</Tabs>
-
-## When Not To Use It
-
-If your project frequently uses older CommonJS `require`s, then this rule might not be applicable to you.
-If only a subset of your project uses `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)

package/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-restricted-imports.mdx

@@ -1,77 +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.
-
-This rule extends the base [`eslint/no-restricted-imports`](https://eslint.org/docs/rules/no-restricted-imports) rule. It adds support for the type import (`import type X from "..."`, `import { type X } from "..."`) and `import x = require("...")` syntaxes.
-
-## Options
-
-This rule adds the following options:
-
-### `allowTypeImports`
-
-(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,
-          },
-        ],
-      },
-    ],
-  },
-}
-```
-
-When set to `true`, the rule will 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>