@alexlit/lint-kit 111.0.0 → 112.0.0

package/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-shadow.mdx

@@ -0,0 +1,108 @@
+---
+description: 'Disallow variable declarations from shadowing variables declared in the outer scope.'
+---
+
+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/no-shadow** for documentation.
+
+This rule extends the base [`eslint/no-shadow`](https://eslint.org/docs/rules/no-shadow) rule.
+It adds support for TypeScript's `this` parameters and global augmentation, and adds options for TypeScript features.
+
+## Options
+
+This rule adds the following options:
+
+```ts
+interface Options extends BaseNoShadowOptions {
+  ignoreTypeValueShadow?: boolean;
+  ignoreFunctionTypeParameterNameValueShadow?: boolean;
+}
+
+const defaultOptions: Options = {
+  ...baseNoShadowDefaultOptions,
+  ignoreTypeValueShadow: true,
+  ignoreFunctionTypeParameterNameValueShadow: true,
+};
+```
+
+### `ignoreTypeValueShadow`
+
+When set to `true`, the rule will ignore the case when you name a type the same as a variable. This is generally safe because you cannot use variables in type locations without a `typeof` operator, so there's little risk of confusion.
+
+Examples of **correct** code with `{ ignoreTypeValueShadow: true }`:
+
+```ts option='{ "ignoreTypeValueShadow": true }' showPlaygroundButton
+type Foo = number;
+interface Bar {
+  prop: number;
+}
+
+function f() {
+  const Foo = 1;
+  const Bar = 'test';
+}
+```
+
+:::note
+
+_Shadowing_ specifically refers to two identical identifiers that are in different, nested scopes. This is different from _redeclaration_, which is when two identical identifiers are in the same scope. Redeclaration is covered by the [`no-redeclare`](./no-redeclare.mdx) rule instead.
+
+:::
+
+### `ignoreFunctionTypeParameterNameValueShadow`
+
+When set to `true`, the rule will ignore the case when you name a parameter in a function type the same as a variable.
+
+Each of a function type's arguments creates a value variable within the scope of the function type. This is done so that you can reference the type later using the `typeof` operator:
+
+```ts
+type Func = (test: string) => typeof test;
+
+declare const fn: Func;
+const result = fn('str'); // typeof result === string
+```
+
+This means that function type arguments shadow value variable names in parent scopes:
+
+```ts
+let test = 1;
+type TestType = typeof test; // === number
+type Func = (test: string) => typeof test; // this "test" references the argument, not the variable
+
+declare const fn: Func;
+const result = fn('str'); // typeof result === string
+```
+
+If you do not use the `typeof` operator in a function type return type position, you can safely turn this option on.
+
+Examples of **correct** code with `{ ignoreFunctionTypeParameterNameValueShadow: true }`:
+
+```ts option='{ "ignoreFunctionTypeParameterNameValueShadow": true }' showPlaygroundButton
+const test = 1;
+type Func = (test: string) => typeof test;
+```
+
+## FAQ
+
+### Why does the rule report on enum members that share the same name as a variable in a parent scope?
+
+Reporting on this case isn't a bug - it is completely intentional and correct reporting! The rule reports due to a relatively unknown feature of enums - enum members create a variable within the enum scope so that they can be referenced within the enum without a qualifier.
+
+To illustrate this with an example:
+
+```ts
+const A = 2;
+enum Test {
+  A = 1,
+  B = A,
+}
+
+console.log(Test.B);
+// what should be logged?
+```
+
+Naively looking at the above code, it might look like the log should output `2`, because the outer variable `A`'s value is `2` - however, the code instead outputs `1`, which is the value of `Test.A`. This is because the unqualified code `B = A` is equivalent to the fully-qualified code `B = Test.A`. Due to this behavior, the enum member has **shadowed** the outer variable declaration.

package/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-this-alias.mdx

@@ -0,0 +1,120 @@
+---
+description: 'Disallow aliasing `this`.'
+---
+
+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/no-this-alias** for documentation.
+
+Assigning a variable to `this` instead of properly using arrow lambdas may be a symptom of pre-ES6 practices
+or not managing scope well.
+
+## Examples
+
+<Tabs>
+<TabItem value="❌ Incorrect">
+
+```ts
+const self = this;
+
+setTimeout(function () {
+  self.doWork();
+});
+```
+
+</TabItem>
+<TabItem value="✅ Correct">
+
+```ts
+setTimeout(() => {
+  this.doWork();
+});
+```
+
+</TabItem>
+</Tabs>
+
+## Options
+
+### `allowDestructuring`
+
+It can sometimes be useful to destructure properties from a class instance, such as retrieving multiple properties from the instance in one of its methods.
+`allowDestructuring` allows those destructures and is `true` by default.
+You can explicitly disallow them by setting `allowDestructuring` to `false`.
+
+Examples of code for the `{ "allowDestructuring": false }` option:
+
+<Tabs>
+<TabItem value="❌ Incorrect">
+
+```ts option='{ "allowDestructuring": false }'
+class ComponentLike {
+  props: unknown;
+  state: unknown;
+
+  render() {
+    const { props, state } = this;
+
+    console.log(props);
+    console.log(state);
+  }
+}
+```
+
+</TabItem>
+<TabItem value="✅ Correct">
+
+```ts option='{ "allowDestructuring": false }'
+class ComponentLike {
+  props: unknown;
+  state: unknown;
+
+  render() {
+    console.log(this.props);
+    console.log(this.state);
+  }
+}
+```
+
+</TabItem>
+</Tabs>
+
+### `allowedNames`
+
+`no-this-alias` can alternately be used to allow only a specific list of names as `this` aliases.
+We recommend against this except as a transitory step towards fixing all rule violations.
+
+Examples of code for the `{ "allowedNames": ["self"] }` option:
+
+<Tabs>
+<TabItem value="❌ Incorrect">
+
+```ts option='{ "allowedNames": ["self"] }'
+class Example {
+  method() {
+    const that = this;
+  }
+}
+```
+
+</TabItem>
+<TabItem value="✅ Correct">
+
+```ts option='{ "allowedNames": ["self"] }'
+class Example {
+  method() {
+    const self = this;
+  }
+}
+```
+
+</TabItem>
+</Tabs>
+
+## When Not To Use It
+
+If your project is structured in a way that it needs to assign `this` to variables, this rule is likely not for you.
+If only a subset of your project assigns `this` to variables then you might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) for those specific situations instead of completely disabling this rule.

