Aug 29, 2024 · Aug 23, 2024
diff --git a/packages/eslint-plugin/docs/rules/ban-ts-comment.mdx b/packages/eslint-plugin/docs/rules/ban-ts-comment.mdx

 ## When Not To Use It

 If your project or its dependencies were not architected with strong type safety in mind, it can be difficult to always adhere to proper TypeScript semantics.
 If your projector its dependencies were not architected with strong type safety in mind, it can be difficult to always adhere to proper TypeScript semantics.
 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
diff --git a/packages/eslint-plugin/docs/rules/consistent-type-assertions.mdx b/packages/eslint-plugin/docs/rules/consistent-type-assertions.mdx

 ### `assertionStyle`

 This option defines theexpected assertion style. Valid values for `assertionStyle` are:
 Theexpected assertion style to enforce. Valid values for `assertionStyle` are:

 - `as` will enforce that you always use `... as foo`.
 - `angle-bracket` will enforce that you always use `<foo>...`

 ### `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.
 Whether to always prefer type declarations for object literals used as variable initializers, rather than type assertions.

 For example, this would 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.

diff --git a/packages/eslint-plugin/docs/rules/consistent-type-exports.mdx b/packages/eslint-plugin/docs/rules/consistent-type-exports.mdx

 ### `fixMixedExportsWithInlineTypeSpecifier`

 When this is set to true,the rule will autofix "mixed" export cases using TS4.5's "inline typespecifier".
 Whetherthe rule will autofix "mixed" export cases using TS inline typespecifiers.
 If you are using a TypeScript version less than 4.5, then you will not be able to use this option.

 For example the following code:
