@alexlit/lint-kit 111.1.0 → 112.0.0

package/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/sort-type-constituents.mdx

@@ -0,0 +1,178 @@
+---
+description: 'Enforce constituents of a type union/intersection to be sorted alphabetically.'
+---
+
+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/sort-type-constituents** for documentation.
+
+Sorting union (`|`) and intersection (`&`) types can help:
+
+- keep your codebase standardized
+- find repeated types
+- reduce diff churn
+
+This rule reports on any types that aren't sorted alphabetically.
+
+> Types are sorted case-insensitively and treating numbers like a human would, falling back to character code sorting in case of ties.
+
+## Examples
+
+<Tabs>
+<TabItem value="❌ Incorrect">
+
+```ts
+type T1 = B | A;
+
+type T2 = { b: string } & { a: string };
+
+type T3 = [1, 2, 4] & [1, 2, 3];
+
+type T4 =
+  | [1, 2, 4]
+  | [1, 2, 3]
+  | { b: string }
+  | { a: string }
+  | (() => void)
+  | (() => string)
+  | 'b'
+  | 'a'
+  | 'b'
+  | 'a'
+  | readonly string[]
+  | readonly number[]
+  | string[]
+  | number[]
+  | B
+  | A
+  | string
+  | any;
+```
+
+</TabItem>
+<TabItem value="✅ Correct">
+
+```ts
+type T1 = A | B;
+
+type T2 = { a: string } & { b: string };
+
+type T3 = [1, 2, 3] & [1, 2, 4];
+
+type T4 =
+  | A
+  | B
+  | number[]
+  | string[]
+  | any
+  | string
+  | readonly number[]
+  | readonly string[]
+  | 'a'
+  | 'a'
+  | 'b'
+  | 'b'
+  | (() => string)
+  | (() => void)
+  | { a: string }
+  | { b: string }
+  | [1, 2, 3]
+  | [1, 2, 4];
+```
+
+</TabItem>
+</Tabs>
+
+## Options
+
+### `checkIntersections`
+
+Whether to check intersection types (`&`).
+
+Examples of code with `{ "checkIntersections": true }` (the default):
+
+<Tabs>
+<TabItem value="❌ Incorrect">
+
+```ts option='{ "checkIntersections": true }'
+type ExampleIntersection = B & A;
+```
+
+</TabItem>
+<TabItem value="✅ Correct">
+
+```ts option='{ "checkIntersections": true }'
+type ExampleIntersection = A & B;
+```
+
+</TabItem>
+</Tabs>
+
+### `checkUnions`
+
+Whether to check union types (`|`).
+
+Examples of code with `{ "checkUnions": true }` (the default):
+
+<Tabs>
+<TabItem value="❌ Incorrect">
+
+```ts option='{ "checkUnions": true }'
+type ExampleUnion = B | A;
+```
+
+</TabItem>
+<TabItem value="✅ Correct">
+
+```ts option='{ "checkUnions": true }'
+type ExampleUnion = A | B;
+```
+
+</TabItem>
+</Tabs>
+
+### `groupOrder`
+
+Each constituent of the type is placed into a group, and then the rule sorts alphabetically within each group.
+The ordering of groups is determined by this option.
+
+- `conditional` - Conditional types (`A extends B ? C : D`)
+- `function` - Function and constructor types (`() => void`, `new () => type`)
+- `import` - Import types (`import('path')`)
+- `intersection` - Intersection types (`A & B`)
+- `keyword` - Keyword types (`any`, `string`, etc)
+- `literal` - Literal types (`1`, `'b'`, `true`, etc)
+- `named` - Named types (`A`, `A['prop']`, `B[]`, `Array<C>`)
+- `object` - Object types (`{ a: string }`, `{ [key: string]: number }`)
+- `operator` - Operator types (`keyof A`, `typeof B`, `readonly C[]`)
+- `tuple` - Tuple types (`[A, B, C]`)
+- `union` - Union types (`A | B`)
+- `nullish` - `null` and `undefined`
+
+For example, configuring the rule with `{ "groupOrder": ["literal", "nullish" ]}`:
+
+<Tabs>
+<TabItem value="❌ Incorrect">
+
+```ts option='{ "groupOrder": ["literal", "nullish" ]}'
+type ExampleGroup = null | 123;
+```
+
+</TabItem>
+<TabItem value="✅ Correct">
+
+```ts option='{ "groupOrder": ["literal", "nullish" ]}'
+type ExampleGroup = 123 | null;
+```
+
+</TabItem>
+</Tabs>
+
+## When Not To Use It
+
+This rule is purely a stylistic rule for maintaining consistency in your project.
+You can turn it off if you don't want to keep a consistent, predictable order for intersection and union types.
+However, keep in mind that inconsistent style can harm readability in a project.

