@alexlit/lint-kit 111.0.0 → 112.0.0

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

@@ -0,0 +1,122 @@
+---
+description: 'Disallow magic numbers.'
+---
+
+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-magic-numbers** for documentation.
+
+This rule extends the base [`eslint/no-magic-numbers`](https://eslint.org/docs/rules/no-magic-numbers) rule.
+It adds support for:
+
+- numeric literal types (`type T = 1`),
+- `enum` members (`enum Foo { bar = 1 }`),
+- `readonly` class properties (`class Foo { readonly bar = 1 }`).
+
+## Options
+
+This rule adds the following options:
+
+```ts
+interface Options extends BaseNoMagicNumbersOptions {
+  ignoreEnums?: boolean;
+  ignoreNumericLiteralTypes?: boolean;
+  ignoreReadonlyClassProperties?: boolean;
+  ignoreTypeIndexes?: boolean;
+}
+
+const defaultOptions: Options = {
+  ...baseNoMagicNumbersDefaultOptions,
+  ignoreEnums: false,
+  ignoreNumericLiteralTypes: false,
+  ignoreReadonlyClassProperties: false,
+  ignoreTypeIndexes: false,
+};
+```
+
+### `ignoreEnums`
+
+A boolean to specify if enums used in TypeScript are considered okay. `false` by default.
+
+Examples of **incorrect** code for the `{ "ignoreEnums": false }` option:
+
+```ts option='{ "ignoreEnums": false }' showPlaygroundButton
+enum foo {
+  SECOND = 1000,
+}
+```
+
+Examples of **correct** code for the `{ "ignoreEnums": true }` option:
+
+```ts option='{ "ignoreEnums": true }' showPlaygroundButton
+enum foo {
+  SECOND = 1000,
+}
+```
+
+### `ignoreNumericLiteralTypes`
+
+A boolean to specify if numbers used in TypeScript numeric literal types are considered okay. `false` by default.
+
+Examples of **incorrect** code for the `{ "ignoreNumericLiteralTypes": false }` option:
+
+```ts option='{ "ignoreNumericLiteralTypes": false }' showPlaygroundButton
+type SmallPrimes = 2 | 3 | 5 | 7 | 11;
+```
+
+Examples of **correct** code for the `{ "ignoreNumericLiteralTypes": true }` option:
+
+```ts option='{ "ignoreNumericLiteralTypes": true }' showPlaygroundButton
+type SmallPrimes = 2 | 3 | 5 | 7 | 11;
+```
+
+### `ignoreReadonlyClassProperties`
+
+Examples of **incorrect** code for the `{ "ignoreReadonlyClassProperties": false }` option:
+
+```ts option='{ "ignoreReadonlyClassProperties": false }' showPlaygroundButton
+class Foo {
+  readonly A = 1;
+  readonly B = 2;
+  public static readonly C = 1;
+  static readonly D = 1;
+}
+```
+
+Examples of **correct** code for the `{ "ignoreReadonlyClassProperties": true }` option:
+
+```ts option='{ "ignoreReadonlyClassProperties": true }' showPlaygroundButton
+class Foo {
+  readonly A = 1;
+  readonly B = 2;
+  public static readonly C = 1;
+  static readonly D = 1;
+}
+```
+
+### `ignoreTypeIndexes`
+
+A boolean to specify if numbers used to index types are okay. `false` by default.
+
+Examples of **incorrect** code for the `{ "ignoreTypeIndexes": false }` option:
+
+```ts option='{ "ignoreTypeIndexes": false }' showPlaygroundButton
+type Foo = Bar[0];
+type Baz = Parameters<Foo>[2];
+```
+
+Examples of **correct** code for the `{ "ignoreTypeIndexes": true }` option:
+
+```ts option='{ "ignoreTypeIndexes": true }' showPlaygroundButton
+type Foo = Bar[0];
+type Baz = Parameters<Foo>[2];
+```
+
+## When Not To Use It
+
+If your project frequently deals with constant numbers and you don't wish to take up extra space to declare them, this rule might not be for you.
+We recommend at least using descriptive comments and/or names to describe constants.
+You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) instead of completely disabling this rule.

