xo 0.46.1 → 0.46.2

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/sort-type-union-intersection-members.md

@@ -1,153 +0,0 @@
-# Enforces that members of a type union/intersection are sorted alphabetically (`sort-type-union-intersection-members`)
-
-Sorting union (`|`) and intersection (`&`) types can help:
-
-- keep your codebase standardized
-- find repeated types
-- reduce diff churn
-
-## Rule Details
-
-Sorting within each group is done using the following code:
-
-```ts
-const collator = new Intl.Collator('en', {
-  sensitivity: 'base',
-  numeric: true,
-});
-
-function compare(a, b) {
-  return collator.compare(a, b) || (a < b ? -1 : a > b ? 1 : 0);
-}
-```
-
-In other words, the types are sorted alphabetically, case-insensitively and treating numbers like a human would, falling back to character code sorting in case of ties.
-
-Examples of **incorrect** code for this rule:
-
-```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;
-```
-
-Examples of **correct** code for this rule:
-
-```ts
-type T1 = A | B;
-
-type T2 = { a: string } & { b: string };
-
-type T3 = [1, 2, 3] & [1, 2, 4];
-
-type T4 =
-  | any
-  | string
-  | A
-  | B
-  | number[]
-  | string[]
-  | readonly number[]
-  | readonly string[]
-  | 'a'
-  | 'b'
-  | 'a'
-  | 'b'
-  | (() => string)
-  | (() => void)
-  | { a: string }
-  | { b: string }
-  | [1, 2, 3]
-  | [1, 2, 4];
-```
-
-## Options
-
-```ts
-type Options = {
-  // true to check intersection types, false otherwise
-  checkIntersections?: boolean;
-  // true to check union types, false otherwise
-  checkUnions?: boolean;
-  // the ordering of the groups
-  groupOrder?: (
-    | 'conditional'
-    | 'function'
-    | 'import'
-    | 'intersection'
-    | 'keyword'
-    | 'literal'
-    | 'named'
-    | 'object'
-    | 'operator'
-    | 'tuple'
-    | 'union'
-    | 'nullish'
-  )[];
-};
-
-const defaultOptions: Options = {
-  checkIntersections: true,
-  checkUnions: true,
-  groupOrder: [
-    'named',
-    'keyword',
-    'operator',
-    'literal',
-    'function',
-    'import',
-    'conditional',
-    'object',
-    'tuple',
-    'intersection',
-    'union',
-    'nullish',
-  ],
-};
-```
-
-### `groupOrder`
-
-Each member 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`
-
-## Attributes
-
-- [ ] ✅ Recommended
-- [x] 🔧 Fixable
-- [ ] 💭 Requires type information

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/space-before-function-paren.md

@@ -1,28 +0,0 @@
-# Enforces consistent spacing before function parenthesis (`space-before-function-paren`)
-
-## Rule Details
-
-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.
-
-## How to use
-
-```jsonc
-{
-  // note you must disable the base rule as it can report incorrect errors
-  "space-before-function-paren": "off",
-  "@typescript-eslint/space-before-function-paren": ["error"]
-}
-```
-
-## Options
-
-See [`eslint/space-before-function-paren` options](https://eslint.org/docs/rules/space-before-function-paren#options).
-
-<sup>Taken with ❤️ [from ESLint core](https://github.com/eslint/eslint/blob/master/docs/rules/space-before-function-paren.md)</sup>
-
-## Attributes
-
-- [ ] ✅ Recommended
-- [x] 🔧 Fixable
-- [ ] 💭 Requires type information

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/space-infix-ops.md

@@ -1,32 +0,0 @@
-# This rule is aimed at ensuring there are spaces around infix operators. (`space-infix-ops`)
-
-This rule extends the base [`eslint/space-infix-ops`](https://eslint.org/docs/rules/space-infix-ops) rule.
-
-It also add support for enum members
-
-```ts
-enum MyEnum {
-  KEY = 'value',
-}
-```
-
-## How to use
-
-```jsonc
-{
-  "space-infix-ops": "off",
-  "@typescript-eslint/space-infix-ops": ["error", { "int32Hint": false }]
-}
-```
-
-## Options
-
-See [`eslint/space-infix-ops` options](https://eslint.org/docs/rules/space-infix-ops#options).
-
-<sup>Taken with ❤️ [from ESLint core](https://github.com/eslint/eslint/blob/master/docs/rules/space-infix-ops.md)</sup>
-
-## Attributes
-
-- [ ] ✅ Recommended
-- [x] 🔧 Fixable
-- [ ] 💭 Requires type information

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/strict-boolean-expressions.md

@@ -1,200 +0,0 @@
-# Restricts the types allowed in boolean expressions (`strict-boolean-expressions`)
-
-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
-
-Examples of **incorrect** code for this rule:
-
-```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();
-}
-```
-
-Examples of **correct** code for this rule:
-
-```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);
-```
-
-## Options
-
-```ts
-type Options = {
-  allowString?: boolean;
-  allowNumber?: boolean;
-  allowNullableObject?: boolean;
-  allowNullableBoolean?: boolean;
-  allowNullableString?: boolean;
-  allowNullableNumber?: boolean;
-  allowAny?: boolean;
-};
-
-const defaultOptions: Options = {
-  allowString: true,
-  allowNumber: true,
-  allowNullableObject: true,
-  allowNullableBoolean: false,
-  allowNullableString: false,
-  allowNullableNumber: false,
-  allowAny: false,
-  allowRuleToRunWithoutStrictNullChecksIKnowWhatIAmDoing: false,
-};
-```
-
-### `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.
-
-### `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)`)
-
-## Related To
-
-- TSLint: [strict-boolean-expressions](https://palantir.github.io/tslint/rules/strict-boolean-expressions)
-
-- [no-unnecessary-condition](./no-unnecessary-condition.md) - Similar rule which reports always-truthy and always-falsy values in conditions
-
-## Attributes
-
-- [ ] ✅ Recommended
-- [x] 🔧 Fixable
-- [x] 💭 Requires type information

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/switch-exhaustiveness-check.md

@@ -1,109 +0,0 @@
-# Exhaustiveness checking in switch with union type (`switch-exhaustiveness-check`)
-
-Union type may have a lot of parts. It's easy to forget to consider all cases in switch. This rule reminds which parts are missing. If domain of the problem requires to have only a partial switch, developer may _explicitly_ add a default clause.
-
-Examples of **incorrect** code for this rule:
-
-```ts
-type Day =
-  | 'Monday'
-  | 'Tuesday'
-  | 'Wednesday'
-  | 'Thursday'
-  | 'Friday'
-  | 'Saturday'
-  | 'Sunday';
-
-const day = 'Monday' as Day;
-let result = 0;
-
-switch (day) {
-  case 'Monday': {
-    result = 1;
-    break;
-  }
-}
-```
-
-Examples of **correct** code for this rule:
-
-```ts
-type Day =
-  | 'Monday'
-  | 'Tuesday'
-  | 'Wednesday'
-  | 'Thursday'
-  | 'Friday'
-  | 'Saturday'
-  | 'Sunday';
-
-const day = 'Monday' as 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;
-  }
-}
-```
-
-or
-
-```ts
-type Day =
-  | 'Monday'
-  | 'Tuesday'
-  | 'Wednesday'
-  | 'Thursday'
-  | 'Friday'
-  | 'Saturday'
-  | 'Sunday';
-
-const day = 'Monday' as Day;
-let result = 0;
-
-switch (day) {
-  case 'Monday': {
-    result = 1;
-    break;
-  }
-  default: {
-    result = 42;
-  }
-}
-```
-
-## When Not To Use It
-
-If program doesn't have union types with many parts. Downside of this rule is the need for type information, so it's slower than regular rules.
-
-## Attributes
-
-- [ ] ✅ Recommended
-- [ ] 🔧 Fixable
-- [x] 💭 Requires type information

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/triple-slash-reference.md

@@ -1,62 +0,0 @@
-# Sets preference level for triple slash directives versus ES6-style import declarations (`triple-slash-reference`)
-
-Use of triple-slash reference type directives is discouraged in favor of the newer `import` style. This rule allows you to ban use of `/// <reference path="" />`, `/// <reference types="" />`, or `/// <reference lib="" />` directives.
-
-## Rule Details
-
-With `{ "path": "never", "types": "never", "lib": "never" }` options set, the following will all be **incorrect** usage:
-
-```ts
-/// <reference path="foo" />
-/// <reference types="bar" />
-/// <reference lib="baz" />
-```
-
-Examples of **incorrect** code for the `{ "types": "prefer-import" }` option. Note that these are only errors when **both** styles are used for the **same** module:
-
-```ts
-/// <reference types="foo" />
-import * as foo from 'foo';
-```
-
-```ts
-/// <reference types="foo" />
-import foo = require('foo');
-```
-
-With `{ "path": "always", "types": "always", "lib": "always" }` options set, the following will all be **correct** usage:
-
-```ts
-/// <reference path="foo" />
-/// <reference types="bar" />
-/// <reference lib="baz" />
-```
-
-Examples of **correct** code for the `{ "types": "prefer-import" }` option:
-
-```ts
-import * as foo from 'foo';
-```
-
-```ts
-import foo = require('foo');
-```
-
-## When To Use It
-
-If you want to ban use of one or all of the triple slash reference directives, or any time you might use triple-slash type reference directives and ES6 import declarations in the same file.
-
-## When Not To Use It
-
-If you want to use all flavors of triple slash reference directives.
-
-## Compatibility
-
-- TSLint: [no-reference](http://palantir.github.io/tslint/rules/no-reference/)
-- TSLint: [no-reference-import](https://palantir.github.io/tslint/rules/no-reference-import/)
-
-## Attributes
-
-- [x] ✅ Recommended
-- [ ] 🔧 Fixable
-- [ ] 💭 Requires type information