xo 0.45.0 → 0.46.3

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/await-thenable.md

@@ -0,0 +1,39 @@
+# Disallows awaiting a value that is not a Thenable (`await-thenable`)
+
+This rule disallows awaiting a value that is not a "Thenable" (an object which has `then` method, such as a Promise).
+While it is valid JavaScript to await a non-`Promise`-like value (it will resolve immediately), this pattern is often a programmer error, such as forgetting to add parenthesis to call a function that returns a Promise.
+
+## Rule Details
+
+Examples of **incorrect** code for this rule:
+
+```ts
+await 'value';
+
+const createValue = () => 'value';
+await createValue();
+```
+
+Examples of **correct** code for this rule:
+
+```ts
+await Promise.resolve('value');
+
+const createValue = async () => 'value';
+await createValue();
+```
+
+## When Not To Use It
+
+If you want to allow code to `await` non-Promise values.
+This is generally not preferred, but can sometimes be useful for visual consistency.
+
+## Related to
+
+- TSLint: ['await-promise'](https://palantir.github.io/tslint/rules/await-promise)
+
+## Attributes
+
+- [x] ✅ Recommended
+- [ ] 🔧 Fixable
+- [x] 💭 Requires type information

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/ban-ts-comment.md

@@ -0,0 +1,138 @@
+# Bans `@ts-<directive>` comments from being used or requires descriptions after directive (`ban-ts-comment`)
+
+TypeScript provides several directive comments that can be used to alter how it processes files.
+Using these to suppress TypeScript Compiler Errors reduces the effectiveness of TypeScript overall.
+
+The directive comments supported by TypeScript are:
+
+```ts
+// @ts-expect-error
+// @ts-ignore
+// @ts-nocheck
+// @ts-check
+```
+
+## Rule Details
+
+This rule lets you set which directive comments you want to allow in your codebase.
+By default, only `@ts-check` is allowed, as it enables rather than suppresses errors.
+
+The configuration looks like this:
+
+```ts
+interface Options {
+  'ts-expect-error'?: boolean | 'allow-with-description';
+  'ts-ignore'?: boolean | 'allow-with-description';
+  'ts-nocheck'?: boolean | 'allow-with-description';
+  'ts-check'?: boolean | 'allow-with-description';
+  minimumDescriptionLength?: number;
+}
+
+const defaultOptions: Options = {
+  'ts-expect-error': 'allow-with-description',
+  'ts-ignore': true,
+  'ts-nocheck': true,
+  'ts-check': false,
+  minimumDescriptionLength: 3,
+};
+```
+
+### `ts-expect-error`, `ts-ignore`, `ts-nocheck`, `ts-check` directives
+
+A value of `true` for a particular directive means that this rule will report if it finds any usage of said directive.
+
+For example, with the defaults above the following patterns are considered warnings for single line or comment block lines:
+
+```ts
+if (false) {
+  // @ts-ignore: Unreachable code error
+  console.log('hello');
+}
+if (false) {
+  /*
+  @ts-ignore: Unreachable code error
+  */
+  console.log('hello');
+}
+```
+
+The following patterns are not warnings:
+
+```ts
+if (false) {
+  // Compiler warns about unreachable code error
+  console.log('hello');
+}
+```
+
+### `allow-with-description`
+
+A value of `'allow-with-description'` for a particular directive means that this rule will report if it finds a directive that does not have a description following the directive (on the same line).
+
+For example, with `{ 'ts-expect-error': 'allow-with-description' }` the following patterns are considered a warning:
+
+```ts
+if (false) {
+  // @ts-expect-error
+  console.log('hello');
+}
+if (false) {
+  /* @ts-expect-error */
+  console.log('hello');
+}
+```
+
+The following patterns are not a warning:
+
+```ts
+if (false) {
+  // @ts-expect-error: Unreachable code error
+  console.log('hello');
+}
+if (false) {
+  /*
+  @ts-expect-error: Unreachable code error
+  */
+  console.log('hello');
+}
+```
+
+### `minimumDescriptionLength`
+
+Use `minimumDescriptionLength` to set a minimum length for descriptions when using the `allow-with-description` option for a directive.
+
+For example, with `{ 'ts-expect-error': 'allow-with-description', minimumDescriptionLength: 10 }` the following pattern is considered a warning:
+
+```ts
+if (false) {
+  // @ts-expect-error: TODO
+  console.log('hello');
+}
+```
+
+The following pattern is not a warning:
+
+```ts
+if (false) {
+  // @ts-expect-error The rationale for this override is described in issue #1337 on GitLab
+  console.log('hello');
+}
+```
+
+## When Not To Use It
+
+If you want to use all of the TypeScript directives.
+
+## Further Reading
+
+- TypeScript [Type Checking JavaScript Files](https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html)
+
+## Compatibility
+
+- TSLint: [ban-ts-ignore](https://palantir.github.io/tslint/rules/ban-ts-ignore/)
+
+## Attributes
+
+- [x] ✅ Recommended
+- [ ] 🔧 Fixable
+- [ ] 💭 Requires type information

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/ban-tslint-comment.md

@@ -0,0 +1,35 @@
+# Bans `// tslint:<rule-flag>` comments from being used (`ban-tslint-comment`)
+
+Useful when migrating from TSLint to ESLint. Once TSLint has been removed, this rule helps locate TSLint annotations (e.g. `// tslint:disable`).
+
+## Rule Details
+
+Examples of **incorrect** code for this rule:
+
+All TSLint [rule flags](https://palantir.github.io/tslint/usage/rule-flags/)
+
+```js
+/* tslint:disable */
+/* tslint:enable */
+/* tslint:disable:rule1 rule2 rule3... */
+/* tslint:enable:rule1 rule2 rule3... */
+// tslint:disable-next-line
+someCode(); // tslint:disable-line
+// tslint:disable-next-line:rule1 rule2 rule3...
+```
+
+Examples of **correct** code for this rule:
+
+```js
+// This is a comment that just happens to mention tslint
+```
+
+## When Not To Use It
+
+If you are still using TSLint.
+
+## Attributes
+
+- [ ] ✅ Recommended
+- [x] 🔧 Fixable
+- [ ] 💭 Requires type information

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/ban-types.md

@@ -0,0 +1,184 @@
+# Bans specific types from being used (`ban-types`)
+
+Some builtin types have aliases, some types are considered dangerous or harmful.
+It's often a good idea to ban certain types to help with consistency and safety.
+
+## Rule Details
+
+This rule bans specific types and can suggest alternatives.
+Note that it does not ban the corresponding runtime objects from being used.
+
+## Options
+
+```ts
+type Options = {
+  types?: {
+    [typeName: string]:
+      | false
+      | string
+      | {
+          message: string;
+          fixWith?: string;
+        };
+  };
+  extendDefaults?: boolean;
+};
+```
+
+The rule accepts a single object as options, with the following keys:
+
+- `types` - An object whose keys are the types you want to ban, and the values are error messages.
+  - The type can either be a type name literal (`Foo`), a type name with generic parameter instantiation(s) (`Foo<Bar>`), the empty object literal (`{}`), or the empty tuple type (`[]`).
+  - The values can be a string, which is the error message to be reported, `false` to specifically disable this type
+    or it can be an object with the following properties:
+    - `message: string` - the message to display when the type is matched.
+    - `fixWith?: string` - a string to replace the banned type with when the fixer is run. If this is omitted, no fix will be done.
+- `extendDefaults` - if you're specifying custom `types`, you can set this to `true` to extend the default `types` configuration.
+  - This is a convenience option to save you copying across the defaults when adding another type.
+  - If this is `false`, the rule will _only_ use the types defined in your configuration.
+
+Example configuration:
+
+```jsonc
+{
+  "@typescript-eslint/ban-types": [
+    "error",
+    {
+      "types": {
+        // add a custom message to help explain why not to use it
+        "Foo": "Don't use Foo because it is unsafe",
+
+        // add a custom message, AND tell the plugin how to fix it
+        "String": {
+          "message": "Use string instead",
+          "fixWith": "string"
+        },
+
+        "{}": {
+          "message": "Use object instead",
+          "fixWith": "object"
+        }
+      }
+    }
+  ]
+}
+```
+
+### Default Options
+
+The default options provide a set of "best practices", intended to provide safety and standardization in your codebase:
+
+- Don't use the upper-case primitive types, you should use the lower-case types for consistency.
+- Avoid the `Function` type, as it provides little safety for the following reasons:
+  - It provides no type safety when calling the value, which means it's easy to provide the wrong arguments.
+  - It accepts class declarations, which will fail when called, as they are called without the `new` keyword.
+- Avoid the `Object` and `{}` types, as they mean "any non-nullish value".
+  - This is a point of confusion for many developers, who think it means "any object type".
+  - See [this comment for more information](https://github.com/typescript-eslint/typescript-eslint/issues/2063#issuecomment-675156492).
+
+**_Important note:_** the default options suggest using `Record<string, unknown>`; this was a stylistic decision, as the built-in `Record` type is considered to look cleaner.
+
+<details>
+<summary>Default Options</summary>
+
+```ts
+const defaultTypes = {
+  String: {
+    message: 'Use string instead',
+    fixWith: 'string',
+  },
+  Boolean: {
+    message: 'Use boolean instead',
+    fixWith: 'boolean',
+  },
+  Number: {
+    message: 'Use number instead',
+    fixWith: 'number',
+  },
+  Symbol: {
+    message: 'Use symbol instead',
+    fixWith: 'symbol',
+  },
+
+  Function: {
+    message: [
+      'The `Function` type accepts any function-like value.',
+      'It provides no type safety when calling the function, which can be a common source of bugs.',
+      'It also accepts things like class declarations, which will throw at runtime as they will not be called with `new`.',
+      'If you are expecting the function to accept certain arguments, you should explicitly define the function shape.',
+    ].join('\n'),
+  },
+
+  // object typing
+  Object: {
+    message: [
+      'The `Object` type actually means "any non-nullish value", so it is marginally better than `unknown`.',
+      '- If you want a type meaning "any object", you probably want `Record<string, unknown>` instead.',
+      '- If you want a type meaning "any value", you probably want `unknown` instead.',
+    ].join('\n'),
+  },
+  '{}': {
+    message: [
+      '`{}` actually means "any non-nullish value".',
+      '- If you want a type meaning "any object", you probably want `Record<string, unknown>` instead.',
+      '- If you want a type meaning "any value", you probably want `unknown` instead.',
+    ].join('\n'),
+  },
+};
+```
+
+</details>
+
+### Examples
+
+Examples of **incorrect** code with the default options:
+
+```ts
+// use lower-case primitives for consistency
+const str: String = 'foo';
+const bool: Boolean = true;
+const num: Number = 1;
+const symb: Symbol = Symbol('foo');
+
+// use a proper function type
+const func: Function = () => 1;
+
+// use safer object types
+const capitalObj1: Object = 1;
+const capitalObj2: Object = { a: 'string' };
+
+const curly1: {} = 1;
+const curly2: {} = { a: 'string' };
+```
+
+Examples of **correct** code with the default options:
+
+```ts
+// use lower-case primitives for consistency
+const str: string = 'foo';
+const bool: boolean = true;
+const num: number = 1;
+const symb: symbol = Symbol('foo');
+
+// use a proper function type
+const func: () => number = () => 1;
+
+// use safer object types
+const lowerObj: object = {};
+
+const capitalObj1: number = 1;
+const capitalObj2: { a: string } = { a: 'string' };
+
+const curly1: number = 1;
+const curly2: Record<'a', string> = { a: 'string' };
+```
+
+## Compatibility
+
+- TSLint: [ban-types](https://palantir.github.io/tslint/rules/ban-types)
+
+## Attributes
+
+- [x] ✅ Recommended
+- [x] 🔧 Fixable
+- [ ] 💭 Requires type information

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/brace-style.md

@@ -0,0 +1,28 @@
+# Enforce consistent brace style for blocks (`brace-style`)
+
+## Rule Details
+
+This rule extends the base [`eslint/brace-style`](https://eslint.org/docs/rules/brace-style) rule.
+It adds support for `enum`, `interface`, `namespace` and `module` declarations.
+
+## How to use
+
+```jsonc
+{
+  // note you must disable the base rule as it can report incorrect errors
+  "brace-style": "off",
+  "@typescript-eslint/brace-style": ["error"]
+}
+```
+
+## Options
+
+See [`eslint/brace-style` options](https://eslint.org/docs/rules/brace-style#options).
+
+<sup>Taken with ❤️ [from ESLint core](https://github.com/eslint/eslint/blob/master/docs/rules/brace-style.md)</sup>
+
+## Attributes
+
+- [ ] ✅ Recommended
+- [x] 🔧 Fixable
+- [ ] 💭 Requires type information

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/camelcase.md

@@ -0,0 +1,8 @@
+## DEPRECATED
+
+This rule has been deprecated in favour of the [`naming-convention`](./naming-convention.md) rule.
+
+<!--
+This doc file has been left on purpose because `camelcase` is a core eslint rule.
+This exists to help direct people to the replacement rule.
+-->

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/class-literal-property-style.md

@@ -0,0 +1,102 @@
+# Ensures that literals on classes are exposed in a consistent style (`class-literal-property-style`)
+
+When writing TypeScript applications, it's typically safe to store literal values on classes using fields with the `readonly` modifier to prevent them from being reassigned.
+When writing TypeScript libraries that could be used by JavaScript users however, it's typically safer to expose these literals using `getter`s, since the `readonly` modifier is enforced at compile type.
+
+## Rule Details
+
+This rule aims to ensure that literals exposed by classes are done so consistently, in one of the two style described above.
+By default this rule prefers the `fields` style as it means JS doesn't have to setup & teardown a function closure.
+
+Note that this rule only checks for constant _literal_ values (string, template string, number, bigint, boolean, regexp, null). It does not check objects or arrays, because a readonly field behaves differently to a getter in those cases. It also does not check functions, as it is a common pattern to use readonly fields with arrow function values as auto-bound methods.
+This is because these types can be mutated and carry with them more complex implications about their usage.
+
+### The `fields` style
+
+This style checks for any getter methods that return literal values, and requires them to be defined using fields with the `readonly` modifier instead.
+
+Examples of **correct** code with the `fields` style:
+
+```ts
+/* eslint @typescript-eslint/class-literal-property-style: ["error", "fields"] */
+
+class Mx {
+  public readonly myField1 = 1;
+
+  // not a literal
+  public readonly myField2 = [1, 2, 3];
+
+  private readonly ['myField3'] = 'hello world';
+
+  public get myField4() {
+    return `hello from ${window.location.href}`;
+  }
+}
+```
+
+Examples of **incorrect** code with the `fields` style:
+
+```ts
+/* eslint @typescript-eslint/class-literal-property-style: ["error", "fields"] */
+
+class Mx {
+  public static get myField1() {
+    return 1;
+  }
+
+  private get ['myField2']() {
+    return 'hello world';
+  }
+}
+```
+
+### The `getters` style
+
+This style checks for any `readonly` fields that are assigned literal values, and requires them to be defined as getters instead.
+This style pairs well with the [`@typescript-eslint/prefer-readonly`](prefer-readonly.md) rule,
+as it will identify fields that can be `readonly`, and thus should be made into getters.
+
+Examples of **correct** code with the `getters` style:
+
+```ts
+/* eslint @typescript-eslint/class-literal-property-style: ["error", "getters"] */
+
+class Mx {
+  // no readonly modifier
+  public myField1 = 'hello';
+
+  // not a literal
+  public readonly myField2 = [1, 2, 3];
+
+  public static get myField3() {
+    return 1;
+  }
+
+  private get ['myField4']() {
+    return 'hello world';
+  }
+}
+```
+
+Examples of **incorrect** code with the `getters` style:
+
+```ts
+/* eslint @typescript-eslint/class-literal-property-style: ["error", "getters"] */
+
+class Mx {
+  readonly myField1 = 1;
+  readonly myField2 = `hello world`;
+  private readonly myField3 = 'hello world';
+}
+```
+
+## When Not To Use It
+
+When you have no strong preference, or do not wish to enforce a particular style
+for how literal values are exposed by your classes.
+
+## Attributes
+
+- [ ] ✅ Recommended
+- [x] 🔧 Fixable
+- [ ] 💭 Requires type information

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/comma-dangle.md

@@ -0,0 +1,40 @@
+# Require or disallow trailing comma (`comma-dangle`)
+
+## Rule Details
+
+This rule extends the base [`eslint/comma-dangle`](https://eslint.org/docs/rules/comma-dangle) rule.
+It adds support for TypeScript syntax.
+
+See the [ESLint documentation](https://eslint.org/docs/rules/comma-dangle) for more details on the `comma-dangle` rule.
+
+## Rule Changes
+
+```cjson
+{
+  // note you must disable the base rule as it can report incorrect errors
+  "comma-dangle": "off",
+  "@typescript-eslint/comma-dangle": ["error"]
+}
+```
+
+In addition to the options supported by the `comma-dangle` rule in ESLint core, the rule adds the following options:
+
+## Options
+
+This rule has a string option and an object option.
+
+- Object option:
+
+  - `"enums"` is for trailing comma in enum. (e.g. `enum Foo = {Bar,}`)
+  - `"generics"` is for trailing comma in generic. (e.g. `function foo<T,>() {}`)
+  - `"tuples"` is for trailing comma in tuple. (e.g. `type Foo = [string,]`)
+
+- [See the other options allowed](https://github.com/eslint/eslint/blob/master/docs/rules/comma-dangle.md#options)
+
+<sup>Taken with ❤️ [from ESLint core](https://github.com/eslint/eslint/blob/master/docs/rules/comma-dangle.md)</sup>
+
+## Attributes
+
+- [ ] ✅ Recommended
+- [x] 🔧 Fixable
+- [ ] 💭 Requires type information

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/comma-spacing.md

@@ -0,0 +1,28 @@
+# Enforces consistent spacing before and after commas (`comma-spacing`)
+
+## Rule Details
+
+This rule extends the base [`eslint/comma-spacing`](https://eslint.org/docs/rules/comma-spacing) rule.
+It adds support for trailing comma in a types parameters list.
+
+## How to use
+
+```jsonc
+{
+  // note you must disable the base rule as it can report incorrect errors
+  "comma-spacing": "off",
+  "@typescript-eslint/comma-spacing": ["error"]
+}
+```
+
+## Options
+
+See [`eslint/comma-spacing` options](https://eslint.org/docs/rules/comma-spacing#options).
+
+<sup>Taken with ❤️ [from ESLint core](https://github.com/eslint/eslint/blob/master/docs/rules/comma-spacing.md)</sup>
+
+## Attributes
+
+- [ ] ✅ Recommended
+- [x] 🔧 Fixable
+- [ ] 💭 Requires type information

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/consistent-indexed-object-style.md

@@ -0,0 +1,73 @@
+# Enforce or disallow the use of the record type (`consistent-indexed-object-style`)
+
+TypeScript supports defining object show keys can be flexible using an index signature. TypeScript also has a builtin type named `Record` to create an empty object defining only an index signature. For example, the following types are equal:
+
+```ts
+interface Foo {
+  [key: string]: unknown;
+}
+
+type Foo = {
+  [key: string]: unknown;
+};
+
+type Foo = Record<string, unknown>;
+```
+
+## Options
+
+- `"record"`: Set to `"record"` to only allow the `Record` type. Set to `"index-signature"` to only allow index signatures. (Defaults to `"record"`)
+
+For example:
+
+```CJSON
+{
+    "@typescript-eslint/consistent-indexed-object-style": ["error", "index-signature"]
+}
+```
+
+## Rule details
+
+This rule enforces a consistent way to define records.
+
+Examples of **incorrect** code with `record` option.
+
+```ts
+interface Foo {
+  [key: string]: unknown;
+}
+
+type Foo = {
+  [key: string]: unknown;
+};
+```
+
+Examples of **correct** code with `record` option.
+
+```ts
+type Foo = Record<string, unknown>;
+```
+
+Examples of **incorrect** code with `index-signature` option.
+
+```ts
+type Foo = Record<string, unknown>;
+```
+
+Examples of **correct** code with `index-signature` option.
+
+```ts
+interface Foo {
+  [key: string]: unknown;
+}
+
+type Foo = {
+  [key: string]: unknown;
+};
+```
+
+## Attributes
+
+- [ ] ✅ Recommended
+- [x] 🔧 Fixable
+- [ ] 💭 Requires type information