xo 0.45.0 → 0.46.3

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/consistent-type-assertions.md

@@ -0,0 +1,100 @@
+# Enforces consistent usage of type assertions (`consistent-type-assertions`)
+
+## Rule Details
+
+This rule aims to standardize the use of type assertion style across the codebase.
+
+Type assertions are also commonly referred as "type casting" in TypeScript (even though it is technically slightly different to what is understood by type casting in other languages), so you can think of type assertions and type casting referring to the same thing. It is essentially you saying to the TypeScript compiler, "in this case, I know better than you!".
+
+In addition to ensuring that type assertions are written in a consistent way, this rule also helps make your codebase more type-safe.
+
+`const` assertions, [introduced in TypeScript 3.4](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-4.html#const-assertions), is always allowed by this rule. Examples of it include `let x = "hello" as const;` and `let x = <const>"hello";`.
+
+## Options
+
+```ts
+type Options =
+  | {
+      assertionStyle: 'as' | 'angle-bracket';
+      objectLiteralTypeAssertions: 'allow' | 'allow-as-parameter' | 'never';
+    }
+  | {
+      assertionStyle: 'never';
+    };
+
+const defaultOptions: Options = {
+  assertionStyle: 'as',
+  objectLiteralTypeAssertions: 'allow',
+};
+```
+
+### `assertionStyle`
+
+This option defines the expected assertion style. Valid values for `assertionStyle` are:
+
+- `as` will enforce that you always use `... as foo`.
+- `angle-bracket` will enforce that you always use `<foo>...`
+- `never` will enforce that you do not do any type assertions.
+
+Most codebases will want to enforce not using `angle-bracket` style because it conflicts with JSX syntax, and is confusing when paired with generic syntax.
+
+Some codebases like to go for an extra level of type safety, and ban assertions altogether via the `never` option.
+
+### `objectLiteralTypeAssertions`
+
+Always prefer `const x: T = { ... };` to `const x = { ... } as T;` (or similar with angle brackets). The type assertion in the latter case is either unnecessary or will probably hide an error.
+
+The compiler will warn for excess properties with this syntax, but not missing _required_ fields. For example: `const x: { foo: number } = {};` will fail to compile, but `const x = {} as { foo: number }` will succeed.
+
+The const assertion `const x = { foo: 1 } as const`, introduced in TypeScript 3.4, is considered beneficial and is ignored by this option.
+
+Assertions to `any` are also ignored by this option.
+
+Examples of **incorrect** code for `{ assertionStyle: 'as', objectLiteralTypeAssertions: 'never' }` (and for `{ assertionStyle: 'as', objectLiteralTypeAssertions: 'allow-as-parameter' }`)
+
+```ts
+const x = { ... } as T;
+
+function foo() {
+  return { ... } as T;
+}
+```
+
+Examples of **correct** code for `{ assertionStyle: 'as', objectLiteralTypeAssertions: 'never' }`.
+
+```ts
+const x: T = { ... };
+const y = { ... } as any;
+const z = { ... } as unknown;
+
+function foo(): T {
+  return { ... };
+}
+```
+
+Examples of **correct** code for `{ assertionStyle: 'as', objectLiteralTypeAssertions: 'allow-as-parameter' }`.
+
+```tsx
+const x: T = { ... };
+const y = { ... } as any;
+const z = { ... } as unknown;
+foo({ ... } as T);
+new Clazz({ ... } as T);
+function foo() { throw { bar: 5 } as Foo }
+const foo = <Foo props={{ ... } as Bar}/>;
+```
+
+## When Not To Use It
+
+If you do not want to enforce consistent type assertions.
+
+## Compatibility
+
+- TSLint: [no-angle-bracket-type-assertion](https://palantir.github.io/tslint/rules/no-angle-bracket-type-assertion/)
+- TSLint: [no-object-literal-type-assertion](https://palantir.github.io/tslint/rules/no-object-literal-type-assertion/)
+
+## Attributes
+
+- [ ] ✅ Recommended
+- [ ] 🔧 Fixable
+- [ ] 💭 Requires type information

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/consistent-type-definitions.md

@@ -0,0 +1,80 @@
+# Consistent with type definition either `interface` or `type` (`consistent-type-definitions`)
+
+There are two ways to define a type.
+
+```ts
+// type alias
+type T1 = {
+  a: string;
+  b: number;
+};
+
+// interface keyword
+interface T2 {
+  a: string;
+  b: number;
+}
+```
+
+## Options
+
+This rule accepts one string option:
+
+- `"interface"`: enforce using `interface`s for object type definitions.
+- `"type"`: enforce using `type`s for object type definitions.
+
+For example:
+
+```jsonc
+{
+  // Use type for object definitions
+  "@typescript-eslint/consistent-type-definitions": ["error", "type"]
+}
+```
+
+## Rule Details
+
+Examples of **incorrect** code with `interface` option.
+
+```ts
+type T = { x: number };
+```
+
+Examples of **correct** code with `interface` option.
+
+```ts
+type T = string;
+type Foo = string | {};
+
+interface T {
+  x: number;
+}
+```
+
+Examples of **incorrect** code with `type` option.
+
+```ts
+interface T {
+  x: number;
+}
+```
+
+Examples of **correct** code with `interface` option.
+
+```ts
+type T = { x: number };
+```
+
+## When Not To Use It
+
+If you specifically want to use an interface or type literal for stylistic reasons, you can disable this rule.
+
+## Compatibility
+
+- TSLint: [interface-over-type-literal](https://palantir.github.io/tslint/rules/interface-over-type-literal/)
+
+## Attributes
+
+- [ ] ✅ Recommended
+- [x] 🔧 Fixable
+- [ ] 💭 Requires type information

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/consistent-type-exports.md

@@ -0,0 +1,34 @@
+# Enforces consistent usage of type exports (`consistent-type-exports`)
+
+TypeScript 3.8 added support for type-only exports.
+
+Type-only exports allow you to specify that 1 or more named exports are exported as type-only. This allows
+transpilers to drop exports without knowing the types of the dependencies.
+
+## Rule Details
+
+This rule aims to standardize the use of type exports style across a codebase.
+
+Given a class `Button`, and an interface `ButtonProps`, examples of **correct** code:
+
+```ts
+export { Button } from 'some-library';
+export type { ButtonProps } from 'some-library';
+```
+
+Examples of **incorrect** code:
+
+```ts
+export { Button, ButtonProps } from 'some-library';
+```
+
+## When Not To Use It
+
+- If you are using a TypeScript version less than 3.8, then you will not be able to use this rule as type exports are not supported.
+- If you specifically want to use both export kinds for stylistic reasons, you can disable this rule.
+
+## Attributes
+
+- [ ] ✅ Recommended
+- [x] 🔧 Fixable
+- [x] 💭 Requires type information

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/consistent-type-imports.md

@@ -0,0 +1,70 @@
+# Enforces consistent usage of type imports (`consistent-type-imports`)
+
+TypeScript 3.8 added support for type-only imports.
+Type-only imports allow you to specify that an import can only be used in a type location, allowing certain optimizations within compilers.
+
+## Rule Details
+
+This rule aims to standardize the use of type imports style across the codebase.
+
+## Options
+
+```ts
+type Options = {
+  prefer: 'type-imports' | 'no-type-imports';
+  disallowTypeAnnotations: boolean;
+};
+
+const defaultOptions: Options = {
+  prefer: 'type-imports',
+  disallowTypeAnnotations: true,
+};
+```
+
+### `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 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
+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
+import { Foo } from 'Foo';
+import Bar from 'Bar';
+type T = Foo;
+const x: Bar = 1;
+```
+
+### `disallowTypeAnnotations`
+
+If `true`, type imports in type annotations (`import()`) is not allowed.
+Default is `true`.
+
+Examples of **incorrect** code with `{disallowTypeAnnotations: true}`.
+
+```ts
+type T = import('Foo').Foo;
+const x: import('Bar') = 1;
+```
+
+## When Not To Use It
+
+- If you are not using TypeScript 3.8 (or greater), then you will not be able to use this rule, as type-only imports are not allowed.
+- If you specifically want to use both import kinds for stylistic reasons, you can disable this rule.
+
+## Attributes
+
+- [ ] ✅ Recommended
+- [x] 🔧 Fixable
+- [ ] 💭 Requires type information

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/default-param-last.md

@@ -0,0 +1,62 @@
+# Enforce default parameters to be last (`default-param-last`)
+
+## Rule Details
+
+This rule extends the base [`eslint/default-param-last`](https://eslint.org/docs/rules/default-param-last) rule.
+It adds support for optional parameters.
+
+Examples of **incorrect** code for this rule:
+
+```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) {}
+}
+```
+
+Examples of **correct** code for this rule:
+
+```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) {}
+}
+```
+
+## How to use
+
+```jsonc
+{
+  // note you must disable the base rule as it can report incorrect errors
+  "default-param-last": "off",
+  "@typescript-eslint/default-param-last": ["error"]
+}
+```
+
+## Options
+
+See [`eslint/default-param-last` options](https://eslint.org/docs/rules/default-param-last#options).
+
+<sup>Taken with ❤️ [from ESLint core](https://github.com/eslint/eslint/blob/master/docs/rules/default-param-last.md)</sup>
+
+## Attributes
+
+- [ ] ✅ Recommended
+- [ ] 🔧 Fixable
+- [ ] 💭 Requires type information

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

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

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/explicit-function-return-type.md

@@ -0,0 +1,254 @@
+# Require explicit return types on functions and class methods (`explicit-function-return-type`)
+
+Explicit types for function return values makes it clear to any calling code what type is returned.
+This ensures that the return value is assigned to a variable of the correct type; or in the case
+where there is no return value, that the calling code doesn't try to use the undefined value when it
+shouldn't.
+
+## Rule Details
+
+This rule aims to ensure that the values returned from functions are of the expected type.
+
+The following patterns are considered warnings:
+
+```ts
+// Should indicate that no value is returned (void)
+function test() {
+  return;
+}
+
+// Should indicate that a number is returned
+var fn = function () {
+  return 1;
+};
+
+// Should indicate that a string is returned
+var arrowFn = () => 'test';
+
+class Test {
+  // Should indicate that no value is returned (void)
+  method() {
+    return;
+  }
+}
+```
+
+The following patterns are not warnings:
+
+```ts
+// No return value should be expected (void)
+function test(): void {
+  return;
+}
+
+// A return value of type number
+var fn = function (): number {
+  return 1;
+};
+
+// A return value of type string
+var arrowFn = (): string => 'test';
+
+class Test {
+  // No return value should be expected (void)
+  method(): void {
+    return;
+  }
+}
+```
+
+## Options
+
+The rule accepts an options object with the following properties:
+
+```ts
+type Options = {
+  // if true, only functions which are part of a declaration will be checked
+  allowExpressions?: boolean;
+  // if true, type annotations are also allowed on the variable of a function expression rather than on the function directly
+  allowTypedFunctionExpressions?: boolean;
+  // if true, functions immediately returning another function expression will not be checked
+  allowHigherOrderFunctions?: boolean;
+  // if true, arrow functions immediately returning a `as const` value will not be checked
+  allowDirectConstAssertionInArrowFunctions?: boolean;
+  // if true, concise arrow functions that start with the void keyword will not be checked
+  allowConciseArrowFunctionExpressionsStartingWithVoid?: boolean;
+};
+
+const defaults = {
+  allowExpressions: false,
+  allowTypedFunctionExpressions: true,
+  allowHigherOrderFunctions: true,
+  allowDirectConstAssertionInArrowFunctions: true,
+  allowConciseArrowFunctionExpressionsStartingWithVoid: false,
+};
+```
+
+### Configuring in a mixed JS/TS codebase
+
+If you are working on a codebase within which you lint non-TypeScript code (i.e. `.js`/`.jsx`), you should ensure that you should use [ESLint `overrides`](https://eslint.org/docs/user-guide/configuring#disabling-rules-only-for-a-group-of-files) to only enable the rule on `.ts`/`.tsx` files. If you don't, then you will get unfixable lint errors reported within `.js`/`.jsx` files.
+
+```jsonc
+{
+  "rules": {
+    // disable the rule for all files
+    "@typescript-eslint/explicit-function-return-type": "off"
+  },
+  "overrides": [
+    {
+      // enable the rule specifically for TypeScript files
+      "files": ["*.ts", "*.tsx"],
+      "rules": {
+        "@typescript-eslint/explicit-function-return-type": ["error"]
+      }
+    }
+  ]
+}
+```
+
+### `allowExpressions`
+
+Examples of **incorrect** code for this rule with `{ allowExpressions: true }`:
+
+```ts
+function test() {}
+
+const fn = () => {};
+
+export default () => {};
+```
+
+Examples of **correct** code for this rule with `{ allowExpressions: true }`:
+
+```ts
+node.addEventListener('click', () => {});
+
+node.addEventListener('click', function () {});
+
+const foo = arr.map(i => i * i);
+```
+
+### `allowTypedFunctionExpressions`
+
+Examples of **incorrect** code for this rule with `{ allowTypedFunctionExpressions: true }`:
+
+```ts
+let arrowFn = () => 'test';
+
+let funcExpr = function () {
+  return 'test';
+};
+
+let objectProp = {
+  foo: () => 1,
+};
+```
+
+Examples of additional **correct** code for this rule with `{ allowTypedFunctionExpressions: true }`:
+
+```ts
+type FuncType = () => string;
+
+let arrowFn: FuncType = () => 'test';
+
+let funcExpr: FuncType = function() {
+  return 'test';
+};
+
+let asTyped = (() => '') as () => string;
+let castTyped = <() => string>(() => '');
+
+interface ObjectType {
+  foo(): number;
+}
+let objectProp: ObjectType = {
+  foo: () => 1,
+};
+let objectPropAs = {
+  foo: () => 1,
+} as ObjectType;
+let objectPropCast = <ObjectType>{
+  foo: () => 1,
+};
+
+declare functionWithArg(arg: () => number);
+functionWithArg(() => 1);
+
+declare functionWithObjectArg(arg: { method: () => number });
+functionWithObjectArg({
+  method() {
+    return 1;
+  },
+});
+```
+
+### `allowHigherOrderFunctions`
+
+Examples of **incorrect** code for this rule with `{ allowHigherOrderFunctions: true }`:
+
+```ts
+var arrowFn = () => () => {};
+
+function fn() {
+  return function () {};
+}
+```
+
+Examples of **correct** code for this rule with `{ allowHigherOrderFunctions: true }`:
+
+```ts
+var arrowFn = () => (): void => {};
+
+function fn() {
+  return function (): void {};
+}
+```
+
+### `allowDirectConstAssertionInArrowFunctions`
+
+Examples of **incorrect** code for this rule with `{ allowDirectConstAssertionInArrowFunctions: true }`:
+
+```ts
+const func = (value: number) => ({ type: 'X', value } as any);
+const func = (value: number) => ({ type: 'X', value } as Action);
+```
+
+Examples of **correct** code for this rule with `{ allowDirectConstAssertionInArrowFunctions: true }`:
+
+```ts
+const func = (value: number) => ({ foo: 'bar', value } as const);
+const func = () => x as const;
+```
+
+### `allowConciseArrowFunctionExpressionsStartingWithVoid`
+
+Examples of **incorrect** code for this rule with `{ allowConciseArrowFunctionExpressionsStartingWithVoid: true }`:
+
+```ts
+var join = (a: string, b: string) => `${a}${b}`;
+
+const log = (message: string) => {
+  console.log(message);
+};
+```
+
+Examples of **correct** code for this rule with `{ allowConciseArrowFunctionExpressionsStartingWithVoid: true }`:
+
+```ts
+var log = (message: string) => void console.log(message);
+```
+
+## When Not To Use It
+
+If you don't wish to prevent calling code from using function return values in unexpected ways, then
+you will not need this rule.
+
+## Further Reading
+
+- TypeScript [Functions](https://www.typescriptlang.org/docs/handbook/functions.html#function-types)
+
+## Attributes
+
+- [ ] ✅ Recommended
+- [ ] 🔧 Fixable
+- [ ] 💭 Requires type information