@typescript-eslint/eslint-plugin 8.0.0-alpha.3 → 8.0.0-alpha.31

package/docs/rules/no-duplicate-imports.mdx

@@ -1,6 +1,6 @@
 :::danger Deprecated
 
-This rule has been deprecated in favour of the [`import/no-duplicates`](https://github.com/import-js/eslint-plugin-import/blob/HEAD/docs/rules/no-duplicates.mdx) rule.
+This rule has been deprecated in favour of the [`import/no-duplicates`](https://github.com/import-js/eslint-plugin-import/blob/HEAD/docs/rules/no-duplicates.md) rule.
 
 :::
 

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

@@ -11,9 +11,13 @@ import TabItem from '@theme/TabItem';
 
 Deleting dynamically computed keys can be dangerous and in some cases not well optimized.
 Using the `delete` operator on keys that aren't runtime constants could be a sign that you're using the wrong data structures.
-Using `Object`s with added and removed keys can cause occasional edge case bugs, such as if a key is named `"hasOwnProperty"`.
+Consider using a `Map` or `Set` if you’re using an object as a key-value collection.
 
-> Consider using a `Map` or `Set` if you’re storing collections of objects.
+Dynamically adding and removing keys from objects can cause occasional edge case bugs. For example, some objects use "hidden properties" (such as `__data`) for private storage, and deleting them can break the object's internal state. Furthermore, [`delete`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/delete) cannot remove inherited properties or non-configurable properties. This makes it interact badly with anything more complicated than a plain object:
+
+- The [`length`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/length) of an array is non-configurable, and deleting it is a runtime error.
+- You can't remove properties on the prototype of an object, such as deleting methods from class instances.
+- Sometimes, `delete` only removes the own property, leaving the inherited property intact. For example, deleting the [`name`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/name) property of a function only removes the own property, but there's also a `Function.prototype.name` property that remains.
 
 ## Examples
 
@@ -21,10 +25,6 @@ Using `Object`s with added and removed keys can cause occasional edge case bugs,
 <TabItem value="❌ Incorrect">
 
 ```ts
-// Can be replaced with the constant equivalents, such as container.aaa
-delete container['aaa'];
-delete container['Infinity'];
-
 // Dynamic, difficult-to-reason-about lookups
 const name = 'name';
 delete container[name];
@@ -44,7 +44,12 @@ delete container.aaa;
 
 // Constants that must be accessed by []
 delete container[7];
-delete container['-Infinity'];
+delete container[-1];
+
+// All strings are allowed, to be compatible with the noPropertyAccessFromIndexSignature
+// TS compiler option
+delete container['aaa'];
+delete container['Infinity'];
 ```
 
 </TabItem>

package/docs/rules/no-empty-interface.mdx

@@ -9,6 +9,12 @@ import TabItem from '@theme/TabItem';
 >
 > See **https://typescript-eslint.io/rules/no-empty-interface** for documentation.
 
+:::danger Deprecated
+
+This rule has been deprecated in favour of the more comprehensive [`@typescript-eslint/no-empty-object-type`](./no-empty-object-type.mdx) rule.
+
+:::
+
 An empty interface in TypeScript does very little: any non-nullable value is assignable to `{}`.
 Using an empty interface is often a sign of programmer error, such as misunderstanding the concept of `{}` or forgetting to fill in fields.
 
@@ -61,3 +67,7 @@ interface Baz extends Foo, Bar {}
 ## When Not To Use It
 
 If you don't care about having empty/meaningless interfaces, then you will not need this rule.
+
+## Related To
+
+- [`no-empty-object-type`](./no-empty-object-type.mdx)

package/docs/rules/no-empty-object-type.mdx

@@ -0,0 +1,145 @@
+---
+description: 'Disallow accidentally using the "empty object" type.'
+---
+
+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-empty-object-type** for documentation.
+
+The `{}`, or "empty object" type in TypeScript is a common source of confusion for developers unfamiliar with TypeScript's structural typing.
+`{}` represents any _non-nullish value_, including literals like `0` and `""`:
+
+```ts
+let anyNonNullishValue: {} = 'Intentionally allowed by TypeScript.';
+```
+
+Often, developers writing `{}` actually mean either:
+
+- `object`: representing any _object_ value
+- `unknown`: representing any value at all, including `null` and `undefined`
+
+In other words, the "empty object" type `{}` really means _"any value that is defined"_.
+That includes arrays, class instances, functions, and primitives such as `string` and `symbol`.
+
+To avoid confusion around the `{}` type allowing any _non-nullish value_, this rule bans usage of the `{}` type.
+That includes interfaces and object type aliases with no fields.
+
+:::tip
+If you do have a use case for an API allowing `{}`, you can always configure the [rule's options](#options), use an [ESLint disable comment](https://eslint.org/docs/latest/use/configure/rules#using-configuration-comments-1), or [disable the rule in your ESLint config](https://eslint.org/docs/latest/use/configure/rules#using-configuration-files-1).
+:::
+
+Note that this rule does not report on:
+
+- `{}` as a type constituent in an intersection type (e.g. types like TypeScript's built-in `type NonNullable<T> = T & {}`), as this can be useful in type system operations.
+- Interfaces that extend from multiple other interfaces.
+
+## Examples
+
+<Tabs>
+<TabItem value="❌ Incorrect">
+
+```ts
+let anyObject: {};
+let anyValue: {};
+
+interface AnyObjectA {}
+interface AnyValueA {}
+
+type AnyObjectB = {};
+type AnyValueB = {};
+```
+
+</TabItem>
+<TabItem value="✅ Correct">
+
+```ts
+let anyObject: object;
+let anyValue: unknown;
+
+type AnyObjectA = object;
+type AnyValueA = unknown;
+
+type AnyObjectB = object;
+type AnyValueB = unknown;
+
+let objectWith: { property: boolean };
+
+interface InterfaceWith {
+  property: boolean;
+}
+
+type TypeWith = { property: boolean };
+```
+
+</TabItem>
+</Tabs>
+
+## Options
+
+By default, this rule flags both interfaces and object types.
+
+### `allowInterfaces`
+
+Whether to allow empty interfaces, as one of:
+
+- `'always'`: to always allow interfaces with no fields
+- `'never'` _(default)_: to never allow interfaces with no fields
+- `'with-single-extends'`: to allow empty interfaces that `extend` from a single base interface
+
+Examples of **correct** code for this rule with `{ allowInterfaces: 'with-single-extends' }`:
+
+```ts option='{ "allowInterfaces": "with-single-extends" }' showPlaygroundButton
+interface Base {
+  value: boolean;
+}
+
+interface Derived extends Base {}
+```
+
+### `allowObjectTypes`
+
+Whether to allow empty object type literals, as one of:
+
+- `'always'`: to always allow object type literals with no fields
+- `'never'` _(default)_: to never allow object type literals with no fields
+
+### `allowWithName`
+
+A stringified regular expression to allow interfaces and object type aliases with the configured name.
+This can be useful if your existing code style includes a pattern of declaring empty types with `{}` instead of `object`.
+
+Examples of code for this rule with `{ allowWithName: 'Props$' }`:
+
+<Tabs>
+<TabItem value="❌ Incorrect">
+
+```ts option='{ "allowWithName": "Props$" }' showPlaygroundButton
+interface InterfaceValue {}
+
+type TypeValue = {};
+```
+
+</TabItem>
+<TabItem value="✅ Correct">
+
+```ts option='{ "allowWithName": "Props$" }' showPlaygroundButton
+interface InterfaceProps {}
+
+type TypeProps = {};
+```
+
+</TabItem>
+</Tabs>
+
+## When Not To Use It
+
+If your code commonly needs to represent the _"any non-nullish value"_ type, this rule may not be for you.
+Projects that extensively use type operations such as conditional types and mapped types oftentimes benefit from disabling this rule.
+
+## Further Reading
+
+- [Enhancement: [ban-types] Split the {} ban into a separate, better-phrased rule](https://github.com/typescript-eslint/typescript-eslint/issues/8700)
+- [The Empty Object Type in TypeScript](https://www.totaltypescript.com/the-empty-object-type-in-typescript)

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

@@ -42,6 +42,8 @@ class HelloWorldLogger {
     console.log('Hello, world!');
   }
 }
+
+abstract class Foo {}
 ```
 
 </TabItem>
@@ -57,6 +59,10 @@ export function isProduction() {
 function logHelloWorld() {
   console.log('Hello, world!');
 }
+
+abstract class Foo {
+  abstract prop: string;
+}
 ```
 
 </TabItem>

package/docs/rules/no-floating-promises.mdx

@@ -17,13 +17,14 @@ Valid ways of handling a Promise-valued statement include:
 
 - `await`ing it
 - `return`ing it
+- `void`ing it
 - Calling its `.then()` with two arguments
 - Calling its `.catch()` with one argument
 
 This rule also reports when an Array containing Promises is created and not properly handled. The main way to resolve this is by using one of the Promise concurrency methods to create a single Promise, then handling that according to the procedure above. These methods include:
 
-- `Promise.all()`,
-- `Promise.allSettled()`,
+- `Promise.all()`
+- `Promise.allSettled()`
 - `Promise.any()`
 - `Promise.race()`
 
@@ -63,6 +64,9 @@ await promise;
 async function returnsPromise() {
   return 'value';
 }
+
+void returnsPromise();
+
 returnsPromise().then(
   () => {},
   () => {},
@@ -82,7 +86,7 @@ await Promise.all([1, 2, 3].map(async x => x + 1));
 
 ### `ignoreVoid`
 
-This allows you to stop the rule reporting promises consumed with void operator.
+This option, which is `true` by default, allows you to stop the rule reporting promises consumed with void operator.
 This can be a good way to explicitly mark a promise as intentionally not awaited.
 
 Examples of **correct** code for this rule with `{ ignoreVoid: true }`:
@@ -100,7 +104,7 @@ With this option set to `true`, and if you are using `no-void`, you should turn
 
 ### `ignoreIIFE`
 
-This allows you to skip checking of async IIFEs (Immediately Invoked function Expressions).
+This allows you to skip checking of async IIFEs (Immediately Invoked Function Expressions).
 
 Examples of **correct** code for this rule with `{ ignoreIIFE: true }`:
 
@@ -115,6 +119,101 @@ await (async function () {
 })();
 ```
 
+### `allowForKnownSafePromises`
+
+This option allows marking specific types as "safe" to be floating. For example, you may need to do this in the case of libraries whose APIs return Promises whose rejections are safely handled by the library.
+
+This option takes an array of type specifiers to consider safe.
+Each item in the array must have one of the following forms:
+
+- A type defined in a file (`{ from: "file", name: "Foo", path: "src/foo-file.ts" }` with `path` being an optional path relative to the project root directory)
+- A type from the default library (`{ from: "lib", name: "PromiseLike" }`)
+- A type from a package (`{ from: "package", name: "Foo", package: "foo-lib" }`, this also works for types defined in a typings package).
+
+Examples of code for this rule with:
+
+```json
+{
+  "allowForKnownSafePromises": [
+    { "from": "file", "name": "SafePromise" },
+    { "from": "lib", "name": "PromiseLike" },
+    { "from": "package", "name": "Bar", "package": "bar-lib" }
+  ]
+}
+```
+
+<Tabs>
+<TabItem value="❌ Incorrect">
+
+```ts option='{"allowForKnownSafePromises":[{"from":"file","name":"SafePromise"},{"from":"lib","name":"PromiseLike"},{"from":"package","name":"Bar","package":"bar-lib"}]}'
+let promise: Promise<number> = Promise.resolve(2);
+promise;
+
+function returnsPromise(): Promise<number> {
+  return Promise.resolve(42);
+}
+
+returnsPromise();
+```
+
+</TabItem>
+<TabItem value="✅ Correct">
+
+```ts option='{"allowForKnownSafePromises":[{"from":"file","name":"SafePromise"},{"from":"lib","name":"PromiseLike"},{"from":"package","name":"Bar","package":"bar-lib"}]}'
+// promises can be marked as safe by using branded types
+type SafePromise = Promise<number> & { __linterBrands?: string };
+
+let promise: SafePromise = Promise.resolve(2);
+promise;
+
+function returnsSafePromise(): SafePromise {
+  return Promise.resolve(42);
+}
+
+returnsSafePromise();
+```
+
+</TabItem>
+</Tabs>
+
+### `allowForKnownSafeCalls`
+
+This option allows marking specific functions as "safe" to be called to create floating Promises.
+For example, you may need to do this in the case of libraries whose APIs may be called without handling the resultant Promises.
+
+This option takes the same array format as [`allowForKnownSafePromises`](#allowForKnownSafePromises).
+
+Examples of code for this rule with:
+
+```json
+{
+  "allowForKnownSafeCalls": [
+    { "from": "file", "name": "safe", "path": "input.ts" }
+  ]
+}
+```
+
+<Tabs>
+<TabItem value="❌ Incorrect">
+
+```ts option='{"allowForKnownSafeCalls":[{"from":"file","name":"safe","path":"input.ts"}]}'
+declare function unsafe(...args: unknown[]): Promise<void>;
+
+unsafe('...', () => {});
+```
+
+</TabItem>
+<TabItem value="✅ Correct">
+
+```ts option='{"allowForKnownSafeCalls":[{"from":"file","name":"safe","path":"input.ts"}]}' skipValidation
+declare function safe(...args: unknown[]): Promise<void>;
+
+safe('...', () => {});
+```
+
+</TabItem>
+</Tabs>
+
 ## When Not To Use It
 
 This rule can be difficult to enable on large existing projects that set up many floating Promises.

package/docs/rules/no-import-type-side-effects.mdx

@@ -76,5 +76,5 @@ If you're not using TypeScript 5.0's `verbatimModuleSyntax` option and your proj
 ## Related To
 
 - [`consistent-type-imports`](./consistent-type-imports.mdx)
-- [`import/consistent-type-specifier-style`](https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/consistent-type-specifier-style.mdx)
+- [`import/consistent-type-specifier-style`](https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/consistent-type-specifier-style.md)
 - [`import/no-duplicates` with `{"prefer-inline": true}`](https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/no-duplicates.md#inline-type-imports)

package/docs/rules/no-misused-promises.mdx

@@ -127,19 +127,18 @@ Examples of code for this rule with `checksVoidReturn: true`:
 
 ```ts option='{ "checksVoidReturn": true }'
 [1, 2, 3].forEach(async value => {
-  await doSomething(value);
+  await fetch(`/${value}`);
 });
 
-new Promise(async (resolve, reject) => {
-  await doSomething();
+new Promise<void>(async (resolve, reject) => {
+  await fetch('/');
   resolve();
 });
 
-const eventEmitter = new EventEmitter();
-eventEmitter.on('some-event', async () => {
-  synchronousCall();
-  await doSomething();
-  otherSynchronousCall();
+document.addEventListener('click', async () => {
+  console.log('synchronous call');
+  await fetch('/');
+  console.log('synchronous call');
 });
 ```
 
@@ -169,8 +168,7 @@ new Promise((resolve, reject) => {
 });
 
 // Name the async wrapper to call it later
-const eventEmitter = new EventEmitter();
-eventEmitter.on('some-event', () => {
+document.addEventListener('click', () => {
   const handler = async () => {
     await doSomething();
     otherSynchronousCall();
@@ -210,30 +208,30 @@ Examples of code for this rule with `checksSpreads: true`:
 <TabItem value="❌ Incorrect">
 
 ```ts option='{ "checksSpreads": true }'
-const getData = () => someAsyncOperation({ myArg: 'foo' });
+const getData = () => fetch('/');
 
-return { foo: 42, ...getData() };
+console.log({ foo: 42, ...getData() });
 
-const getData2 = async () => {
-  await someAsyncOperation({ myArg: 'foo' });
+const awaitData = async () => {
+  await fetch('/');
 };
 
-return { foo: 42, ...getData2() };
+console.log({ foo: 42, ...awaitData() });
 ```
 
 </TabItem>
 <TabItem value="✅ Correct">
 
 ```ts option='{ "checksSpreads": true }'
-const getData = () => someAsyncOperation({ myArg: 'foo' });
+const getData = () => fetch('/');
 
-return { foo: 42, ...(await getData()) };
+console.log({ foo: 42, ...(await getData()) });
 
-const getData2 = async () => {
-  await someAsyncOperation({ myArg: 'foo' });
+const awaitData = async () => {
+  await fetch('/');
 };
 
-return { foo: 42, ...(await getData2()) };
+console.log({ foo: 42, ...(await awaitData()) });
 ```
 
 </TabItem>

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

@@ -38,7 +38,7 @@ import * as lib3 from 'lib3';
 
 ### `allow`
 
-A array of strings. These strings will be compiled into regular expressions with the `u` flag and be used to test against the imported path. A common use case is to allow importing `package.json`. This is because `package.json` commonly lives outside of the TS root directory, so statically importing it would lead to root directory conflicts, especially with `resolveJsonModule` enabled. You can also use it to allow importing any JSON if your environment doesn't support JSON modules, or use it for other cases where `import` statements cannot work.
+An array of strings. These strings will be compiled into regular expressions with the `u` flag and be used to test against the imported path. A common use case is to allow importing `package.json`. This is because `package.json` commonly lives outside of the TS root directory, so statically importing it would lead to root directory conflicts, especially with `resolveJsonModule` enabled. You can also use it to allow importing any JSON if your environment doesn't support JSON modules, or use it for other cases where `import` statements cannot work.
 
 With `{allow: ['/package\\.json$']}`:
 
@@ -59,6 +59,33 @@ console.log(require('../package.json').version);
 </TabItem>
 </Tabs>
 
+### `allowAsImport`
+
+When set to `true`, the `import x = require(...)` declaration won't be reported.
+This is useful if you use certain module options that require strict CommonJS interop semantics.
+
+With `{allowAsImport: true}`:
+
+<Tabs>
+<TabItem value="❌ Incorrect">
+
+```ts option='{ "allowAsImport": true }'
+var foo = require('foo');
+const foo = require('foo');
+let foo = require('foo');
+```
+
+</TabItem>
+<TabItem value="✅ Correct">
+
+```ts option='{ "allowAsImport": true }'
+import foo = require('foo');
+import foo from 'foo';
+```
+
+</TabItem>
+</Tabs>
+
 ## When Not To Use It
 
 If your project frequently uses older CommonJS `require`s, then this rule might not be applicable to you.

package/docs/rules/no-restricted-types.mdx

@@ -0,0 +1,71 @@
+---
+description: 'Disallow certain types.'
+---
+
+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-restricted-types** for documentation.
+
+It can sometimes be useful to ban specific types from being used in type annotations.
+For example, a project might be migrating from using one type to another, and want to ban references to the old type.
+
+This rule can be configured to ban a list of specific types and can suggest alternatives.
+Note that it does not ban the corresponding runtime objects from being used.
+
+## Options
+
+### `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 (`OldType`) or a a type name with generic parameter instantiation(s) (`OldType<MyArgument>`).
+
+The values can be:
+
+- A string, which is the error message to be reported; or
+- `false` to specifically un-ban this type (useful when you are using `extendDefaults`); or
+- 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.
+  - `suggest?: string[]`: a list of suggested replacements for the banned type.
+
+Example configuration:
+
+```jsonc
+{
+  "@typescript-eslint/no-restricted-types": [
+    "error",
+    {
+      "types": {
+        // add a custom message to help explain why not to use it
+        "OldType": "Don't use OldType because it is unsafe",
+
+        // add a custom message, and tell the plugin how to fix it
+        "OldAPI": {
+          "message": "Use NewAPI instead",
+          "fixWith": "NewAPI",
+        },
+
+        // add a custom message, and tell the plugin how to suggest a fix
+        "SoonToBeOldAPI": {
+          "message": "Use NewAPI instead",
+          "suggest": ["NewAPIOne", "NewAPITwo"],
+        },
+      },
+    },
+  ],
+}
+```
+
+## When Not To Use It
+
+If you have no need to ban specific types from being used in type annotations, you don't need this rule.
+
+## Related To
+
+- [`no-empty-object-type`](./no-empty-object-type.mdx)
+- [`no-unsafe-function-type`](./no-unsafe-function-type.mdx)
+- [`no-wrapper-object-types`](./no-wrapper-object-types.mdx)

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

@@ -19,7 +19,7 @@ TypeScript type aliases are a commonly necessary language feature; banning it al
 :::note
 
 If you want to ban certain classifications of type aliases, consider using [`no-restricted-syntax`](https://eslint.org/docs/latest/rules/no-restricted-syntax).
-See [Troubleshooting & FAQs](/troubleshooting#how-can-i-ban-specific-language-feature).
+See [Troubleshooting & FAQs](/troubleshooting/faqs/general#how-can-i-ban-specific-language-feature).
 
 :::
 

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

@@ -114,11 +114,11 @@ if (someNullCondition !== false) {
 
 ```ts option='{ "allowComparingNullableBooleansToFalse": false }'
 declare const someUndefinedCondition: boolean | undefined;
-if (someUndefinedCondition ?? true) {
+if (!(someUndefinedCondition ?? true)) {
 }
 
 declare const someNullCondition: boolean | null;
-if (!(someNullCondition ?? true)) {
+if (someNullCondition ?? true) {
 }
 ```
 
@@ -127,16 +127,16 @@ if (!(someNullCondition ?? true)) {
 
 ## Fixer
 
-|            Comparison             | Fixer Output                    | Notes                                                                               |
-| :-------------------------------: | ------------------------------- | ----------------------------------------------------------------------------------- |
-|       `booleanVar === true`       | `booleanVar`                    |                                                                                     |
-|       `booleanVar !== true`       | `!booleanVar`                   |                                                                                     |
-|      `booleanVar === false`       | `!booleanVar`                   |                                                                                     |
-|      `booleanVar !== false`       | `booleanVar`                    |                                                                                     |
-|   `nullableBooleanVar === true`   | `nullableBooleanVar`            | Only checked/fixed if the `allowComparingNullableBooleansToTrue` option is `false`  |
-|   `nullableBooleanVar !== true`   | `!nullableBooleanVar`           | Only checked/fixed if the `allowComparingNullableBooleansToTrue` option is `false`  |
-| `!(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` |
+|           Comparison           | Fixer Output                    | Notes                                                                               |
+| :----------------------------: | ------------------------------- | ----------------------------------------------------------------------------------- |
+|     `booleanVar === true`      | `booleanVar`                    |                                                                                     |
+|     `booleanVar !== true`      | `!booleanVar`                   |                                                                                     |
+|     `booleanVar === false`     | `!booleanVar`                   |                                                                                     |
+|     `booleanVar !== false`     | `booleanVar`                    |                                                                                     |
+| `nullableBooleanVar === true`  | `nullableBooleanVar`            | Only checked/fixed if the `allowComparingNullableBooleansToTrue` option is `false`  |
+| `nullableBooleanVar !== true`  | `!nullableBooleanVar`           | Only checked/fixed if the `allowComparingNullableBooleansToTrue` option is `false`  |
+| `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` |
 
 ## When Not To Use It