@alexlit/lint-kit 111.0.0 → 112.0.0

package/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/consistent-type-exports.mdx

@@ -0,0 +1,114 @@
+---
+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`
+
+When this is set to true, the rule will autofix "mixed" export cases using TS 4.5's "inline type specifier".
+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 };
+```
+
+<Tabs>
+<TabItem value="❌ Incorrect">
+
+```ts option='{ "fixMixedExportsWithInlineTypeSpecifier": true }'
+export { Button } from 'some-library';
+export type { ButtonProps } from 'some-library';
+```
+
+</TabItem>
+<TabItem value="✅ Correct">
+
+```ts option='{ "fixMixedExportsWithInlineTypeSpecifier": true }'
+export { Button, type ButtonProps } from 'some-library';
+```
+
+</TabItem>
+</Tabs>
+
+## 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.

package/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/consistent-type-imports.mdx

@@ -0,0 +1,113 @@
+---
+description: 'Enforce consistent usage of type imports.'
+---
+
+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-imports** for documentation.
+
+TypeScript allows specifying a `type` keyword on imports to indicate that the export exists only in the type system, not at runtime.
+This allows transpilers to drop imports 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.
+
+## Options
+
+### `prefer`
+
+This option defines the expected import kind for type-only imports. Valid values for `prefer` are:
+
+- `type-imports` will enforce that you always use `import type Foo from '...'` except referenced by metadata of decorators. It is the default.
+- `no-type-imports` will enforce that you always use `import Foo from '...'`.
+
+Examples of **correct** code with `{prefer: 'type-imports'}`, and **incorrect** code with `{prefer: 'no-type-imports'}`.
+
+```ts option='{ "prefer": "type-imports" }' showPlaygroundButton
+import type { Foo } from 'Foo';
+import type Bar from 'Bar';
+type T = Foo;
+const x: Bar = 1;
+```
+
+Examples of **incorrect** code with `{prefer: 'type-imports'}`, and **correct** code with `{prefer: 'no-type-imports'}`.
+
+```ts option='{ "prefer": "type-imports" }' showPlaygroundButton
+import { Foo } from 'Foo';
+import Bar from 'Bar';
+type T = Foo;
+const x: Bar = 1;
+```
+
+### `fixStyle`
+
+This option defines the expected type modifier to be added when an import is detected as used only in the type position. Valid values for `fixStyle` are:
+
+- `separate-type-imports` will add the type keyword after the import keyword `import type { A } from '...'`. It is the default.
+- `inline-type-imports` will inline the type keyword `import { type A } from '...'` and is only available in TypeScript 4.5 and onwards. See [documentation here](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-5.html#type-modifiers-on-import-names 'TypeScript 4.5 documentation on type modifiers and import names').
+
+<Tabs>
+<TabItem value="❌ Incorrect">
+
+```ts
+import { Foo } from 'Foo';
+import Bar from 'Bar';
+type T = Foo;
+const x: Bar = 1;
+```
+
+</TabItem>
+<TabItem value="✅ With `separate-type-imports`">
+
+```ts option='{ "fixStyle": "separate-type-imports" }'
+import type { Foo } from 'Foo';
+import type Bar from 'Bar';
+type T = Foo;
+const x: Bar = 1;
+```
+
+</TabItem>
+<TabItem value="✅ With `inline-type-imports`">
+
+```ts option='{ "fixStyle": "inline-type-imports" }'
+import { type Foo } from 'Foo';
+import type Bar from 'Bar';
+type T = Foo;
+const x: Bar = 1;
+```
+
+</TabItem>
+</Tabs>
+
+### `disallowTypeAnnotations`
+
+If `true`, type imports in type annotations (`import()`) are not allowed.
+Default is `true`.
+
+Examples of **incorrect** code with `{disallowTypeAnnotations: true}`:
+
+```ts option='{ "disallowTypeAnnotations": true }' showPlaygroundButton
+type T = import('Foo').Foo;
+const x: import('Bar') = 1;
+```
+
+## Usage with `emitDecoratorMetadata`
+
+The `emitDecoratorMetadata` compiler option changes the code the TypeScript emits. In short - it causes TypeScript to create references to value imports when they are used in a type-only location. If you are using `emitDecoratorMetadata` then our tooling will require additional information in order for the rule to work correctly.
+
+If you are using [type-aware linting](/getting-started/typed-linting), then you just need to ensure that the `tsconfig.json` you've configured for `parserOptions.project` has `emitDecoratorMetadata` turned on. Otherwise you can explicitly tell our tooling to analyze your code as if the compiler option was turned on [by setting `parserOptions.emitDecoratorMetadata` to `true`](https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/parser/README.md#parseroptionsemitdecoratormetadata).
+
+## When Not To Use It
+
+If you specifically want to use both import 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.
+
+## Related To
+
+- [`no-import-type-side-effects`](./no-import-type-side-effects.mdx)
+- [`import/consistent-type-specifier-style`](https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/consistent-type-specifier-style.mdx)
+- [`import/no-duplicates` with `{"prefer-inline": true}`](https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/no-duplicates.md#inline-type-imports)

package/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/default-param-last.mdx

@@ -0,0 +1,64 @@
+---
+description: 'Enforce default parameters to be last.'
+---
+
+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/default-param-last** for documentation.
+
+This rule extends the base [`eslint/default-param-last`](https://eslint.org/docs/rules/default-param-last) rule.
+It adds support for optional parameters.
+
+<Tabs>
+<TabItem value="❌ Incorrect">
+
+```ts
+/* eslint @typescript-eslint/default-param-last: "error" */
+
+function f(a = 0, b: number) {}
+function f(a: number, b = 0, c: number) {}
+function f(a: number, b?: number, c: number) {}
+class Foo {
+  constructor(
+    public a = 10,
+    private b: number,
+  ) {}
+}
+class Foo {
+  constructor(
+    public a?: number,
+    private b: number,
+  ) {}
+}
+```
+
+</TabItem>
+<TabItem value="✅ Correct">
+
+```ts
+/* eslint @typescript-eslint/default-param-last: "error" */
+
+function f(a = 0) {}
+function f(a: number, b = 0) {}
+function f(a: number, b?: number) {}
+function f(a: number, b?: number, c = 0) {}
+function f(a: number, b = 0, c?: number) {}
+class Foo {
+  constructor(
+    public a,
+    private b = 0,
+  ) {}
+}
+class Foo {
+  constructor(
+    public a,
+    private b?: number,
+  ) {}
+}
+```
+
+</TabItem>
+</Tabs>

package/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/dot-notation.mdx

@@ -0,0 +1,85 @@
+---
+description: 'Enforce dot notation whenever possible.'
+---
+
+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/dot-notation** for documentation.
+
+This rule extends the base [`eslint/dot-notation`](https://eslint.org/docs/rules/dot-notation) rule.
+It adds:
+
+- Support for optionally ignoring computed `private` and/or `protected` member access.
+- Compatibility with TypeScript's `noPropertyAccessFromIndexSignature` option.
+
+## Options
+
+This rule adds the following options:
+
+```ts
+interface Options extends BaseDotNotationOptions {
+  allowPrivateClassPropertyAccess?: boolean;
+  allowProtectedClassPropertyAccess?: boolean;
+  allowIndexSignaturePropertyAccess?: boolean;
+}
+
+const defaultOptions: Options = {
+  ...baseDotNotationDefaultOptions,
+  allowPrivateClassPropertyAccess: false,
+  allowProtectedClassPropertyAccess: false,
+  allowIndexSignaturePropertyAccess: false,
+};
+```
+
+If the TypeScript compiler option `noPropertyAccessFromIndexSignature` is set to `true`, then this rule always allows the use of square bracket notation to access properties of types that have a `string` index signature, even if `allowIndexSignaturePropertyAccess` is `false`.
+
+### `allowPrivateClassPropertyAccess`
+
+Example of a correct code when `allowPrivateClassPropertyAccess` is set to `true`:
+
+```ts option='{ "allowPrivateClassPropertyAccess": true }' showPlaygroundButton
+class X {
+  private priv_prop = 123;
+}
+
+const x = new X();
+x['priv_prop'] = 123;
+```
+
+### `allowProtectedClassPropertyAccess`
+
+Example of a correct code when `allowProtectedClassPropertyAccess` is set to `true`:
+
+```ts option='{ "allowProtectedClassPropertyAccess": true }' showPlaygroundButton
+class X {
+  protected protected_prop = 123;
+}
+
+const x = new X();
+x['protected_prop'] = 123;
+```
+
+### `allowIndexSignaturePropertyAccess`
+
+Example of correct code when `allowIndexSignaturePropertyAccess` is set to `true`:
+
+```ts option='{ "allowIndexSignaturePropertyAccess": true }' showPlaygroundButton
+class X {
+  [key: string]: number;
+}
+
+const x = new X();
+x['hello'] = 123;
+```
+
+If the TypeScript compiler option `noPropertyAccessFromIndexSignature` is set to `true`, then the above code is always allowed, even if `allowIndexSignaturePropertyAccess` is `false`.
+
+## When Not To Use It
+
+If you specifically want to use both member access 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.