package/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/space-before-blocks.mdx

@@ -0,0 +1,49 @@
+---
+description: 'Enforce consistent spacing before blocks.'
+---
+
+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/space-before-blocks** for documentation.
+
+This rule extends the base [`eslint/space-before-blocks`](https://eslint.org/docs/rules/space-before-blocks) rule.
+It adds support for interfaces and enums.
+
+<Tabs>
+<TabItem value="❌ Incorrect">
+
+<!-- prettier-ignore -->
+```ts
+enum Breakpoint{
+  Large,
+  Medium,
+}
+
+interface State{
+  currentBreakpoint: Breakpoint;
+}
+```
+
+</TabItem>
+<TabItem value="✅ Correct">
+
+```ts
+enum Breakpoint {
+  Large,
+  Medium,
+}
+
+interface State {
+  currentBreakpoint: Breakpoint;
+}
+```
+
+</TabItem>
+</Tabs>
+
+## Options
+
+In case a more specific options object is passed these blocks will follow `classes` configuration option.

package/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/space-before-function-paren.mdx

@@ -0,0 +1,13 @@
+---
+description: 'Enforce consistent spacing before function parenthesis.'
+---
+
+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/space-before-function-paren** for documentation.
+
+This rule extends the base [`eslint/space-before-function-paren`](https://eslint.org/docs/rules/space-before-function-paren) rule.
+It adds support for generic type parameters on function calls.

package/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/space-infix-ops.mdx

@@ -0,0 +1,19 @@
+---
+description: 'Require spacing around infix operators.'
+---
+
+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/space-infix-ops** for documentation.
+
+This rule extends the base [`eslint/space-infix-ops`](https://eslint.org/docs/rules/space-infix-ops) rule.
+It adds support for enum members.
+
+```ts
+enum MyEnum {
+  KEY = 'value',
+}
+```

package/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/strict-boolean-expressions.mdx

@@ -0,0 +1,196 @@
+---
+description: 'Disallow certain types in boolean expressions.'
+---
+
+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/strict-boolean-expressions** for documentation.
+
+Forbids usage of non-boolean types in expressions where a boolean is expected.
+`boolean` and `never` types are always allowed.
+Additional types which are considered safe in a boolean context can be configured via options.
+
+The following nodes are considered boolean expressions and their type is checked:
+
+- Argument to the logical negation operator (`!arg`).
+- The condition in a conditional expression (`cond ? x : y`).
+- Conditions for `if`, `for`, `while`, and `do-while` statements.
+- Operands of logical binary operators (`lhs || rhs` and `lhs && rhs`).
+  - Right-hand side operand is ignored when it's not a descendant of another boolean expression.
+    This is to allow usage of boolean operators for their short-circuiting behavior.
+
+## Examples
+
+<Tabs>
+<TabItem value="❌ Incorrect">
+
+```ts
+// nullable numbers are considered unsafe by default
+let num: number | undefined = 0;
+if (num) {
+  console.log('num is defined');
+}
+
+// nullable strings are considered unsafe by default
+let str: string | null = null;
+if (!str) {
+  console.log('str is empty');
+}
+
+// nullable booleans are considered unsafe by default
+function foo(bool?: boolean) {
+  if (bool) {
+    bar();
+  }
+}
+
+// `any`, unconstrained generics and unions of more than one primitive type are disallowed
+const foo = <T>(arg: T) => (arg ? 1 : 0);
+
+// always-truthy and always-falsy types are disallowed
+let obj = {};
+while (obj) {
+  obj = getObj();
+}
+```
+
+</TabItem>
+<TabItem value="✅ Correct">
+
+```tsx
+// Using logical operator short-circuiting is allowed
+const Component = () => {
+  const entry = map.get('foo') || {};
+  return entry && <p>Name: {entry.name}</p>;
+};
+
+// nullable values should be checked explicitly against null or undefined
+let num: number | undefined = 0;
+if (num != null) {
+  console.log('num is defined');
+}
+
+let str: string | null = null;
+if (str != null && !str) {
+  console.log('str is empty');
+}
+
+function foo(bool?: boolean) {
+  if (bool ?? false) {
+    bar();
+  }
+}
+
+// `any` types should be cast to boolean explicitly
+const foo = (arg: any) => (Boolean(arg) ? 1 : 0);
+```
+
+</TabItem>
+</Tabs>
+
+## Options
+
+### `allowString`
+
+Allows `string` in a boolean context.
+This is safe because strings have only one falsy value (`""`).
+Set this to `false` if you prefer the explicit `str != ""` or `str.length > 0` style.
+
+### `allowNumber`
+
+Allows `number` in a boolean context.
+This is safe because numbers have only two falsy values (`0` and `NaN`).
+Set this to `false` if you prefer the explicit `num != 0` and `!Number.isNaN(num)` style.
+
+### `allowNullableObject`
+
+Allows `object | function | symbol | null | undefined` in a boolean context.
+This is safe because objects, functions and symbols don't have falsy values.
+Set this to `false` if you prefer the explicit `obj != null` style.
+
+### `allowNullableBoolean`
+
+Allows `boolean | null | undefined` in a boolean context.
+This is unsafe because nullable booleans can be either `false` or nullish.
+Set this to `false` if you want to enforce explicit `bool ?? false` or `bool ?? true` style.
+Set this to `true` if you don't mind implicitly treating false the same as a nullish value.
+
+### `allowNullableString`
+
+Allows `string | null | undefined` in a boolean context.
+This is unsafe because nullable strings can be either an empty string or nullish.
+Set this to `true` if you don't mind implicitly treating an empty string the same as a nullish value.
+
+### `allowNullableNumber`
+
+Allows `number | null | undefined` in a boolean context.
+This is unsafe because nullable numbers can be either a falsy number or nullish.
+Set this to `true` if you don't mind implicitly treating zero or NaN the same as a nullish value.
+
+### `allowNullableEnum`
+
+Allows `enum | null | undefined` in a boolean context.
+This is unsafe because nullable enums can be either a falsy number or nullish.
+Set this to `true` if you don't mind implicitly treating an enum whose value is zero the same as a nullish value.
+
+### `allowAny`
+
+Allows `any` in a boolean context.
+This is unsafe for obvious reasons.
+Set this to `true` at your own risk.
+
+### `allowRuleToRunWithoutStrictNullChecksIKnowWhatIAmDoing`
+
+If this is set to `false`, then the rule will error on every file whose `tsconfig.json` does _not_ have the `strictNullChecks` compiler option (or `strict`) set to `true`.
+
+Without `strictNullChecks`, TypeScript essentially erases `undefined` and `null` from the types. This means when this rule inspects the types from a variable, **it will not be able to tell that the variable might be `null` or `undefined`**, which essentially makes this rule a lot less useful.
+
+You should be using `strictNullChecks` to ensure complete type-safety in your codebase.
+
+If for some reason you cannot turn on `strictNullChecks`, but still want to use this rule - you can use this option to allow it - but know that the behavior of this rule is _undefined_ with the compiler option turned off. We will not accept bug reports if you are using this option.
+
+## Fixes and Suggestions
+
+This rule provides following fixes and suggestions for particular types in boolean context:
+
+- `boolean` - Always allowed - no fix needed.
+- `string` - (when `allowString` is `false`) - Provides following suggestions:
+  - Change condition to check string's length (`str` → `str.length > 0`)
+  - Change condition to check for empty string (`str` → `str !== ""`)
+  - Explicitly cast value to a boolean (`str` → `Boolean(str)`)
+- `number` - (when `allowNumber` is `false`):
+  - For `array.length` - Provides **autofix**:
+    - Change condition to check for 0 (`array.length` → `array.length > 0`)
+  - For other number values - Provides following suggestions:
+    - Change condition to check for 0 (`num` → `num !== 0`)
+    - Change condition to check for NaN (`num` → `!Number.isNaN(num)`)
+    - Explicitly cast value to a boolean (`num` → `Boolean(num)`)
+- `object | null | undefined` - (when `allowNullableObject` is `false`) - Provides **autofix**:
+  - Change condition to check for null/undefined (`maybeObj` → `maybeObj != null`)
+- `boolean | null | undefined` - Provides following suggestions:
+  - Explicitly treat nullish value the same as false (`maybeBool` → `maybeBool ?? false`)
+  - Change condition to check for true/false (`maybeBool` → `maybeBool === true`)
+- `string | null | undefined` - Provides following suggestions:
+  - Change condition to check for null/undefined (`maybeStr` → `maybeStr != null`)
+  - Explicitly treat nullish value the same as an empty string (`maybeStr` → `maybeStr ?? ""`)
+  - Explicitly cast value to a boolean (`maybeStr` → `Boolean(maybeStr)`)
+- `number | null | undefined` - Provides following suggestions:
+  - Change condition to check for null/undefined (`maybeNum` → `maybeNum != null`)
+  - Explicitly treat nullish value the same as 0 (`maybeNum` → `maybeNum ?? 0`)
+  - Explicitly cast value to a boolean (`maybeNum` → `Boolean(maybeNum)`)
+- `any` and `unknown` - Provides following suggestions:
+  - Explicitly cast value to a boolean (`value` → `Boolean(value)`)
+
+## When Not To Use It
+
+If your project isn't likely to experience bugs from falsy non-boolean values being used in logical conditions, you can skip enabling this rule.
+
+Otherwise, this rule can be quite strict around requiring exact comparisons in logical checks.
+If you prefer more succinct checks over more precise boolean logic, this rule might not be for you.
+
+## Related To
+
+- [no-unnecessary-condition](./no-unnecessary-condition.mdx) - Similar rule which reports always-truthy and always-falsy values in conditions

package/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/switch-exhaustiveness-check.mdx

@@ -0,0 +1,230 @@
+---
+description: 'Require switch-case statements to be exhaustive.'
+---
+
+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/switch-exhaustiveness-check** for documentation.
+
+When working with union types or enums in TypeScript, it's common to want to write a `switch` statement intended to contain a `case` for each possible type in the union or the enum.
+However, if the union type or the enum changes, it's easy to forget to modify the cases to account for any new types.
+
+This rule reports when a `switch` statement over a value typed as a union of literals or as an enum is missing a case for any of those literal types and does not have a `default` clause.
+
+## Options
+
+### `allowDefaultCaseForExhaustiveSwitch`
+
+Defaults to true. If set to false, this rule will also report when a `switch` statement has a case for everything in a union and _also_ contains a `default` case. Thus, by setting this option to false, the rule becomes stricter.
+
+When a `switch` statement over a union type is exhaustive, a final `default` case would be a form of dead code.
+Additionally, if a new value is added to the union type, a `default` would prevent the `switch-exhaustiveness-check` rule from reporting on the new case not being handled in the `switch` statement.
+
+#### `allowDefaultCaseForExhaustiveSwitch` Caveats
+
+It can sometimes be useful to include a redundant `default` case on an exhaustive `switch` statement if it's possible for values to have types not represented by the union type.
+For example, in applications that can have version mismatches between clients and servers, it's possible for a server running a newer software version to send a value not recognized by the client's older typings.
+
+If your project has a small number of intentionally redundant `default` cases, you might want to use an [inline ESLint disable comment](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for each of them.
+
+If your project has many intentionally redundant `default` cases, you may want to disable `allowDefaultCaseForExhaustiveSwitch` and use the [`default-case` core ESLint rule](https://eslint.org/docs/latest/rules/default-case) along with [a `satisfies never` check](https://www.typescriptlang.org/play?#code/C4TwDgpgBAYgTgVwJbCgXigcgIZjAGwkygB8sAjbAO2u0wG4AoRgMwSoGNgkB7KqBAGcI8ZMAAULRCgBcsacACUcwcDhIqAcygBvRlCiCA7ig4ALKJIWLd+g1A7ZhWXASJy99+3AjAEcfhw8QgApZA4iJi8AX2YvR2dMShoaTA87Lx8-AIpaGjCkCIYMqFiSgBMIFmwEfGB0rwMpMUNsbkEWJAhBKCoIADcIOCjGrP9A9gBrKh4jKgKikYNY5cZYoA).
+
+### `requireDefaultForNonUnion`
+
+Defaults to false. It set to true, this rule will also report when a `switch` statement switches over a non-union type (like a `number` or `string`, for example) and that `switch` statement does not have a `default` case. Thus, by setting this option to true, the rule becomes stricter.
+
+This is generally desirable so that `number` and `string` switches will be subject to the same exhaustive checks that your other switches are.
+
+Examples of additional **incorrect** code for this rule with `{ requireDefaultForNonUnion: true }`:
+
+```ts option='{ "requireDefaultForNonUnion": true }' showPlaygroundButton
+const value: number = Math.floor(Math.random() * 3);
+
+switch (value) {
+  case 0:
+    return 0;
+  case 1:
+    return 1;
+}
+```
+
+Since `value` is a non-union type it requires the switch case to have a default clause only with `requireDefaultForNonUnion` enabled.
+
+## Examples
+
+When the switch doesn't have exhaustive cases, either filling them all out or adding a default will correct the rule's complaint.
+
+Here are some examples of code working with a union of literals:
+
+<Tabs>
+<TabItem value="❌ Incorrect">
+
+```ts
+type Day =
+  | 'Monday'
+  | 'Tuesday'
+  | 'Wednesday'
+  | 'Thursday'
+  | 'Friday'
+  | 'Saturday'
+  | 'Sunday';
+
+declare const day: Day;
+let result = 0;
+
+switch (day) {
+  case 'Monday':
+    result = 1;
+    break;
+}
+```
+
+</TabItem>
+<TabItem value="✅ Correct (Exhaustive)">
+
+```ts
+type Day =
+  | 'Monday'
+  | 'Tuesday'
+  | 'Wednesday'
+  | 'Thursday'
+  | 'Friday'
+  | 'Saturday'
+  | 'Sunday';
+
+declare const day: Day;
+let result = 0;
+
+switch (day) {
+  case 'Monday':
+    result = 1;
+    break;
+  case 'Tuesday':
+    result = 2;
+    break;
+  case 'Wednesday':
+    result = 3;
+    break;
+  case 'Thursday':
+    result = 4;
+    break;
+  case 'Friday':
+    result = 5;
+    break;
+  case 'Saturday':
+    result = 6;
+    break;
+  case 'Sunday':
+    result = 7;
+    break;
+}
+```
+
+</TabItem>
+<TabItem value="✅ Correct (Defaulted)">
+
+```ts
+type Day =
+  | 'Monday'
+  | 'Tuesday'
+  | 'Wednesday'
+  | 'Thursday'
+  | 'Friday'
+  | 'Saturday'
+  | 'Sunday';
+
+declare const day: Day;
+let result = 0;
+
+switch (day) {
+  case 'Monday':
+    result = 1;
+    break;
+  default:
+    result = 42;
+}
+```
+
+</TabItem>
+</Tabs>
+
+Likewise, here are some examples of code working with an enum:
+
+<Tabs>
+<TabItem value="❌ Incorrect">
+
+```ts
+enum Fruit {
+  Apple,
+  Banana,
+  Cherry,
+}
+
+declare const fruit: Fruit;
+
+switch (fruit) {
+  case Fruit.Apple:
+    console.log('an apple');
+    break;
+}
+```
+
+</TabItem>
+<TabItem value="✅ Correct (Exhaustive)">
+
+```ts
+enum Fruit {
+  Apple,
+  Banana,
+  Cherry,
+}
+
+declare const fruit: Fruit;
+
+switch (fruit) {
+  case Fruit.Apple:
+    console.log('an apple');
+    break;
+
+  case Fruit.Banana:
+    console.log('a banana');
+    break;
+
+  case Fruit.Cherry:
+    console.log('a cherry');
+    break;
+}
+```
+
+</TabItem>
+<TabItem value="✅ Correct (Defaulted)">
+
+```ts
+enum Fruit {
+  Apple,
+  Banana,
+  Cherry,
+}
+
+declare const fruit: Fruit;
+
+switch (fruit) {
+  case Fruit.Apple:
+    console.log('an apple');
+    break;
+
+  default:
+    console.log('a fruit');
+    break;
+}
+```
+
+</TabItem>
+</Tabs>
+
+## When Not To Use It
+
+If you don't frequently `switch` over union types or enums with many parts, or intentionally wish to leave out some parts, this rule may not be for you.