Release 1.31.0 (#670)

Boshen · web-flow · commit e8ca9f0410a9 · 2025-12-02T16:00:54.000+08:00
Co-authored-by: Boshen &lt;1430279+Boshen@users.noreply.github.com&gt;
diff --git a/src/docs/guide/usage/linter/generated-rules.md b/src/docs/guide/usage/linter/generated-rules.md
@@ -6,7 +6,7 @@ search: false
 
 The progress of all rule implementations is tracked [here](https://github.com/oxc-project/oxc/issues/481).
 
-- Total number of rules: 617
+- Total number of rules: 618
 - Rules turned on by default: 103
 
 **Legend for 'Fixable?' column:**
@@ -238,7 +238,7 @@ Code that can be written to run faster.
 | [prefer-array-flat-map](/docs/guide/usage/linter/rules/unicorn/prefer-array-flat-map.html)                | unicorn    |         | 🛠️        |
 | [prefer-set-has](/docs/guide/usage/linter/rules/unicorn/prefer-set-has.html)                              | unicorn    |         | ⚠️🛠️️       |
 
-## Restriction (78):
+## Restriction (79):
 
 Lints which prevent the use of language and library features. Must not be enabled as a whole, should be considered on a case-by-case basis before enabling.
 
@@ -302,6 +302,7 @@ Lints which prevent the use of language and library features. Must not be enable
 | [no-non-null-asserted-nullish-coalescing](/docs/guide/usage/linter/rules/typescript/no-non-null-asserted-nullish-coalescing.html) | typescript |         |          |
 | [no-non-null-assertion](/docs/guide/usage/linter/rules/typescript/no-non-null-assertion.html)                                     | typescript |         |          |
 | [no-require-imports](/docs/guide/usage/linter/rules/typescript/no-require-imports.html)                                           | typescript |         | 🚧       |
+| [no-restricted-types](/docs/guide/usage/linter/rules/typescript/no-restricted-types.html)                                         | typescript |         | 🛠️💡      |
 | [no-var-requires](/docs/guide/usage/linter/rules/typescript/no-var-requires.html)                                                 | typescript |         |          |
 | [non-nullable-type-assertion-style](/docs/guide/usage/linter/rules/typescript/non-nullable-type-assertion-style.html)             | typescript |         | 🚧       |
 | [prefer-literal-enum-member](/docs/guide/usage/linter/rules/typescript/prefer-literal-enum-member.html)                           | typescript |         |          |
diff --git a/src/docs/guide/usage/linter/rules/eslint/no-bitwise.md b/src/docs/guide/usage/linter/rules/eslint/no-bitwise.md
@@ -75,7 +75,7 @@ type: `boolean`
 
 default: `false`
 
-When set to true the `int32Hint` option allows the use of bitwise OR in |0
+When set to `true` the `int32Hint` option allows the use of bitwise OR in |0
 pattern for type casting.
 
 For example with `{ "int32Hint": true }` the following is permitted:
diff --git a/src/docs/guide/usage/linter/rules/eslint/no-obj-calls.md b/src/docs/guide/usage/linter/rules/eslint/no-obj-calls.md
@@ -15,7 +15,10 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin
 
 ### What it does
 
-Disallow calling some global objects as functions
+Disallow calling some global objects as functions.
+
+It is safe to disable this rule when using TypeScript, because
+TypeScript's compiler enforces this check.
 
 ### Why is this bad?
 
diff --git a/src/docs/guide/usage/linter/rules/eslint/no-proto.md b/src/docs/guide/usage/linter/rules/eslint/no-proto.md
@@ -15,14 +15,17 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin
 
 ### What it does
 
-Disallow the use of the `__proto__` property
+Disallow the use of the `__proto__` property.
 
 ### Why is this bad?
 
 The `__proto__` property has been deprecated as of ECMAScript 3.1 and
 shouldn’t be used in new code. Use `Object.getPrototypeOf` and
 `Object.setPrototypeOf` instead.
 
+For more information, see
+[the MDN documentation](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/proto).
+
 ### Examples
 
 Examples of **incorrect** code for this rule:
diff --git a/src/docs/guide/usage/linter/rules/eslint/no-redeclare.md b/src/docs/guide/usage/linter/rules/eslint/no-redeclare.md
@@ -40,7 +40,7 @@ a = 10;
 
 This rule accepts a configuration object with the following properties:
 
-### builtInGlobals
+### builtinGlobals
 
 type: `boolean`
 
diff --git a/src/docs/guide/usage/linter/rules/eslint/no-return-assign.md b/src/docs/guide/usage/linter/rules/eslint/no-return-assign.md
@@ -15,7 +15,7 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin
 
 ### What it does
 
-Disallows assignment operators in return statements
+Disallows assignment operators in return statements.
 
 ### Why is this bad?
 
@@ -46,15 +46,16 @@ function x() {
 
 ## Configuration
 
-This rule accepts a configuration object with the following properties:
+This rule accepts one of the following string values:
 
-### alwaysDisallowAssignmentInReturn
+### `"always"`
 
-type: `boolean`
+Disallow all assignments in return statements.
 
-default: `false`
+### `"except-parens"`
 
-Whether to always disallow assignment in return statements.
+Allow assignments in return statements only if they are enclosed in parentheses.
+This is the default mode.
 
 ## How to use
 
diff --git a/src/docs/guide/usage/linter/rules/eslint/no-unused-expressions.md b/src/docs/guide/usage/linter/rules/eslint/no-unused-expressions.md
@@ -65,7 +65,7 @@ default: `false`
 
 When set to `true`, allows ternary operators in expressions.
 
-### enforceForJsx
+### enforceForJSX
 
 type: `boolean`
 
diff --git a/src/docs/guide/usage/linter/rules/eslint/radix.md b/src/docs/guide/usage/linter/rules/eslint/radix.md
@@ -19,7 +19,12 @@ Enforce the consistent use of the radix argument when using `parseInt()`.
 
 ### Why is this bad?
 
-Using the `parseInt()` function without specifying the radix can lead to unexpected results.
+Using the `parseInt()` function without specifying
+the radix can lead to unexpected results.
+
+See the
+[MDN documentation](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/parseInt#radix)
+for more information.
 
 ### Examples
 
@@ -37,15 +42,15 @@ var num = parseInt("071", 10); // 71
 
 ## Configuration
 
-This rule accepts a configuration object with the following properties:
+This rule accepts one of the following string values:
 
-### radixType
+### `"always"`
 
-type: `"always" | "as-needed"`
+Always require the radix parameter when using `parseInt()`.
 
-default: `"always"`
+### `"as-needed"`
 
-Configuration option to specify when to require the radix parameter.
+Only require the radix parameter when necessary.
 
 ## How to use
 
diff --git a/src/docs/guide/usage/linter/rules/eslint/unicode-bom.md b/src/docs/guide/usage/linter/rules/eslint/unicode-bom.md
@@ -35,13 +35,16 @@ var a = 123;
 
 ## Configuration
 
-This rule accepts a configuration object with the following properties:
+This rule accepts one of the following string values:
 
-### bomOption
+### `"always"`
 
-type: `"always" | "never"`
+Always require a Unicode BOM (Byte Order Mark) at the beginning of the file.
 
-Configuration option to specify whether to require or disallow Unicode BOM.
+### `"never"`
+
+Never allow a Unicode BOM (Byte Order Mark) at the beginning of the file.
+This is the default option.
 
 ## How to use
 
diff --git a/src/docs/guide/usage/linter/rules/import/consistent-type-specifier-style.md b/src/docs/guide/usage/linter/rules/import/consistent-type-specifier-style.md
@@ -55,18 +55,15 @@ import Foo, { type Bar } from "Foo";
 
 ## Configuration
 
-This rule accepts a configuration object with the following properties:
+This rule accepts one of the following string values:
 
-### mode
+### `"prefer-top-level"`
 
-type: `"prefer-top-level" | "prefer-inline"`
+Prefer `import type { Foo } from 'foo'` for type imports.
 
-default: `"prefer-top-level"`
+### `"prefer-inline"`
 
-Specify whether to prefer top-level type-only imports or inline type specifiers.
-
-- `"prefer-top-level"`: `import type { Foo } from 'foo'`
-- `"prefer-inline"`: `import { type Foo } from 'foo'`
+Prefer `import { type Foo } from 'foo'` for type imports.
 
 ## How to use
 
diff --git a/src/docs/guide/usage/linter/rules/import/first.md b/src/docs/guide/usage/linter/rules/import/first.md
@@ -44,13 +44,11 @@ export { x, y };
 
 ## Configuration
 
-This rule accepts a configuration object with the following properties:
+This rule accepts one of the following string values:
 
-### absolute_first
+### `"absolute-first"`
 
-type: `"absolute-first" | "disable-absolute-first"`
-
-Whether to enforce absolute imports before relative imports.
+Forces absolute imports to be listed before relative imports.
 
 Examples of **incorrect** code for this rule with `"absolute-first"`:
 
@@ -66,6 +64,11 @@ import { y } from "bar";
 import { x } from "./foo";
 ```
 
+### `"disable-absolute-first"`
+
+Disables the absolute-first behavior.
+This is the default behavior.
+
 ## How to use
 
 To **enable** this rule in the CLI or using the config file, you can use:
diff --git a/src/docs/guide/usage/linter/rules/import/no-cycle.md b/src/docs/guide/usage/linter/rules/import/no-cycle.md
@@ -15,7 +15,7 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin
 Ensures that there is no resolvable path back to this module via its dependencies.
 
 This includes cycles of depth 1 (imported module imports me) to "∞" (or Infinity),
-if the maxDepth option is not set.
+if the `maxDepth` option is not set.
 
 ### Why is this bad?
 
diff --git a/src/docs/guide/usage/linter/rules/import/no-duplicates.md b/src/docs/guide/usage/linter/rules/import/no-duplicates.md
@@ -42,7 +42,7 @@ import * as a from "foo"; // separate statements for namespace imports
 import { b } from "foo";
 
 import { c } from "foo"; // separate type imports, unless
-import type { d } from "foo"; // `preferInline` is true
+import type { d } from "foo"; // `prefer-inline` is true
 ```
 
 ## Configuration
diff --git a/src/docs/guide/usage/linter/rules/jsx_a11y/label-has-associated-control.md b/src/docs/guide/usage/linter/rules/jsx_a11y/label-has-associated-control.md
@@ -55,7 +55,7 @@ This rule accepts a configuration object with the following properties:
 
 ### assert
 
-type: `"html-for" | "nesting" | "both" | "either"`
+type: `"htmlFor" | "nesting" | "both" | "either"`
 
 default: `"either"`
 
diff --git a/src/docs/guide/usage/linter/rules/oxc/no-async-await.md b/src/docs/guide/usage/linter/rules/oxc/no-async-await.md
@@ -12,11 +12,14 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin
 
 ### What it does
 
-Disallows the use of async/await.
+Disallows the use of `async`/`await`.
+
+This rule should generally not be used in modern JavaScript/TypeScript
+codebases without good reason.
 
 ### Why is this bad?
 
-This rule is useful for environments that don't support async/await syntax
+This rule is useful for environments that don't support `async`/`await` syntax,
 or when you want to enforce the use of promises or other asynchronous
 patterns instead. It can also be used to maintain consistency in codebases
 that use alternative async patterns.
diff --git a/src/docs/guide/usage/linter/rules/react/jsx-key.md b/src/docs/guide/usage/linter/rules/react/jsx-key.md
@@ -34,6 +34,34 @@ Examples of **correct** code for this rule:
 [1, 2, 3]?.map(x => <BabelEslintApp key={x} />);
 ```
 
+## Configuration
+
+This rule accepts a configuration object with the following properties:
+
+### checkFragmentShorthand
+
+type: `boolean`
+
+default: `true`
+
+When true, check fragment shorthand `<>` for keys
+
+### checkKeyMustBeforeSpread
+
+type: `boolean`
+
+default: `true`
+
+When true, require key prop to be placed before any spread props
+
+### warnOnDuplicates
+
+type: `boolean`
+
+default: `true`
+
+When true, warn on duplicate key values
+
 ## How to use
 
 To **enable** this rule in the CLI or using the config file, you can use:
diff --git a/src/docs/guide/usage/linter/rules/typescript/consistent-type-definitions.md b/src/docs/guide/usage/linter/rules/typescript/consistent-type-definitions.md
@@ -25,7 +25,7 @@ Using the same type declaration style consistently helps with code readability.
 
 ### Examples
 
-By default this rule enforces the use of interfaces for object types.
+By default this rule enforces the use of `interface` for defining object types.
 
 Examples of **incorrect** code for this rule:
 
@@ -46,27 +46,21 @@ interface T {
 
 ## Configuration
 
-This rule accepts a configuration object with the following properties:
+This rule accepts one of the following string values:
 
-### config
+### `"interface"`
 
-type: `"interface" | "type"`
-
-default: `"interface"`
-
-Configuration option to enforce either `interface` or `type` for object type definitions.
-
-Setting to `type` enforces the use of types for object type definitions.
-
-Examples of **incorrect** code for this option:
+Prefer `interface` over `type` for object type definitions:
 
 ```typescript
 interface T {
   x: number;
 }
 ```
 
-Examples of **correct** code for this option:
+### `"type"`
+
+Prefer `type` over `interface` for object type definitions:
 
 ```typescript
 type T = { x: number };
diff --git a/src/docs/guide/usage/linter/rules/typescript/consistent-type-imports.md b/src/docs/guide/usage/linter/rules/typescript/consistent-type-imports.md
@@ -102,6 +102,8 @@ This rule accepts a configuration object with the following properties:
 
 type: `boolean`
 
+default: `true`
+
 Disallow using `import()` in type annotations, like `type T = import('foo')`
 
 ### fixStyle
diff --git a/src/docs/guide/usage/linter/rules/typescript/explicit-function-return-type.md b/src/docs/guide/usage/linter/rules/typescript/explicit-function-return-type.md
@@ -117,7 +117,7 @@ default: `true`
 
 Whether to allow higher-order functions (functions that return another function) without return type annotations.
 
-### allowIifes
+### allowIIFEs
 
 type: `boolean`
 
diff --git a/src/docs/guide/usage/linter/rules/typescript/no-empty-object-type.md b/src/docs/guide/usage/linter/rules/typescript/no-empty-object-type.md
@@ -93,6 +93,31 @@ Allowed values are:
 - `'always'`: to always allow object type literals with no fields
 - `'never'` _(default)_: to never allow object type literals with no fields
 
+### allowWithName
+
+type: `[
+  string,
+  null
+]`
+
+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`.
+
+Example of **incorrect** code for this rule with `{ allowWithName: 'Props$' }`:
+
+```ts
+interface InterfaceValue {}
+type TypeValue = {};
+```
+
+Example of **correct** code for this rule with `{ allowWithName: 'Props$' }`:
+
+```ts
+interface InterfaceProps {}
+type TypeProps = {};
+```
+
 ## How to use
 
 To **enable** this rule in the CLI or using the config file, you can use:
diff --git a/src/docs/guide/usage/linter/rules/typescript/no-extraneous-class.md b/src/docs/guide/usage/linter/rules/typescript/no-extraneous-class.md
diff --git a/src/docs/guide/usage/linter/rules/typescript/no-restricted-types.md b/src/docs/guide/usage/linter/rules/typescript/no-restricted-types.md
diff --git a/src/docs/guide/usage/linter/rules/typescript/switch-exhaustiveness-check.md b/src/docs/guide/usage/linter/rules/typescript/switch-exhaustiveness-check.md
diff --git a/src/docs/guide/usage/linter/rules/typescript/triple-slash-reference.md b/src/docs/guide/usage/linter/rules/typescript/triple-slash-reference.md
diff --git a/src/docs/guide/usage/linter/rules/unicorn/explicit-length-check.md b/src/docs/guide/usage/linter/rules/unicorn/explicit-length-check.md
diff --git a/src/docs/guide/usage/linter/rules/version.data.js b/src/docs/guide/usage/linter/rules/version.data.js