diff --git a/packages/eslint-plugin/docs/rules/consistent-type-imports.mdx b/packages/eslint-plugin/docs/rules/consistent-type-imports.mdx

 ### `prefer`

 This option defines the expected import kind for type-only imports. Valid values for `prefer` are:
 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 the default.
 - `no-type-imports` will enforce that you always use `import Foo from '...'`.

 ### `fixStyle`

 This option defines the expected type modifier to be added when an import is detected as used only in the type position. Valid values for `fixStyle` are:
 The expected type modifier to be added when an import is detected as used only in the type position. Valid values for `fixStyle` are:

 - `separate-type-imports` will add the type keyword after the import keyword `import type { A } from '...'`. It is the default.
 - `inline-type-imports` will inline the type keyword `import { type A } from '...'` and is only available in TypeScript 4.5 and onwards. See [documentation here](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-5.html#type-modifiers-on-import-names 'TypeScript 4.5 documentation on type modifiers and import names').

 ### `disallowTypeAnnotations`

 If `true`,type imports in type annotations (`import()`) are not allowed.
 Whether to disallowtype imports in type annotations (`import()`).
 Default is `true`.

 Examples of **incorrect** code with `{disallowTypeAnnotations: true}`:
diff --git a/packages/eslint-plugin/docs/rules/dot-notation.mdx b/packages/eslint-plugin/docs/rules/dot-notation.mdx

 ### `allowPrivateClassPropertyAccess`

 Whether to allow accessing class members marked as `private` with array notation.
 This can be useful because TypeScript will report a type error on dot notation but not array notation.

 Example of a correct code when `allowPrivateClassPropertyAccess` is set to `true`:

 ```ts option='{ "allowPrivateClassPropertyAccess": true }' showPlaygroundButton

 ### `allowProtectedClassPropertyAccess`

 Whether to allow accessing class members marked as `protected` with array notation.
 This can be useful because TypeScript will report a type error on dot notation but not array notation.

 Example of a correct code when `allowProtectedClassPropertyAccess` is set to `true`:

 ```ts option='{ "allowProtectedClassPropertyAccess": true }' showPlaygroundButton

 ### `allowIndexSignaturePropertyAccess`

 Whether to allow accessing properties matching an index signature with array notation.

 Example of correct code when `allowIndexSignaturePropertyAccess` is set to `true`:

 ```ts option='{ "allowIndexSignaturePropertyAccess": true }' showPlaygroundButton
diff --git a/packages/eslint-plugin/docs/rules/explicit-member-accessibility.mdx b/packages/eslint-plugin/docs/rules/explicit-member-accessibility.mdx

 ### `ignoredMethodNames`

 If you want to ignore some specific methods, you can do it by specifying method names. Note that this option does not care for the context, and will ignore every method with these names, which could lead to it missing some cases. You should use this sparingly.
 Specific method names that may be ignored.
 Note that this option does not care for the context, and will ignore every method with these names, which could lead to it missing some cases. You should use this sparingly.
 e.g. `[ { ignoredMethodNames: ['specificMethod', 'whateverMethod'] } ]`

 ```ts option='{ "ignoredMethodNames": ["specificMethod", "whateverMethod"] }' showPlaygroundButton
diff --git a/packages/eslint-plugin/docs/rules/max-params.mdx b/packages/eslint-plugin/docs/rules/max-params.mdx

 This rule extends the base [`eslint/max-params`](https://eslint.org/docs/rules/max-params) rule.
 This version adds support for TypeScript `this` parameters so they won't be counted as a parameter.

 ## Options

 This rule adds the following options:

 ```ts
 interface Options extends BaseMaxParamsOptions {
  countVoidThis?: boolean;
 }

 const defaultOptions: Options = {
  ...baseMaxParamsOptions,
  countVoidThis: false,
 };
 ```

 ### `countVoidThis`

 Whether to count a `this` declaration when the type is `void`.

 Example of a code when `countVoidThis` is set to `false` and `max` is `1`:

 <Tabs>
 <TabItem value="❌ Incorrect">

 ```ts option='{ "countVoidThis": false, "max": 1 }'
 function hasNoThis(this: void, first: string, second: string) {
  // ...
 }
 ```

 </TabItem>
 <TabItem value="✅ Correct">

 ```ts option='{ "countVoidThis": false, "max": 1 }'
 function hasNoThis(this: void, first: string) {
  // ...
 }
 ```

 </TabItem>
 </Tabs>
diff --git a/packages/eslint-plugin/docs/rules/no-base-to-string.mdx b/packages/eslint-plugin/docs/rules/no-base-to-string.mdx

 ### `ignoredTypeNames`

 A string array of type names to ignore, this is useful for types missing `toString()` (but actually has `toString()`).
 Stringified regular expressions of type names to ignore.
 This is useful for types missing `toString()` (but actually has `toString()`).
 There are some types missing `toString()` in old version TypeScript, like `RegExp`, `URL`, `URLSearchParams` etc.

 The following patterns are considered correct with the default options `{ ignoredTypeNames: ["RegExp"] }`:
diff --git a/packages/eslint-plugin/docs/rules/no-confusing-void-expression.mdx b/packages/eslint-plugin/docs/rules/no-confusing-void-expression.mdx

 ### `ignoreArrowShorthand`

 It might be undesirable to wrap every arrow function shorthand expression with braces.
 Especially when using Prettier formatter, which spreads such code across 3 lines instead of 1.
 Whether to ignore "shorthand" `() =>` arrow functions: those without `{ ... }` braces.

 It might be undesirable to wrap every arrow function shorthand expression.
 Especially when using the Prettier formatter, which spreads such code across 3 lines instead of 1.

 Examples of additional **correct** code with this option enabled:


 ### `ignoreVoidOperator`

 Whether to ignore returns that start with the `void` operator.

 It might be preferable to only use some distinct syntax
 to explicitly mark the confusing but valid usage of void expressions.
 This option allows void expressions which are explicitly wrapped in the `void` operator.
diff --git a/packages/eslint-plugin/docs/rules/no-inferrable-types.mdx b/packages/eslint-plugin/docs/rules/no-inferrable-types.mdx

 ### `ignoreParameters`

 Whether to ignore function parameters.

 When set to true, the following pattern is considered valid:

 ```ts option='{ "ignoreParameters": true }' showPlaygroundButton

 ### `ignoreProperties`

 Whether to ignore class properties.

 When set to true, the following pattern is considered valid:

 ```ts option='{ "ignoreProperties": true }' showPlaygroundButton
diff --git a/packages/eslint-plugin/docs/rules/no-invalid-void-type.mdx b/packages/eslint-plugin/docs/rules/no-invalid-void-type.mdx

 ### `allowInGenericTypeArguments`

 This option lets you control if `void` can be used as a valid value for generic type parameters.
 Whether `void` can be used as a valid value for generic type parameters.

 Alternatively, you can provide an array of strings which whitelist which types may accept `void` as a generic type parameter.


 ### `allowAsThisParameter`

 This option allows specifyinga `this` parameter of a functionto be `void` when set to `true`.
 Whethera `this` parameter of a functionmay be `void`.
 This pattern can be useful to explicitly label function types that do not use a `this` argument. [See the TypeScript docs for more information](https://www.typescriptlang.org/docs/handbook/functions.html#this-parameters-in-callbacks).

 This option is `false` by default.
diff --git a/packages/eslint-plugin/docs/rules/no-magic-numbers.mdx b/packages/eslint-plugin/docs/rules/no-magic-numbers.mdx

 ### `ignoreEnums`

 A boolean to specify if enums used in TypeScript are considered okay. `false` by default.
 Whether enums used in TypeScript are considered okay. `false` by default.

 Examples of **incorrect** code for the `{ "ignoreEnums": false }` option:


 ### `ignoreNumericLiteralTypes`

 A boolean to specify if numbers used in TypeScript numeric literal types are considered okay. `false` by default.
 Whether numbers used in TypeScript numeric literal types are considered okay. `false` by default.

 Examples of **incorrect** code for the `{ "ignoreNumericLiteralTypes": false }` option:


 ### `ignoreReadonlyClassProperties`

 Whether `readonly` class properties are considered okay.

 Examples of **incorrect** code for the `{ "ignoreReadonlyClassProperties": false }` option:

 ```ts option='{ "ignoreReadonlyClassProperties": false }' showPlaygroundButton

 ### `ignoreTypeIndexes`

 A boolean to specify if numbers used to index types are okay. `false` by default.
 Whether numbers used to index types are okay. `false` by default.

 Examples of **incorrect** code for the `{ "ignoreTypeIndexes": false }` option:

diff --git a/packages/eslint-plugin/docs/rules/no-meaningless-void-operator.mdx b/packages/eslint-plugin/docs/rules/no-meaningless-void-operator.mdx

 ### `checkNever`

 `checkNever: true` will suggest removing `void` when the argument has type `never`.
 Whether to suggest removing `void` when the argument has type `never`.

 ## When Not To Use It

diff --git a/packages/eslint-plugin/docs/rules/no-misused-promises.mdx b/packages/eslint-plugin/docs/rules/no-misused-promises.mdx

 ### `checksSpreads`

 Whether to warn when `...` spreading a `Promise`.

 If you don't want to check object spreads, you can add this configuration:

 ```json
diff --git a/packages/eslint-plugin/docs/rules/no-redeclare.mdx b/packages/eslint-plugin/docs/rules/no-redeclare.mdx

 ### `ignoreDeclarationMerge`

 When set to `true`, the rule will ignore declaration merges between the following sets:
 Whether to ignore declaration merges between the following sets:

 - interface + interface
 - namespace + namespace
diff --git a/packages/eslint-plugin/docs/rules/no-restricted-imports.mdx b/packages/eslint-plugin/docs/rules/no-restricted-imports.mdx
 }
 ```

 When set to `true`, the rule will allow [Type-Only Imports](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-8.html#type-only-imports-and-export).
 Whether to allow [Type-Only Imports](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-8.html#type-only-imports-and-export).

 Examples of code with the above config:

diff --git a/packages/eslint-plugin/docs/rules/no-shadow.mdx b/packages/eslint-plugin/docs/rules/no-shadow.mdx

 ### `ignoreTypeValueShadow`

 When setto`true`, the rule willignorethe 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.
 Whetherto ignoretypes named 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 }`:


 ### `ignoreFunctionTypeParameterNameValueShadow`

 When setto`true`, the rule willignorethe case when you name a parameter in afunctiontype the same as a variable.
 Whetherto ignore functionparameters named 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:

diff --git a/packages/eslint-plugin/docs/rules/no-use-before-define.mdx b/packages/eslint-plugin/docs/rules/no-use-before-define.mdx

 ### `enums`

 Whether to check references to enums before the enum declaration.

 If this is `true`, this rule warns every reference to a enum before the enum declaration.
 If this is `false`, this rule will ignore references to enums, when the reference is in a child scope.


 ### `typedefs`

 Whether to check references to types before the type declaration.

 If this is `true`, this rule warns every reference to a type before the type declaration.
 If this is `false`, this rule will ignore references to types.


 ### `ignoreTypeReferences`

 If this is `true`, this rule ignores all type references, such as in type annotations and assertions.
 Whether to ignore type references, such as in type annotations and assertions.

 If this is `true`, this rule ignores all type references.
 If this is `false`, this will check all type references.

 Examples of **correct** code for the `{ "ignoreTypeReferences": true }` option:
diff --git a/packages/eslint-plugin/docs/rules/prefer-literal-enum-member.mdx b/packages/eslint-plugin/docs/rules/prefer-literal-enum-member.mdx

 ### `allowBitwiseExpressions`

 When setto`true` willallowyou to usebitwise expressions in enuminitializer (default: `false`).
 Whetherto allowusingbitwise expressions in enuminitializers (default: `false`).

 Examples of code for the `{ "allowBitwiseExpressions": true }` option:

diff --git a/packages/eslint-plugin/docs/rules/prefer-nullish-coalescing.mdx b/packages/eslint-plugin/docs/rules/prefer-nullish-coalescing.mdx

 ### `ignoreTernaryTests`

 Setting this option to `true` will cause the rule to ignore any ternary expressions that could be simplified by using the nullish coalescing operator. This is set to `false` by default.
 Whether to ignore any ternary expressions that could be simplified by using the nullish coalescing operator. This is set to `false` by default.

 Incorrect code for `ignoreTernaryTests: false`, and correct code for `ignoreTernaryTests: true`:


 ### `ignoreConditionalTests`

 Setting this optionto`false` will cause the rule to also check cases that are located within a conditional test. This is set to `true` by default.
 Whethertoignore cases that are located within a conditional test. This is set to `true` by default.

 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.


 ### `ignoreMixedLogicalExpressions`

 Setting this option to `true` will cause the rule to ignore any logical or expressions that are part of a mixed logical expression (with `&&`). This is set to `false` by default.
 Whether to ignore any logical or expressions that are part of a mixed logical expression (with `&&`). This is set to `false` by default.

 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.


 ### `ignorePrimitives`

 Whether to ignore all (`true`) or some (an object with properties) primitive types.

 If you would like to ignore expressions containing operands of certain primitive types that can be falsy then you may pass an object containing a boolean value for each primitive:

 - `string: true`, ignores `null` or `undefined` unions with `string` (default: false).

 ### `allowRuleToRunWithoutStrictNullChecksIKnowWhatIAmDoing`

 If this is set to `false`, then the rule will error on every file whose `tsconfig.json` does _not_ have the `strictNullChecks` compiler option (or `strict`) set to `true`.
 Unless this is set to `true`, the rule will error on every file whose `tsconfig.json` does _not_ have the `strictNullChecks` compiler option (or `strict`) set to `true`.

 Without `strictNullChecks`, TypeScript essentially erases `undefined` and `null` from the types. This means when this rule inspects the types from a variable, **it will not be able to tell that the variable might be `null` or `undefined`**, which essentially makes this rule useless.
Original file line number	Diff line number	Diff line change
Expand Up		@@ -153,7 +153,7 @@ if (false) {

		## When Not To Use It

		If your project or its dependencies were not architected with strong type safety in mind, it can be difficult to always adhere to proper TypeScript semantics.
		If your projector its dependencies were not architected with strong type safety in mind, it can be difficult to always adhere to proper TypeScript semantics.
		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
Expand Down
Original file line number	Diff line number	Diff line change
Expand Up		@@ -30,7 +30,7 @@ Examples of them include `let x = "hello" as const;` and `let x = <const>"hello"

		### `assertionStyle`

		This option defines theexpected assertion style. Valid values for `assertionStyle` are:
		Theexpected assertion style to enforce. Valid values for `assertionStyle` are:

		- `as` will enforce that you always use `... as foo`.
		- `angle-bracket` will enforce that you always use `<foo>...`
Expand All		@@ -42,7 +42,10 @@ Some codebases like to go for an extra level of type safety, and ban assertions

		### `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.
		Whether to always prefer type declarations for object literals used as variable initializers, rather than type assertions.

		For example, this would 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.

Expand Down
Original file line number	Diff line number	Diff line change
Expand Up		@@ -54,7 +54,7 @@ export type { ButtonProps };

		### `fixMixedExportsWithInlineTypeSpecifier`

		When this is set to true,the rule will autofix "mixed" export cases using TS4.5's "inline typespecifier".
		Whetherthe rule will autofix "mixed" export cases using TS inline typespecifiers.
		If you are using a TypeScript version less than 4.5, then you will not be able to use this option.

		For example the following code:
Expand Down
Original file line number	Diff line number	Diff line change
Expand Up		@@ -18,7 +18,7 @@ This allows transpilers to drop imports without knowing the types of the depende

		### `prefer`

		This option defines the expected import kind for type-only imports. Valid values for `prefer` are:
		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 the default.
		- `no-type-imports` will enforce that you always use `import Foo from '...'`.
Expand All		@@ -43,7 +43,7 @@ const x: Bar = 1;

		### `fixStyle`

		This option defines the expected type modifier to be added when an import is detected as used only in the type position. Valid values for `fixStyle` are:
		The expected type modifier to be added when an import is detected as used only in the type position. Valid values for `fixStyle` are:

		- `separate-type-imports` will add the type keyword after the import keyword `import type { A } from '...'`. It is the default.
		- `inline-type-imports` will inline the type keyword `import { type A } from '...'` and is only available in TypeScript 4.5 and onwards. See [documentation here](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-5.html#type-modifiers-on-import-names 'TypeScript 4.5 documentation on type modifiers and import names').
Expand DownExpand Up		@@ -83,7 +83,7 @@ const x: Bar = 1;

		### `disallowTypeAnnotations`

		If `true`,type imports in type annotations (`import()`) are not allowed.
		Whether to disallowtype imports in type annotations (`import()`).
		Default is `true`.

		Examples of incorrect code with `{disallowTypeAnnotations: true}`:
Expand Down
Original file line number	Diff line number	Diff line change
Expand Up		@@ -38,6 +38,9 @@ If the TypeScript compiler option `noPropertyAccessFromIndexSignature` is set to

		### `allowPrivateClassPropertyAccess`

		Whether to allow accessing class members marked as `private` with array notation.
		This can be useful because TypeScript will report a type error on dot notation but not array notation.

		Example of a correct code when `allowPrivateClassPropertyAccess` is set to `true`:

		```ts option='{ "allowPrivateClassPropertyAccess": true }' showPlaygroundButton
Expand All		@@ -51,6 +54,9 @@ x['priv_prop'] = 123;

		### `allowProtectedClassPropertyAccess`

		Whether to allow accessing class members marked as `protected` with array notation.
		This can be useful because TypeScript will report a type error on dot notation but not array notation.

		Example of a correct code when `allowProtectedClassPropertyAccess` is set to `true`:

		```ts option='{ "allowProtectedClassPropertyAccess": true }' showPlaygroundButton
Expand All		@@ -64,6 +70,8 @@ x['protected_prop'] = 123;

		### `allowIndexSignaturePropertyAccess`

		Whether to allow accessing properties matching an index signature with array notation.

		Example of correct code when `allowIndexSignaturePropertyAccess` is set to `true`:

		```ts option='{ "allowIndexSignaturePropertyAccess": true }' showPlaygroundButton
Expand Down
Original file line number	Diff line number	Diff line change
Expand Up		@@ -317,7 +317,8 @@ class Animal {

		### `ignoredMethodNames`

		If you want to ignore some specific methods, you can do it by specifying method names. Note that this option does not care for the context, and will ignore every method with these names, which could lead to it missing some cases. You should use this sparingly.
		Specific method names that may be ignored.
		Note that this option does not care for the context, and will ignore every method with these names, which could lead to it missing some cases. You should use this sparingly.
		e.g. `[ { ignoredMethodNames: ['specificMethod', 'whateverMethod'] } ]`

		```ts option='{ "ignoredMethodNames": ["specificMethod", "whateverMethod"] }' showPlaygroundButton
Expand Down
Original file line number	Diff line number	Diff line change
Expand Up		@@ -11,3 +11,45 @@ import TabItem from '@theme/TabItem';

		This rule extends the base [`eslint/max-params`](https://eslint.org/docs/rules/max-params) rule.
		This version adds support for TypeScript `this` parameters so they won't be counted as a parameter.

		## Options

		This rule adds the following options:

		```ts
		interface Options extends BaseMaxParamsOptions {
		countVoidThis?: boolean;
		}

		const defaultOptions: Options = {
		...baseMaxParamsOptions,
		countVoidThis: false,
		};
		```

		### `countVoidThis`

		Whether to count a `this` declaration when the type is `void`.

		Example of a code when `countVoidThis` is set to `false` and `max` is `1`:

		<Tabs>
		<TabItem value="❌ Incorrect">

		```ts option='{ "countVoidThis": false, "max": 1 }'
		function hasNoThis(this: void, first: string, second: string) {
		// ...
		}
		```

		</TabItem>
		<TabItem value="✅ Correct">

		```ts option='{ "countVoidThis": false, "max": 1 }'
		function hasNoThis(this: void, first: string) {
		// ...
		}
		```

		</TabItem>
		</Tabs>
Original file line number	Diff line number	Diff line change
Expand Up		@@ -66,7 +66,8 @@ const literalWithToString = {

		### `ignoredTypeNames`

		A string array of type names to ignore, this is useful for types missing `toString()` (but actually has `toString()`).
		Stringified regular expressions of type names to ignore.
		This is useful for types missing `toString()` (but actually has `toString()`).
		There are some types missing `toString()` in old version TypeScript, like `RegExp`, `URL`, `URLSearchParams` etc.

		The following patterns are considered correct with the default options `{ ignoredTypeNames: ["RegExp"] }`:
Expand Down
Original file line number	Diff line number	Diff line change
Expand Up		@@ -77,8 +77,10 @@ cond ? console.log('true') : console.error('false');

		### `ignoreArrowShorthand`

		It might be undesirable to wrap every arrow function shorthand expression with braces.
		Especially when using Prettier formatter, which spreads such code across 3 lines instead of 1.
		Whether to ignore "shorthand" `() =>` arrow functions: those without `{ ... }` braces.

		It might be undesirable to wrap every arrow function shorthand expression.
		Especially when using the Prettier formatter, which spreads such code across 3 lines instead of 1.

		Examples of additional correct code with this option enabled:

Expand All		@@ -88,6 +90,8 @@ promise.then(value => window.postMessage(value));

		### `ignoreVoidOperator`

		Whether to ignore returns that start with the `void` operator.

		It might be preferable to only use some distinct syntax
		to explicitly mark the confusing but valid usage of void expressions.
		This option allows void expressions which are explicitly wrapped in the `void` operator.
Expand Down
Original file line number	Diff line number	Diff line change
Expand Up		@@ -80,6 +80,8 @@ function fn(a = 5, b = true) {}

		### `ignoreParameters`

		Whether to ignore function parameters.

		When set to true, the following pattern is considered valid:

		```ts option='{ "ignoreParameters": true }' showPlaygroundButton
Expand All		@@ -90,6 +92,8 @@ function foo(a: number = 5, b: boolean = true) {

		### `ignoreProperties`

		Whether to ignore class properties.

		When set to true, the following pattern is considered valid:

		```ts option='{ "ignoreProperties": true }' showPlaygroundButton
Expand Down