package/packages/config-eslint/node_modules/@typescript-eslint/eslint-plugin/docs/rules/no-throw-literal.mdx

@@ -0,0 +1,115 @@
+---
+description: 'Disallow throwing literals as exceptions.'
+---
+
+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/no-throw-literal** for documentation.
+
+It is considered good practice to only `throw` the `Error` object itself or an object using the `Error` object as base objects for user-defined exceptions.
+The fundamental benefit of `Error` objects is that they automatically keep track of where they were built and originated.
+
+This rule restricts what can be thrown as an exception. When it was first created, it only prevented literals from being thrown (hence the name), but it has now been expanded to only allow expressions which have a possibility of being an `Error` object. With the `allowThrowingAny` and `allowThrowingUnknown`, it can be configured to only allow throwing values which are guaranteed to be an instance of `Error`.
+
+## Examples
+
+This rule is aimed at maintaining consistency when throwing exception by disallowing to throw literals and other expressions which cannot possibly be an `Error` object.
+
+<Tabs>
+<TabItem value="❌ Incorrect">
+
+```ts
+throw 'error';
+
+throw 0;
+
+throw undefined;
+
+throw null;
+
+const err = new Error();
+throw 'an ' + err;
+
+const err = new Error();
+throw `${err}`;
+
+const err = '';
+throw err;
+
+function err() {
+  return '';
+}
+throw err();
+
+const foo = {
+  bar: '',
+};
+throw foo.bar;
+```
+
+</TabItem>
+<TabItem value="✅ Correct">
+
+```ts
+throw new Error();
+
+throw new Error('error');
+
+const e = new Error('error');
+throw e;
+
+try {
+  throw new Error('error');
+} catch (e) {
+  throw e;
+}
+
+const err = new Error();
+throw err;
+
+function err() {
+  return new Error();
+}
+throw err();
+
+const foo = {
+  bar: new Error(),
+};
+throw foo.bar;
+
+class CustomError extends Error {
+  // ...
+}
+throw new CustomError();
+```
+
+</TabItem>
+</Tabs>
+
+## Options
+
+This rule adds the following options:
+
+```ts
+interface Options {
+  /**
+   * Whether to always allow throwing values typed as `any`.
+   */
+  allowThrowingAny?: boolean;
+
+  /**
+   * Whether to always allow throwing values typed as `unknown`.
+   */
+  allowThrowingUnknown?: boolean;
+}
+
+const defaultOptions: Options = {
+  allowThrowingAny: false,
+  allowThrowingUnknown: false,
+};
+```
+
+{/* Intentionally Omitted: When Not To Use It */}