xo 0.45.0 → 0.46.3

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/prefer-for-of.md

@@ -0,0 +1,47 @@
+# Prefer a ‘for-of’ loop over a standard ‘for’ loop if the index is only used to access the array being iterated (`prefer-for-of`)
+
+This rule recommends a for-of loop when the loop index is only used to read from an array that is being iterated.
+
+## Rule Details
+
+For cases where the index is only used to read from the array being iterated, a for-of loop is easier to read and write.
+
+Examples of **incorrect** code for this rule:
+
+```js
+for (let i = 0; i < arr.length; i++) {
+  console.log(arr[i]);
+}
+```
+
+Examples of **correct** code for this rule:
+
+```js
+for (const x of arr) {
+  console.log(x);
+}
+
+for (let i = 0; i < arr.length; i++) {
+  // i is used to write to arr, so for-of could not be used.
+  arr[i] = 0;
+}
+
+for (let i = 0; i < arr.length; i++) {
+  // i is used independent of arr, so for-of could not be used.
+  console.log(i, arr[i]);
+}
+```
+
+## When Not To Use It
+
+If you transpile for browsers that do not support for-of loops, you may wish to use traditional for loops that produce more compact code.
+
+## Related to
+
+- TSLint: ['prefer-for-of'](https://palantir.github.io/tslint/rules/prefer-for-of/)
+
+## Attributes
+
+- [ ] ✅ Recommended
+- [ ] 🔧 Fixable
+- [ ] 💭 Requires type information

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

@@ -0,0 +1,87 @@
+# Use function types instead of interfaces with call signatures (`prefer-function-type`)
+
+## Rule Details
+
+This rule suggests using a function type instead of an interface or object type literal with a single call signature.
+
+Examples of **incorrect** code for this rule:
+
+```ts
+interface Foo {
+  (): string;
+}
+```
+
+```ts
+function foo(bar: { (): number }): number {
+  return bar();
+}
+```
+
+```ts
+interface Foo extends Function {
+  (): void;
+}
+```
+
+```ts
+interface MixinMethod {
+  // returns the function itself, not the `this` argument.
+  (arg: string): this;
+}
+```
+
+Examples of **correct** code for this rule:
+
+```ts
+interface Foo {
+  (): void;
+  bar: number;
+}
+```
+
+```ts
+function foo(bar: { (): string; baz: number }): string {
+  return bar();
+}
+```
+
+```ts
+interface Foo {
+  bar: string;
+}
+interface Bar extends Foo {
+  (): void;
+}
+```
+
+```ts
+// returns the `this` argument of function, retaining it's type.
+type MixinMethod = <TSelf>(this: TSelf, arg: string) => TSelf;
+// a function that returns itself is much clearer in this form.
+type ReturnsSelf = (arg: string) => ReturnsSelf;
+```
+
+```ts
+// multiple call signatures (overloads) is allowed:
+interface Overloaded {
+  (data: string): number;
+  (id: number): string;
+}
+// this is equivelent to Overloaded interface.
+type Intersection = ((data: string) => number) & ((id: number) => string);
+```
+
+## When Not To Use It
+
+If you specifically want to use an interface or type literal with a single call signature for stylistic reasons, you can disable this rule.
+
+## Further Reading
+
+- TSLint: [`callable-types`](https://palantir.github.io/tslint/rules/callable-types/)
+
+## Attributes
+
+- [ ] ✅ Recommended
+- [x] 🔧 Fixable
+- [ ] 💭 Requires type information

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

@@ -0,0 +1,79 @@
+# Enforce `includes` method over `indexOf` method (`prefer-includes`)
+
+Until ES5, we were using `String#indexOf` method to check whether a string contains an arbitrary substring or not.
+Until ES2015, we were using `Array#indexOf` method to check whether an array contains an arbitrary value or not.
+
+ES2015 has added `String#includes` and ES2016 has added `Array#includes`.
+It makes code more understandable if we use those `includes` methods for the purpose.
+
+## Rule Details
+
+This rule is aimed at suggesting `includes` method if `indexOf` method was used to check whether an object contains an arbitrary value or not.
+
+If the receiver object of the `indexOf` method call has `includes` method and the two methods have the same parameters, this rule does suggestion.
+There are such types: `String`, `Array`, `ReadonlyArray`, and typed arrays.
+
+Additionally, this rule reports the tests of simple regular expressions in favor of `String#includes`.
+
+Examples of **incorrect** code for this rule:
+
+```ts
+let str: string;
+let array: any[];
+let readonlyArray: ReadonlyArray<any>;
+let typedArray: UInt8Array;
+let maybe: string;
+let userDefined: {
+  indexOf(x: any): number;
+  includes(x: any): boolean;
+};
+
+str.indexOf(value) !== -1;
+array.indexOf(value) !== -1;
+readonlyArray.indexOf(value) === -1;
+typedArray.indexOf(value) > -1;
+maybe?.indexOf('') !== -1;
+userDefined.indexOf(value) >= 0;
+
+// simple RegExp test
+/foo/.test(str);
+```
+
+Examples of **correct** code for this rule:
+
+```ts
+let array: any[];
+let readonlyArray: ReadonlyArray<any>;
+let typedArray: UInt8Array;
+let userDefined: {
+  indexOf(x: any): number;
+  includes(x: any): boolean;
+};
+let mismatchExample: {
+  indexOf(x: any, fromIndex?: number): number;
+  includes(x: any): boolean;
+};
+
+str.includes(value);
+array.includes(value);
+readonlyArray.includes(value);
+typedArray.includes(value);
+userDefined.includes(value);
+
+// the two methods have different parameters.
+mismatchExample.indexOf(value) >= 0;
+```
+
+## Options
+
+There are no options.
+
+## When Not To Use It
+
+If you don't want to suggest `includes`, you can safely turn this rule off.
+
+## Attributes
+
+- [ ] ✅ Recommended
+- [x] 🔧 Fixable
+- [x] 💭 Requires type information

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/prefer-literal-enum-member.md

@@ -0,0 +1,92 @@
+# Require that all enum members be literal values to prevent unintended enum member name shadow issues (`prefer-literal-enum-member`)
+
+TypeScript allows the value of an enum member to be many different kinds of valid JavaScript expressions. However, because enums create their own scope whereby each enum member becomes a variable in that scope, unexpected values could be used at runtime. Example:
+
+```ts
+const imOutside = 2;
+const b = 2;
+enum Foo {
+  outer = imOutside,
+  a = 1,
+  b = a,
+  c = b,
+  // does c == Foo.b == Foo.c == 1?
+  // or does c == b == 2?
+}
+```
+
+The answer is that `Foo.c` will be `1` at runtime. The [playground](https://www.typescriptlang.org/play/#src=const%20imOutside%20%3D%202%3B%0D%0Aconst%20b%20%3D%202%3B%0D%0Aenum%20Foo%20%7B%0D%0A%20%20%20%20outer%20%3D%20imOutside%2C%0D%0A%20%20%20%20a%20%3D%201%2C%0D%0A%20%20%20%20b%20%3D%20a%2C%0D%0A%20%20%20%20c%20%3D%20b%2C%0D%0A%20%20%20%20%2F%2F%20does%20c%20%3D%3D%20Foo.b%20%3D%3D%20Foo.c%20%3D%3D%201%3F%0D%0A%20%20%20%20%2F%2F%20or%20does%20c%20%3D%3D%20b%20%3D%3D%202%3F%0D%0A%7D) illustrates this quite nicely.
+
+## Rule Details
+
+This rule is meant to prevent unexpected results in code by requiring the use of literal values as enum members to prevent unexpected runtime behavior. Template literals, arrays, objects, constructors, and all other expression types can end up using a variable from its scope or the parent scope, which can result in the same unexpected behavior at runtime.
+
+## Options
+
+- `allowBitwiseExpressions` set to `true` will allow you to use bitwise expressions in enum initializer (Default: `false`).
+
+Examples of **incorrect** code for this rule:
+
+```ts
+const str = 'Test';
+enum Invalid {
+  A = str, // Variable assignment
+  B = {}, // Object assignment
+  C = `A template literal string`, // Template literal
+  D = new Set(1, 2, 3), // Constructor in assignment
+  E = 2 + 2, // Expression assignment
+}
+```
+
+Examples of **correct** code for this rule:
+
+```ts
+enum Valid {
+  A,
+  B = 'TestStr', // A regular string
+  C = 4, // A number
+  D = null,
+  E = /some_regex/,
+}
+```
+
+### `allowBitwiseExpressions`
+
+Examples of **incorrect** code for the `{ "allowBitwiseExpressions": true }` option:
+
+```ts
+const x = 1;
+enum Foo {
+  A = x << 0,
+  B = x >> 0,
+  C = x >>> 0,
+  D = x | 0,
+  E = x & 0,
+  F = x ^ 0,
+  G = ~x,
+}
+```
+
+Examples of **correct** code for the `{ "allowBitwiseExpressions": true }` option:
+
+```ts
+enum Foo {
+  A = 1 << 0,
+  B = 1 >> 0,
+  C = 1 >>> 0,
+  D = 1 | 0,
+  E = 1 & 0,
+  F = 1 ^ 0,
+  G = ~1,
+}
+```
+
+## When Not To Use It
+
+If you want use anything other than simple literals as an enum value.
+
+## Attributes
+
+- [ ] ✅ Recommended
+- [ ] 🔧 Fixable
+- [ ] 💭 Requires type information

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/prefer-namespace-keyword.md

@@ -0,0 +1,28 @@
+# Require the use of the `namespace` keyword instead of the `module` keyword to declare custom TypeScript modules (`prefer-namespace-keyword`)
+
+In an effort to prevent further confusion between custom TypeScript modules and the new ES2015 modules, starting
+with TypeScript `v1.5` the keyword `namespace` is now the preferred way to declare custom TypeScript modules.
+
+## Rule Details
+
+This rule aims to standardize the way modules are declared.
+
+## When Not To Use It
+
+If you are using the ES2015 module syntax, then you will not need this rule.
+
+## Further Reading
+
+- [Modules](https://www.typescriptlang.org/docs/handbook/modules.html)
+- [Namespaces](https://www.typescriptlang.org/docs/handbook/namespaces.html)
+- [Namespaces and Modules](https://www.typescriptlang.org/docs/handbook/namespaces-and-modules.html)
+
+## Compatibility
+
+- TSLint: [no-internal-module](https://palantir.github.io/tslint/rules/no-internal-module/)
+
+## Attributes
+
+- [x] ✅ Recommended
+- [x] 🔧 Fixable
+- [ ] 💭 Requires type information

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/prefer-nullish-coalescing.md

@@ -0,0 +1,147 @@
+# Enforce the usage of the nullish coalescing operator instead of logical chaining (`prefer-nullish-coalescing`)
+
+TypeScript 3.7 added support for the nullish coalescing operator.
+This operator allows you to safely cascade a value when dealing with `null` or `undefined`.
+
+```ts
+function myFunc(foo: string | null) {
+  return foo ?? 'a string';
+}
+
+// is equivalent to
+
+function myFunc(foo: string | null) {
+  return foo !== null && foo !== undefined ? foo : 'a string';
+}
+```
+
+Because the nullish coalescing operator _only_ coalesces when the original value is `null` or `undefined`, it is much safer than relying upon logical OR operator chaining `||`; which coalesces on any _falsy_ value:
+
+```ts
+const emptyString = '';
+
+const nullish1 = emptyString ?? 'unsafe';
+const logical1 = emptyString || 'unsafe';
+
+// nullish1 === ''
+// logical1 === 'unsafe'
+
+declare const nullString: string | null;
+
+const nullish2 = nullString ?? 'safe';
+const logical2 = nullString || 'safe';
+
+// nullish2 === 'safe'
+// logical2 === 'safe'
+```
+
+## Rule Details
+
+This rule aims enforce the usage of the safer operator.
+
+## Options
+
+```ts
+type Options = [
+  {
+    ignoreConditionalTests?: boolean;
+    ignoreMixedLogicalExpressions?: boolean;
+  },
+];
+
+const defaultOptions = [
+  {
+    ignoreConditionalTests: true,
+    ignoreMixedLogicalExpressions: true,
+  },
+];
+```
+
+### `ignoreConditionalTests`
+
+Setting this option to `true` (the default) will cause the rule to ignore any cases that are located within a conditional test.
+
+Generally expressions within conditional tests intentionally use the falsy fallthrough behavior of the logical or operator, meaning that fixing the operator to the nullish coalesce operator could cause bugs.
+
+If you're looking to enforce stricter conditional tests, you should consider using the `strict-boolean-expressions` rule.
+
+Incorrect code for `ignoreConditionalTests: false`, and correct code for `ignoreConditionalTests: true`:
+
+```ts
+declare const a: string | null;
+declare const b: string | null;
+
+if (a || b) {
+}
+while (a || b) {}
+do {} while (a || b);
+for (let i = 0; a || b; i += 1) {}
+a || b ? true : false;
+```
+
+Correct code for `ignoreConditionalTests: false`:
+
+```ts
+declare const a: string | null;
+declare const b: string | null;
+
+if (a ?? b) {
+}
+while (a ?? b) {}
+do {} while (a ?? b);
+for (let i = 0; a ?? b; i += 1) {}
+a ?? b ? true : false;
+```
+
+### `ignoreMixedLogicalExpressions`
+
+Setting this option to `true` (the default) will cause the rule to ignore any logical or expressions that are part of a mixed logical expression (with `&&`).
+
+Generally expressions within mixed logical expressions intentionally use the falsy fallthrough behavior of the logical or operator, meaning that fixing the operator to the nullish coalesce operator could cause bugs.
+
+If you're looking to enforce stricter conditional tests, you should consider using the `strict-boolean-expressions` rule.
+
+Incorrect code for `ignoreMixedLogicalExpressions: false`, and correct code for `ignoreMixedLogicalExpressions: true`:
+
+```ts
+declare const a: string | null;
+declare const b: string | null;
+declare const c: string | null;
+declare const d: string | null;
+
+a || (b && c);
+(a && b) || c || d;
+a || (b && c) || d;
+a || (b && c && d);
+```
+
+Correct code for `ignoreMixedLogicalExpressions: false`:
+
+```ts
+declare const a: string | null;
+declare const b: string | null;
+declare const c: string | null;
+declare const d: string | null;
+
+a ?? (b && c);
+(a && b) ?? c ?? d;
+a ?? (b && c) ?? d;
+a ?? (b && c && d);
+```
+
+**_NOTE:_** Errors for this specific case will be presented as suggestions (see below), instead of fixes. This is because it is not always safe to automatically convert `||` to `??` within a mixed logical expression, as we cannot tell the intended precedence of the operator. Note that by design, `??` requires parentheses when used with `&&` or `||` in the same expression.
+
+## When Not To Use It
+
+If you are not using TypeScript 3.7 (or greater), then you will not be able to use this rule, as the operator is not supported.
+
+## Further Reading
+
+- [TypeScript 3.7 Release Notes](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html)
+- [Nullish Coalescing Operator Proposal](https://github.com/tc39/proposal-nullish-coalescing/)
+
+## Attributes
+
+- [ ] ✅ Recommended
+- [ ] 🔧 Fixable
+- [x] 💭 Requires type information

package/node_modules/@typescript-eslint/eslint-plugin/docs/rules/prefer-optional-chain.md

@@ -0,0 +1,88 @@
+# Prefer using concise optional chain expressions instead of chained logical ands (`prefer-optional-chain`)
+
+TypeScript 3.7 added support for the optional chain operator.
+This operator allows you to safely access properties and methods on objects when they are potentially `null` or `undefined`.
+
+```ts
+type T = {
+  a?: {
+    b?: {
+      c: string;
+      method?: () => void;
+    };
+  };
+};
+
+function myFunc(foo: T | null) {
+  return foo?.a?.b?.c;
+}
+// is roughly equivalent to
+function myFunc(foo: T | null) {
+  return foo && foo.a && foo.a.b && foo.a.b.c;
+}
+
+function myFunc(foo: T | null) {
+  return foo?.['a']?.b?.c;
+}
+// is roughly equivalent to
+function myFunc(foo: T | null) {
+  return foo && foo['a'] && foo['a'].b && foo['a'].b.c;
+}
+
+function myFunc(foo: T | null) {
+  return foo?.a?.b?.method?.();
+}
+// is roughly equivalent to
+function myFunc(foo: T | null) {
+  return foo && foo.a && foo.a.b && foo.a.b.method && foo.a.b.method();
+}
+```
+
+Because the optional chain operator _only_ chains when the property value is `null` or `undefined`, it is much safer than relying upon logical AND operator chaining `&&`; which chains on any _truthy_ value.
+
+## Rule Details
+
+This rule aims enforce the usage of the safer operator.
+
+Examples of **incorrect** code for this rule:
+
+```ts
+foo && foo.a && foo.a.b && foo.a.b.c;
+foo && foo['a'] && foo['a'].b && foo['a'].b.c;
+foo && foo.a && foo.a.b && foo.a.b.method && foo.a.b.method();
+
+// this rule also supports converting chained strict nullish checks:
+foo &&
+  foo.a != null &&
+  foo.a.b !== null &&
+  foo.a.b.c != undefined &&
+  foo.a.b.c.d !== undefined &&
+  foo.a.b.c.d.e;
+```
+
+Examples of **correct** code for this rule:
+
+```ts
+foo?.a?.b?.c;
+foo?.['a']?.b?.c;
+foo?.a?.b?.method?.();
+
+foo?.a?.b?.c?.d?.e;
+```
+
+**Note:** there are a few edge cases where this rule will false positive. Use your best judgement when evaluating reported errors.
+
+## When Not To Use It
+
+If you are not using TypeScript 3.7 (or greater), then you will not be able to use this rule, as the operator is not supported.
+
+## Further Reading
+
+- [TypeScript 3.7 Release Notes](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html)
+- [Optional Chaining Proposal](https://github.com/tc39/proposal-optional-chaining/)
+
+## Attributes
+
+- [ ] ✅ Recommended
+- [ ] 🔧 Fixable
+- [ ] 💭 Requires type information