package/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-meaningless-void-operator.mdx

@@ -0,0 +1,61 @@
+---
+description: 'Disallow the `void` operator except when used to discard a value.'
+---
+
+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-meaningless-void-operator** for documentation.
+
+`void` in TypeScript refers to a function return that is meant to be ignored.
+The `void` operator is a useful tool to convey the programmer's intent to discard a value.
+For example, it is recommended as one way of suppressing [`@typescript-eslint/no-floating-promises`](./no-floating-promises.mdx) instead of adding `.catch()` to a promise.
+
+This rule helps an authors catch API changes where previously a value was being discarded at a call site, but the callee changed so it no longer returns a value.
+When combined with [no-unused-expressions](https://eslint.org/docs/rules/no-unused-expressions), it also helps _readers_ of the code by ensuring consistency: a statement that looks like `void foo();` is **always** discarding a return value, and a statement that looks like `foo();` is **never** discarding a return value.
+This rule reports on any `void` operator whose argument is already of type `void` or `undefined`.
+
+## Examples
+
+## Examples
+
+<Tabs>
+<TabItem value="❌ Incorrect">
+
+```ts
+void (() => {})();
+
+function foo() {}
+void foo();
+```
+
+</TabItem>
+<TabItem value="✅ Correct">
+
+```ts
+(() => {})();
+
+function foo() {}
+foo(); // nothing to discard
+
+function bar(x: number) {
+  void x; // discarding a number
+  return 2;
+}
+void bar(); // discarding a number
+```
+
+</TabItem>
+</Tabs>
+
+## Options
+
+### `checkNever`
+
+`checkNever: true` will suggest removing `void` when the argument has type `never`.
+
+## When Not To Use It
+
+If you don't mind extra `void`s in your project, you can avoid this rule.

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

@@ -0,0 +1,53 @@
+---
+description: 'Enforce valid definition of `new` and `constructor`.'
+---
+
+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-misused-new** for documentation.
+
+JavaScript classes may define a `constructor` method that runs when a class instance is newly created.
+TypeScript allows interfaces that describe a static class object to define a `new()` method (though this is rarely used in real world code).
+Developers new to JavaScript classes and/or TypeScript interfaces may sometimes confuse when to use `constructor` or `new`.
+
+This rule reports when a class defines a method named `new` or an interface defines a method named `constructor`.
+
+## Examples
+
+<Tabs>
+<TabItem value="❌ Incorrect">
+
+```ts
+declare class C {
+  new(): C;
+}
+
+interface I {
+  new (): I;
+  constructor(): void;
+}
+```
+
+</TabItem>
+<TabItem value="✅ Correct">
+
+```ts
+declare class C {
+  constructor();
+}
+
+interface I {
+  new (): C;
+}
+```
+
+</TabItem>
+</Tabs>
+
+## When Not To Use It
+
+If you intentionally want a class with a `new` method, and you're confident nobody working in your code will mistake it with a constructor, you might not want this rule.
+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-misused-promises.mdx

@@ -0,0 +1,254 @@
+---
+description: 'Disallow Promises in places not designed to handle them.'
+---
+
+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-misused-promises** for documentation.
+
+This rule forbids providing Promises to logical locations such as if statements in places where the TypeScript compiler allows them but they are not handled properly.
+These situations can often arise due to a missing `await` keyword or just a misunderstanding of the way async
+functions are handled/awaited.
+
+:::tip
+`no-misused-promises` only detects code that provides Promises to incorrect _logical_ locations.
+See [`no-floating-promises`](./no-floating-promises.mdx) for detecting unhandled Promise _statements_.
+:::
+
+## Options
+
+### `checksConditionals`
+
+If you don't want to check conditionals, you can configure the rule with `"checksConditionals": false`:
+
+```json
+{
+  "@typescript-eslint/no-misused-promises": [
+    "error",
+    {
+      "checksConditionals": false
+    }
+  ]
+}
+```
+
+Doing so prevents the rule from looking at code like `if (somePromise)`.
+
+Examples of code for this rule with `checksConditionals: true`:
+
+## Examples
+
+<Tabs>
+<TabItem value="❌ Incorrect">
+
+```ts option='{ "checksConditionals": true }'
+const promise = Promise.resolve('value');
+
+if (promise) {
+  // Do something
+}
+
+const val = promise ? 123 : 456;
+
+while (promise) {
+  // Do something
+}
+```
+
+</TabItem>
+<TabItem value="✅ Correct">
+
+```ts option='{ "checksConditionals": true }'
+const promise = Promise.resolve('value');
+
+// Always `await` the Promise in a conditional
+if (await promise) {
+  // Do something
+}
+
+const val = (await promise) ? 123 : 456;
+
+while (await promise) {
+  // Do something
+}
+```
+
+</TabItem>
+</Tabs>
+
+### `checksVoidReturn`
+
+Likewise, if you don't want to check functions that return promises where a void return is
+expected, your configuration will look like this:
+
+```json
+{
+  "@typescript-eslint/no-misused-promises": [
+    "error",
+    {
+      "checksVoidReturn": false
+    }
+  ]
+}
+```
+
+You can disable selective parts of the `checksVoidReturn` option by providing an object that disables specific checks.
+The following options are supported:
+
+- `arguments`: Disables checking an asynchronous function passed as argument where the parameter type expects a function that returns `void`
+- `attributes`: Disables checking an asynchronous function passed as a JSX attribute expected to be a function that returns `void`
+- `properties`: Disables checking an asynchronous function passed as an object property expected to be a function that returns `void`
+- `returns`: Disables checking an asynchronous function returned in a function whose return type is a function that returns `void`
+- `variables`: Disables checking an asynchronous function used as a variable whose return type is a function that returns `void`
+
+For example, if you don't mind that passing a `() => Promise<void>` to a `() => void` parameter or JSX attribute can lead to a floating unhandled Promise:
+
+```json
+{
+  "@typescript-eslint/no-misused-promises": [
+    "error",
+    {
+      "checksVoidReturn": {
+        "arguments": false,
+        "attributes": false
+      }
+    }
+  ]
+}
+```
+
+Examples of code for this rule with `checksVoidReturn: true`:
+
+<Tabs>
+<TabItem value="❌ Incorrect">
+
+```ts option='{ "checksVoidReturn": true }'
+[1, 2, 3].forEach(async value => {
+  await doSomething(value);
+});
+
+new Promise(async (resolve, reject) => {
+  await doSomething();
+  resolve();
+});
+
+const eventEmitter = new EventEmitter();
+eventEmitter.on('some-event', async () => {
+  synchronousCall();
+  await doSomething();
+  otherSynchronousCall();
+});
+```
+
+</TabItem>
+<TabItem value="✅ Correct">
+
+```ts option='{ "checksVoidReturn": true }'
+// for-of puts `await` in outer context
+for (const value of [1, 2, 3]) {
+  await doSomething(value);
+}
+
+// If outer context is not `async`, handle error explicitly
+Promise.all(
+  [1, 2, 3].map(async value => {
+    await doSomething(value);
+  }),
+).catch(handleError);
+
+// Use an async IIFE wrapper
+new Promise((resolve, reject) => {
+  // combine with `void` keyword to tell `no-floating-promises` rule to ignore unhandled rejection
+  void (async () => {
+    await doSomething();
+    resolve();
+  })();
+});
+
+// Name the async wrapper to call it later
+const eventEmitter = new EventEmitter();
+eventEmitter.on('some-event', () => {
+  const handler = async () => {
+    await doSomething();
+    otherSynchronousCall();
+  };
+
+  try {
+    synchronousCall();
+  } catch (err) {
+    handleSpecificError(err);
+  }
+
+  handler().catch(handleError);
+});
+```
+
+</TabItem>
+</Tabs>
+
+### `checksSpreads`
+
+If you don't want to check object spreads, you can add this configuration:
+
+```json
+{
+  "@typescript-eslint/no-misused-promises": [
+    "error",
+    {
+      "checksSpreads": false
+    }
+  ]
+}
+```
+
+Examples of code for this rule with `checksSpreads: true`:
+
+<Tabs>
+<TabItem value="❌ Incorrect">
+
+```ts option='{ "checksSpreads": true }'
+const getData = () => someAsyncOperation({ myArg: 'foo' });
+
+return { foo: 42, ...getData() };
+
+const getData2 = async () => {
+  await someAsyncOperation({ myArg: 'foo' });
+};
+
+return { foo: 42, ...getData2() };
+```
+
+</TabItem>
+<TabItem value="✅ Correct">
+
+```ts option='{ "checksSpreads": true }'
+const getData = () => someAsyncOperation({ myArg: 'foo' });
+
+return { foo: 42, ...(await getData()) };
+
+const getData2 = async () => {
+  await someAsyncOperation({ myArg: 'foo' });
+};
+
+return { foo: 42, ...(await getData2()) };
+```
+
+</TabItem>
+</Tabs>
+
+## When Not To Use It
+
+This rule can be difficult to enable on large existing projects that set up many misused Promises.
+Alternately, if you're not worried about crashes from floating or misused Promises -such as if you have global unhandled Promise handlers registered- then in some cases it may be safe to not use this rule.
+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 void function assignability](https://github.com/Microsoft/TypeScript/wiki/FAQ#why-are-functions-returning-non-void-assignable-to-function-returning-void)
+
+## Related To
+
+- [`no-floating-promises`](./no-floating-promises.mdx)

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

@@ -0,0 +1,96 @@
+---
+description: 'Disallow enums from having both number and string members.'
+---
+
+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-mixed-enums** for documentation.
+
+TypeScript enums are allowed to assign numeric or string values to their members.
+Most enums contain either all numbers or all strings, but in theory you can mix-and-match within the same enum.
+Mixing enum member types is generally considered confusing and a bad practice.
+
+## Examples
+
+<Tabs>
+<TabItem value="❌ Incorrect">
+
+```ts
+enum Status {
+  Unknown,
+  Closed = 1,
+  Open = 'open',
+}
+```
+
+</TabItem>
+<TabItem value="✅ Correct (Explicit Numbers)">
+
+```ts
+enum Status {
+  Unknown = 0,
+  Closed = 1,
+  Open = 2,
+}
+```
+
+</TabItem>
+<TabItem value="✅ Correct (Implicit Numbers)">
+
+```ts
+enum Status {
+  Unknown,
+  Closed,
+  Open,
+}
+```
+
+</TabItem>
+<TabItem value="✅ Correct (Strings)">
+
+```ts
+enum Status {
+  Unknown = 'unknown',
+  Closed = 'closed',
+  Open = 'open',
+}
+```
+
+</TabItem>
+</Tabs>
+
+## Iteration Pitfalls of Mixed Enum Member Values
+
+Enum values may be iterated over using `Object.entries`/`Object.keys`/`Object.values`.
+
+If all enum members are strings, the number of items will match the number of enum members:
+
+```ts
+enum Status {
+  Closed = 'closed',
+  Open = 'open',
+}
+
+// ['closed', 'open']
+Object.values(Status);
+```
+
+But if the enum contains members that are initialized with numbers -including implicitly initialized numbers— then iteration over that enum will include those numbers as well:
+
+```ts
+enum Status {
+  Unknown,
+  Closed = 1,
+  Open = 'open',
+}
+
+// ["Unknown", "Closed", 0, 1, "open"]
+Object.values(Status);
+```
+
+## When Not To Use It
+
+If you don't mind the confusion of mixed enum member values and don't iterate over enums, you can safely disable this rule.