@typescript-eslint/eslint-plugin 6.13.2-alpha.5 → 6.13.2

package/docs/rules/explicit-function-return-type.md

@@ -317,8 +317,7 @@ var bar = (function () {
 
 ## 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.
+If you don't find the added cost of explicitly writing function return types to be worth the visual clarity, or your project is not large enough for it to be a factor in type checking performance, then you will not need this rule.
 
 ## Further Reading
 

package/docs/rules/explicit-member-accessibility.md

@@ -333,7 +333,11 @@ class Animal {
 
 ## When Not To Use It
 
-If you think defaulting to public is a good default, then you should consider using the `no-public` setting. If you want to mix implicit and explicit public members then disable this rule.
+If you think defaulting to public is a good default, then you should consider using the `no-public` setting.
+If you want to mix implicit and explicit public members then you can disable this rule.
+
+However, keep in mind that inconsistent style can harm readability in a project.
+We recommend picking a single option for this rule that works best for your project.
 
 ## Further Reading
 

package/docs/rules/explicit-module-boundary-types.md

@@ -243,8 +243,12 @@ export const foo: FooType = bar => {};
 
 ## When Not To Use It
 
-If you wish to make sure all functions have explicit return types, as opposed to only the module boundaries, you can use [explicit-function-return-type](./explicit-function-return-type.md)
+If your project is not used by downstream consumers that are sensitive to API types, you can disable this rule.
 
 ## Further Reading
 
 - TypeScript [Functions](https://www.typescriptlang.org/docs/handbook/functions.html#function-types)
+
+## Related To
+
+- [explicit-function-return-type](./explicit-function-return-type.md)

package/docs/rules/member-delimiter-style.md

@@ -158,4 +158,7 @@ type FooBar = { name: string; greet(): string }
 
 ## When Not To Use It
 
-If you don't care about enforcing a consistent member delimiter in interfaces and type literals, then you will not need this rule.
+If you specifically want to use both member delimiter kinds for stylistic reasons, or don't wish to enforce one style over the other, you can avoid this rule.
+
+However, keep in mind that inconsistent style can harm readability in a project.
+We recommend picking a single option for this rule that works best for your project.

package/docs/rules/method-signature-style.md

@@ -108,3 +108,6 @@ type T2 = {
 ## When Not To Use It
 
 If you don't want to enforce a particular style for object/interface function types, and/or if you don't use `strictFunctionTypes`, then you don't need this rule.
+
+However, keep in mind that inconsistent style can harm readability in a project.
+We recommend picking a single option for this rule that works best for your project.

package/docs/rules/naming-convention.md

@@ -711,4 +711,11 @@ You can use the `destructured` modifier to match these names, and explicitly set
 
 ## When Not To Use It
 
-If you do not want to enforce naming conventions for anything.
+This rule can be very strict.
+If you don't have strong needs for enforcing naming conventions, we recommend using it only to flag very egregious violations of your naming standards.
+Consider documenting your naming conventions and enforcing them in code review if you have processes like that.
+
+If you do not want to enforce naming conventions for anything, you can disable this rule.
+
+However, keep in mind that inconsistent style can harm readability in a project.
+We recommend that if you care about naming conventions, pick a single option for this rule that works best for your project.

package/docs/rules/no-base-to-string.md

@@ -76,7 +76,7 @@ let text = `${value}`;
 
 ## When Not To Use It
 
-If you don't mind `"[object Object]"` in your strings, then you will not need this rule.
+If you don't mind a risk of `"[object Object]"` or incorrect type coercions in your values, then you will not need this rule.
 
 ## Related To
 

package/docs/rules/no-confusing-void-expression.md

@@ -113,4 +113,4 @@ console.log(void alert('Hello, world!'));
 
 The return type of a function can be inspected by going to its definition or hovering over it in an IDE.
 If you don't care about being explicit about the void type in actual code then don't use this rule.
-Also, if you prefer concise coding style then also don't use it.
+Also, if you strongly prefer a concise coding style more strongly than any fear of `void`-related bugs then you can avoid this rule.

package/docs/rules/no-duplicate-enum-values.md

@@ -48,3 +48,11 @@ enum E {
   B = 'B',
 }
 ```
+
+## When Not To Use It
+
+It can sometimes be useful to include duplicate enum members for very specific use cases.
+For example, when renaming an enum member, it can sometimes be useful to keep the old name until a scheduled major breaking change.
+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.
+
+In general, if your project intentionally duplicates enum member values, you can avoid this rule.

package/docs/rules/no-duplicate-type-constituents.md

@@ -57,3 +57,10 @@ When set to true, duplicate checks on intersection type constituents are ignored
 ### `ignoreUnions`
 
 When set to true, duplicate checks on union type constituents are ignored.
+
+## When Not To Use It
+
+It can sometimes be useful for the sake of documentation to include aliases for the same type.
+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.
+
+> In some of those cases, [branded types](https://basarat.gitbook.io/typescript/main-1/nominaltyping#using-interfaces) might be a type-safe way to represent the underlying data types.

package/docs/rules/no-dynamic-delete.md

@@ -47,7 +47,7 @@ delete container['-Infinity'];
 ## When Not To Use It
 
 When you know your keys are safe to delete, this rule can be unnecessary.
-Some environments such as older browsers might not support `Map` and `Set`.
+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.
 
 Do not consider this rule as performance advice before profiling your code's bottlenecks.
 Even repeated minor performance slowdowns likely do not significantly affect your application's general perceived speed.

package/docs/rules/no-empty-function.md

@@ -84,3 +84,12 @@ class Foo extends Base {
   protected override greet(): void {}
 }
 ```
+
+## When Not To Use It
+
+If you are working with external APIs that require functions even if they do nothing, then you may want to avoid this rule.
+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.
+
+Test code often violates this rule as well.
+If your testing setup doesn't support "mock" or "spy" functions such as [`jest.fn()`](https://jestjs.io/docs/mock-functions), [`sinon.spy()`](https://sinonjs.org/releases/latest/spies), or [`vi.fn()`](https://vitest.dev/guide/mocking.html), you may wish to disable this rule in test files.
+Again, if those cases aren't extremely common, 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 in test files.

package/docs/rules/no-explicit-any.md

@@ -138,6 +138,8 @@ Most commonly:
 - If an external package doesn't yet have typings and you want to use `any` pending adding a `.d.ts` for it
 - You're working with particularly complex or nuanced code that can't yet be represented in the TypeScript type system
 
+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.
+
 ## Related To
 
 - [`no-unsafe-argument`](./no-unsafe-argument.md)
@@ -148,5 +150,7 @@ Most commonly:
 
 ## Further Reading
 
+- TypeScript [`any` type](https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#any)
+- TypeScript's [`unknown` type](https://www.typescriptlang.org/docs/handbook/2/functions.html#unknown)
 - TypeScript [`any` type documentation](https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#any)
 - TypeScript [`unknown` type release notes](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-0.html#new-unknown-top-type)

package/docs/rules/no-extra-non-null-assertion.md

@@ -50,3 +50,5 @@ function foo(bar?: { n: number }) {
   return bar?.n;
 }
 ```
+
+<!-- Intentionally Omitted: When Not To Use It -->

package/docs/rules/no-extraneous-class.md

@@ -291,4 +291,5 @@ class Constants {
 
 ## When Not To Use It
 
-You can disable this rule if you are unable -or unwilling- to switch off using classes as namespaces.
+If your project was set up before modern class and namespace practices, and you don't have the time to switch over, you might not be practically able to use this rule.
+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/docs/rules/no-floating-promises.md

@@ -99,7 +99,9 @@ await(async function () {
 
 ## When Not To Use It
 
-If you do not use Promise-like values in your codebase, or want to allow them to remain unhandled.
+This rule can be difficult to enable on large existing projects that set up many floating Promises.
+Alternately, if you're not worried about crashes from floating or misused Promises -such as if you have global unhandled Promise handlers registered- then in some cases it may be safe to not use this rule.
+You might consider using `void`s and/or [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.
 
 ## Related To
 

package/docs/rules/no-for-in-array.md

@@ -53,4 +53,5 @@ for (const [i, value] of array.entries()) {
 
 ## When Not To Use It
 
-If you want to iterate through a loop using the indices in an array as strings, you can turn off this rule.
+If your project is a rare one that intentionally loops over string indices of arrays, you can turn off this rule.
+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/docs/rules/no-implied-eval.md

@@ -98,4 +98,5 @@ setTimeout(Foo.fn, 100);
 
 ## When Not To Use It
 
-If you want to allow `new Function()` or `setTimeout()`, `setInterval()`, `setImmediate()` and `execScript()` with string arguments, then you can safely disable this rule.
+If your project is a rare one that needs to allow `new Function()` or `setTimeout()`, `setInterval()`, `setImmediate()` and `execScript()` with string arguments, then you can disable this rule.
+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/docs/rules/no-import-type-side-effects.md

@@ -65,8 +65,7 @@ import T, { type U } from 'mod';
 
 ## When Not To Use It
 
-- If you want to leave behind side effect imports, then you shouldn't use this rule.
-- If you're not using TypeScript 5.0's `verbatimModuleSyntax` option, then you don't need this rule.
+If you're not using TypeScript 5.0's `verbatimModuleSyntax` option and your project is built with a bundler that manages import side effects for you, this rule may not be as useful for you.
 
 ## Related To
 

package/docs/rules/no-inferrable-types.md

@@ -96,8 +96,8 @@ class Foo {
 
 ## When Not To Use It
 
-If you do not want to enforce inferred types.
+If you strongly prefer to have explicit types regardless of whether they can be inferred, this rule may not be for you.
 
 ## Further Reading
 
-TypeScript [Inference](https://www.typescriptlang.org/docs/handbook/type-inference.html)
+- [TpeScript Inference](https://www.typescriptlang.org/docs/handbook/type-inference.html)

package/docs/rules/no-invalid-void-type.md

@@ -109,5 +109,4 @@ class Example {
 
 ## When Not To Use It
 
-If you don't care about if `void` is used with other types,
-or in invalid places, then you don't need this rule.
+If you don't care about if `void` is used with other types, or in invalid places, then you don't need this rule.

package/docs/rules/no-magic-numbers.md

@@ -111,3 +111,9 @@ Examples of **correct** code for the `{ "ignoreTypeIndexes": true }` option:
 type Foo = Bar[0];
 type Baz = Parameters<Foo>[2];
 ```
+
+## When Not To Use It
+
+If your project frequently deals with constant numbers and you don't wish to take up extra space to declare them, this rule might not be for you.
+We recommend at least using descriptive comments and/or names to describe constants.
+You might consider using [ESLint disable comments](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1) instead of completely disabling this rule.

package/docs/rules/no-meaningless-void-operator.md

@@ -45,3 +45,7 @@ void bar(); // discarding a number
 ## Options
 
 `checkNever: true` will suggest removing `void` when the argument has type `never`.
+
+## When Not To Use It
+
+If you don't mind extra `void`s in your project, you can avoid this rule.

package/docs/rules/no-misused-new.md

@@ -43,4 +43,5 @@ interface I {
 
 ## When Not To Use It
 
-If you intentionally want a class with a `new` method, and you're confident nobody working in your code will mistake it with a constructor.
+If you intentionally want a class with a `new` method, and you're confident nobody working in your code will mistake it with a constructor, you might not want this rule.
+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/docs/rules/no-misused-promises.md

@@ -233,8 +233,9 @@ return { foo: 42, ...(await getData2()) };
 
 ## When Not To Use It
 
-If you do not use Promises in your codebase or are not concerned with possible
-misuses of them outside of what the TypeScript compiler will check.
+This rule can be difficult to enable on large existing projects that set up many misused Promises.
+Alternately, if you're not worried about crashes from floating or misused Promises -such as if you have global unhandled Promise handlers registered- then in some cases it may be safe to not use this rule.
+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.
 
 ## Further Reading
 

package/docs/rules/no-namespace.md

@@ -120,7 +120,9 @@ declare module 'foo' {}
 
 ## When Not To Use It
 
-If you are using the ES2015 module syntax, then you will not need this rule.
+If your project was architected before modern modules and namespaces, it may be difficult to migrate off of namespaces.
+In that case you may not be able to use this rule for parts of your project.
+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.
 
 ## Further Reading
 

package/docs/rules/no-non-null-asserted-nullish-coalescing.md

@@ -43,6 +43,11 @@ let x: string;
 x! ?? '';
 ```
 
+## When Not To Use It
+
+If your project's types don't yet fully describe whether certain values may be nullable, such as if you're transitioning to `strictNullChecks`, this rule might create many false reports.
+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.
+
 ## Further Reading
 
 - [TypeScript 3.7 Release Notes](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html)

package/docs/rules/no-non-null-asserted-optional-chain.md

@@ -29,6 +29,11 @@ foo?.bar;
 foo?.bar();
 ```
 
+## When Not To Use It
+
+If your project's types don't yet fully describe whether certain values may be nullable, such as if you're transitioning to `strictNullChecks`, this rule might create many false reports.
+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.
+
 ## Further Reading
 
 - [TypeScript 3.7 Release Notes](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html)

package/docs/rules/no-non-null-assertion.md

@@ -38,5 +38,5 @@ const includesBaz = example.property?.includes('baz') ?? false;
 
 ## When Not To Use It
 
-If your project does not use the `strictNullChecks` compiler option, this rule is likely useless to you.
-If your code is often wildly incorrect with respect to strict null-checking, your code may not yet be ready for this rule.
+If your project's types don't yet fully describe whether certain values may be nullable, such as if you're transitioning to `strictNullChecks`, this rule might create many false reports.
+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/docs/rules/no-redundant-type-constituents.md

@@ -70,6 +70,20 @@ type IntersectionStringLiteral = 'foo';
 
 This rule plays it safe and only works with bottom types, top types, and comparing literal types to primitive types.
 
+## When Not To Use It
+
+Some projects choose to occasionally intentionally include a redundant type constituent for documentation purposes.
+For example, the following code includes `string` in a union even though the `unknown` makes it redundant:
+
+```ts
+/**
+ * Normally a string name, but sometimes arbitrary unknown data.
+ */
+type NameOrOther = string | unknown;
+```
+
+If you strongly feel a preference for these unnecessary type constituents, this rule might not be for you.
+
 ## Further Reading
 
 - [Union Types](https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#union-types)

package/docs/rules/no-require-imports.md

@@ -30,7 +30,8 @@ import * as lib3 from 'lib3';
 
 ## When Not To Use It
 
-If you don't care about using newer module syntax, then you will not need this rule.
+If your project frequently uses older CommonJS `require`s, then this rule might not be applicable to you.
+If only a subset of your project uses `require`s 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.
 
 ## Related To
 

package/docs/rules/no-this-alias.md

@@ -35,4 +35,5 @@ setTimeout(() => {
 
 ## When Not To Use It
 
-If you need to assign `this` to variables, you shouldn’t use this rule.
+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/docs/rules/no-throw-literal.md

@@ -109,3 +109,5 @@ const defaultOptions: Options = {
   allowThrowingUnknown: false,
 };
 ```
+
+<!-- Intentionally omitted: When Not To Use It -->

package/docs/rules/no-type-alias.md

@@ -606,10 +606,7 @@ type Foo = Partial<Bar>;
 type Foo = Omit<Bar, 'a' | 'b'>;
 ```
 
-## When Not To Use It
-
-When you can't express some shape with an interface or you need to use a union, tuple type,
-callback, etc. that would cause the code to be unreadable or impractical.
+<!-- Intentionally Omitted: When Not To Use It -->
 
 ## Further Reading
 

package/docs/rules/no-unnecessary-boolean-literal-compare.md

@@ -126,7 +126,7 @@ if (!(someNullCondition ?? true)) {
 | `!(nullableBooleanVar === false)` | `nullableBooleanVar ?? true`    | Only checked/fixed if the `allowComparingNullableBooleansToFalse` option is `false` |
 | `!(nullableBooleanVar !== false)` | `!(nullableBooleanVar ?? true)` | Only checked/fixed if the `allowComparingNullableBooleansToFalse` option is `false` |
 
-## Not To Use It
+## When Not To Use It
 
 Do not use this rule when `strictNullChecks` is disabled.
 ESLint is not able to distinguish between `false` and `undefined` or `null` values.

package/docs/rules/no-unnecessary-condition.md

@@ -95,7 +95,8 @@ If for some reason you cannot turn on `strictNullChecks`, but still want to use
 
 ## When Not To Use It
 
-The main downside to using this rule is the need for type information.
+If your project is not accurately typed, such as if it's in the process of being converted to TypeScript or is susceptible to [trade-offs in control flow analysis](https://github.com/Microsoft/TypeScript/issues/9998), it may be difficult to enable this rule for particularly non-type-safe areas of code.
+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.
 
 This rule has a known edge case of triggering on conditions that were modified within function calls (as side effects).
 It is due to limitations of TypeScript's type narrowing.

package/docs/rules/no-unnecessary-qualifier.md

@@ -48,4 +48,4 @@ namespace A {
 
 ## When Not To Use It
 
-If you don't care about having unneeded enum or namespace qualifiers, then you don't need to use this rule.
+If you explicitly prefer to use fully qualified names, such as for explicitness, then you don't need to use this rule.

package/docs/rules/no-unnecessary-type-arguments.md

@@ -71,3 +71,7 @@ class D extends C<string> {}
 interface I<T = number> {}
 class Impl implements I<string> {}
 ```
+
+## When Not To Use It
+
+If you prefer explicitly specifying type parameters even when they are equal to the default, you can skip this rule.

package/docs/rules/no-unsafe-argument.md

@@ -78,6 +78,16 @@ declare function foo(arg1: unknown, arg2: Set<unknown>, arg3: unknown[]): void;
 foo(1 as any, new Set<any>(), [] as any[]);
 ```
 
+## When Not To Use It
+
+If your codebase has many existing `any`s or areas of unsafe code, it may be difficult to enable this rule.
+It may be easier to skip the `no-unsafe-*` rules pending increasing type safety in unsafe areas of your project.
+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.
+
 ## Related To
 
 - [`no-explicit-any`](./no-explicit-any.md)
+- [`no-unsafe-assignment`](./no-unsafe-assignment.md)
+- [`no-unsafe-call`](./no-unsafe-call.md)
+- [`no-unsafe-member-access`](./no-unsafe-member-access.md)
+- [`no-unsafe-return`](./no-unsafe-return.md)

package/docs/rules/no-unsafe-assignment.md

@@ -81,6 +81,16 @@ const x: unknown[] = y as any[];
 const x: Set<unknown> = y as Set<any>;
 ```
 
+## When Not To Use It
+
+If your codebase has many existing `any`s or areas of unsafe code, it may be difficult to enable this rule.
+It may be easier to skip the `no-unsafe-*` rules pending increasing type safety in unsafe areas of your project.
+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.
+
 ## Related To
 
 - [`no-explicit-any`](./no-explicit-any.md)
+- [`no-unsafe-argument`](./no-unsafe-argument.md)
+- [`no-unsafe-call`](./no-unsafe-call.md)
+- [`no-unsafe-member-access`](./no-unsafe-member-access.md)
+- [`no-unsafe-return`](./no-unsafe-return.md)

package/docs/rules/no-unsafe-call.md

@@ -53,6 +53,16 @@ new Map();
 String.raw`foo`;
 ```
 
+## When Not To Use It
+
+If your codebase has many existing `any`s or areas of unsafe code, it may be difficult to enable this rule.
+It may be easier to skip the `no-unsafe-*` rules pending increasing type safety in unsafe areas of your project.
+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.
+
 ## Related To
 
 - [`no-explicit-any`](./no-explicit-any.md)
+- [`no-unsafe-argument`](./no-unsafe-argument.md)
+- [`no-unsafe-assignment`](./no-unsafe-assignment.md)
+- [`no-unsafe-member-access`](./no-unsafe-member-access.md)
+- [`no-unsafe-return`](./no-unsafe-return.md)

package/docs/rules/no-unsafe-declaration-merging.md

@@ -49,6 +49,11 @@ namespace Qux {}
 function Qux() {}
 ```
 
+## When Not To Use It
+
+If your project intentionally defines classes and interfaces with unsafe declaration merging patterns, this rule might not be for you.
+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.
+
 ## Further Reading
 
 - [Declaration Merging](https://www.typescriptlang.org/docs/handbook/declaration-merging.html)

package/docs/rules/no-unsafe-enum-comparison.md

@@ -77,3 +77,6 @@ vegetable === Vegetable.Asparagus;
 ## When Not To Use It
 
 If you don't mind number and/or literal string constants being compared against enums, you likely don't need this rule.
+
+Separately, in the rare case of relying on an third party enums that are only imported as `type`s, it may be difficult to adhere to this rule.
+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/docs/rules/no-unsafe-member-access.md

@@ -59,6 +59,16 @@ arr[idx];
 arr[idx++];
 ```
 
+## When Not To Use It
+
+If your codebase has many existing `any`s or areas of unsafe code, it may be difficult to enable this rule.
+It may be easier to skip the `no-unsafe-*` rules pending increasing type safety in unsafe areas of your project.
+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.
+
 ## Related To
 
 - [`no-explicit-any`](./no-explicit-any.md)
+- [`no-unsafe-argument`](./no-unsafe-argument.md)
+- [`no-unsafe-assignment`](./no-unsafe-assignment.md)
+- [`no-unsafe-call`](./no-unsafe-call.md)
+- [`no-unsafe-return`](./no-unsafe-return.md)

package/docs/rules/no-unsafe-return.md

@@ -98,6 +98,16 @@ function foo2(): unknown[] {
 }
 ```
 
+## When Not To Use It
+
+If your codebase has many existing `any`s or areas of unsafe code, it may be difficult to enable this rule.
+It may be easier to skip the `no-unsafe-*` rules pending increasing type safety in unsafe areas of your project.
+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.
+
 ## Related To
 
 - [`no-explicit-any`](./no-explicit-any.md)
+- [`no-unsafe-argument`](./no-unsafe-argument.md)
+- [`no-unsafe-assignment`](./no-unsafe-assignment.md)
+- [`no-unsafe-call`](./no-unsafe-call.md)
+- [`no-unsafe-member-access`](./no-unsafe-member-access.md)

package/docs/rules/no-unsafe-unary-minus.md

@@ -48,3 +48,5 @@ declare const d: any;
 declare const e: 1 | 2;
 -e;
 ```
+
+<!-- Intentionally Omitted: When Not To Use It -->

package/docs/rules/no-useless-empty-export.md

@@ -41,3 +41,7 @@ export const value = 'Hello, world!';
 ```ts
 import 'some-other-module';
 ```
+
+## When Not To Use It
+
+If you don't mind an empty `export {}` at the bottom of files, you likely don't need this rule.

package/docs/rules/no-var-requires.md

@@ -30,7 +30,8 @@ import foo from 'foo';
 
 ## When Not To Use It
 
-If you don't care about using newer module syntax, then you will not need this rule.
+If your project frequently uses older CommonJS `require`s, then this rule might not be applicable to you.
+If only a subset of your project uses `require`s 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.
 
 ## Related To
 

package/docs/rules/non-nullable-type-assertion-style.md

@@ -38,4 +38,4 @@ const alsoDefinitely = maybe!;
 
 ## When Not To Use It
 
-If you don't mind having unnecessarily verbose type casts, you can avoid this rule.
+If you don't mind having unnecessarily verbose type assertions, you can avoid this rule.

package/docs/rules/parameter-properties.md

@@ -482,4 +482,7 @@ class Foo {
 
 ## When Not To Use It
 
-If you don't care about the using parameter properties in constructors, then you will not need this rule.
+If you don't care about which style of parameter properties in constructors is used in your classes, then you will not need this rule.
+
+However, keep in mind that inconsistent style can harm readability in a project.
+We recommend picking a single option for this rule that works best for your project.

package/docs/rules/prefer-as-const.md

@@ -41,4 +41,7 @@ let foo = { bar: 'baz' };
 
 ## When Not To Use It
 
-If you are using TypeScript < 3.4
+If you don't care about which style of literals assertions is used in your code, then you will not need this rule.
+
+However, keep in mind that inconsistent style can harm readability in a project.
+We recommend picking a single option for this rule that works best for your project.

package/docs/rules/prefer-for-of.md

@@ -41,6 +41,4 @@ for (let i = 0; i < array.length; 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.
+<!-- Intentionally Omitted: When Not To Use It -->