oxc-project · camc314 · Aug 6, 2025 · Aug 6, 2025
diff --git a/src/docs/guide/usage/linter/generated-config.md b/src/docs/guide/usage/linter/generated-config.md
@@ -275,6 +275,29 @@ See
 [eslint-plugin-jsx-a11y](https://github.com/jsx-eslint/eslint-plugin-jsx-a11y#configurations)'s
 configuration for a full reference.
 
+#### settings.jsx-a11y.attributes
+
+type: `Record<string, array>`
+
+default: `{}`
+
+Map of attribute names to their DOM equivalents.
+This is useful for non-React frameworks that use different attribute names.
+
+Example:
+
+```json
+{
+  "settings": {
+    "jsx-a11y": {
+      "attributes": {
+        "for": ["htmlFor", "for"]
+      }
+    }
+  }
+}
+```
+
 #### settings.jsx-a11y.components
 
 type: `Record<string, string>`

diff --git a/src/docs/guide/usage/linter/generated-rules.md b/src/docs/guide/usage/linter/generated-rules.md
@@ -2,8 +2,8 @@
 
 The progress of all rule implementations is tracked [here](https://github.com/oxc-project/oxc/issues/481).
 
-- Total number of rules: 526
-- Rules turned on by default: 87
+- Total number of rules: 528
+- Rules turned on by default: 88
 
 **Legend for 'Fixable?' column:**
 
@@ -13,7 +13,7 @@ The progress of all rule implementations is tracked [here](https://github.com/ox
 - ⚠️💡: a dangerous suggestion is available for this rule
 - 🚧: an auto-fix or suggestion is possible, but currently not implemented
 
-## Correctness (177):
+## Correctness (178):
 
 Code that is outright wrong or useless.
 
@@ -55,6 +55,7 @@ Code that is outright wrong or useless.
 | [no-shadow-restricted-names](/docs/guide/usage/linter/rules/eslint/no-shadow-restricted-names.html)                                                   | eslint     | ✅      |          |
 | [no-sparse-arrays](/docs/guide/usage/linter/rules/eslint/no-sparse-arrays.html)                                                                       | eslint     | ✅      |          |
 | [no-this-before-super](/docs/guide/usage/linter/rules/eslint/no-this-before-super.html)                                                               | eslint     | ✅      |          |
+| [no-unassigned-vars](/docs/guide/usage/linter/rules/eslint/no-unassigned-vars.html)                                                                   | eslint     | ✅      |          |
 | [no-unsafe-finally](/docs/guide/usage/linter/rules/eslint/no-unsafe-finally.html)                                                                     | eslint     | ✅      |          |
 | [no-unsafe-negation](/docs/guide/usage/linter/rules/eslint/no-unsafe-negation.html)                                                                   | eslint     | ✅      | 🛠️        |
 | [no-unsafe-optional-chaining](/docs/guide/usage/linter/rules/eslint/no-unsafe-optional-chaining.html)                                                 | eslint     | ✅      |          |
@@ -418,7 +419,7 @@ Lints which are rather strict or have occasional false positives.
 | [prefer-type-error](/docs/guide/usage/linter/rules/unicorn/prefer-type-error.html)                                             | unicorn    |         | 🛠️        |
 | [require-number-to-fixed-digits-argument](/docs/guide/usage/linter/rules/unicorn/require-number-to-fixed-digits-argument.html) | unicorn    |         | 🛠️        |
 
-## Style (148):
+## Style (149):
 
 Code that should be written in a more idiomatic way.
 
@@ -452,6 +453,7 @@ Code that should be written in a more idiomatic way.
 | [no-template-curly-in-string](/docs/guide/usage/linter/rules/eslint/no-template-curly-in-string.html)                    | eslint     |         | ⚠️🛠️️       |
 | [no-ternary](/docs/guide/usage/linter/rules/eslint/no-ternary.html)                                                      | eslint     |         |          |
 | [operator-assignment](/docs/guide/usage/linter/rules/eslint/operator-assignment.html)                                    | eslint     |         | ⚠️🛠️️       |
+| [prefer-destructuring](/docs/guide/usage/linter/rules/eslint/prefer-destructuring.html)                                  | eslint     |         | 🚧       |
 | [prefer-exponentiation-operator](/docs/guide/usage/linter/rules/eslint/prefer-exponentiation-operator.html)              | eslint     |         |          |
 | [prefer-numeric-literals](/docs/guide/usage/linter/rules/eslint/prefer-numeric-literals.html)                            | eslint     |         | 🛠️        |
 | [prefer-object-has-own](/docs/guide/usage/linter/rules/eslint/prefer-object-has-own.html)                                | eslint     |         | 🛠️        |

diff --git a/src/docs/guide/usage/linter/rules/eslint/max-params.md b/src/docs/guide/usage/linter/rules/eslint/max-params.md
@@ -64,6 +64,15 @@ This option is for changing the maximum allowed number of function parameters.
 For example `{ "max": 4 }` would mean that having a function take four
 parameters is allowed which overrides the default of three.
 
+### countVoidThis
+
+`{ "countVoidThis": boolean }`
+
+This option is for counting the `this` parameter if it is of type `void`.
+
+For example `{ "countVoidThis": true }` would mean that having a function
+take a `this` parameter of type `void` is counted towards the maximum number of parameters.
+
 ## 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/eslint/no-bitwise.md b/src/docs/guide/usage/linter/rules/eslint/no-bitwise.md
@@ -55,7 +55,7 @@ var x = y > z;
 
 `{ type: string[], default: [] }`
 
-The`allow` option permits the given list of bitwise operators to be used
+The `allow` option permits the given list of bitwise operators to be used
 as exceptions to this rule.
 
 For example `{ "allow": ["~"] }` would allow the use of the bitwise operator

diff --git a/src/docs/guide/usage/linter/rules/eslint/no-irregular-whitespace.md b/src/docs/guide/usage/linter/rules/eslint/no-irregular-whitespace.md
@@ -15,30 +15,32 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin
 
 ### What it does
 
-Disallows the use of irregular whitespaces in the code.
+Disallows the use of irregular whitespace characters in the code.
 
-### Why is this bad
+### Why is this bad?
 
-The use of irregular whitespaces can hinder code readability and
-create inconsistencies, making maintenance and collaboration more challenging.
+Irregular whitespace characters are invisible to most editors and can
+cause unexpected behavior, making code harder to debug and maintain.
+They can also cause issues with code formatting and parsing.
 
 ### Examples
 
 Examples of **incorrect** code for this rule:
 
 ```javascript
-function invalidExample() {
-  return 42;
+// Contains irregular whitespace characters (invisible)
+function example() {
+  var foo = "bar"; // irregular whitespace before 'bar'
 }
 ```
 
-Examples of **incorrect** code for this rule:
+Examples of **correct** code for this rule:
 
-```javascript
-function invalidExample() {
-  return 42;
+````javascript
+function example() {
+  var foo = 'bar'; // regular spaces only
 }
-```
+
 
 ## How to use
 
@@ -48,7 +50,7 @@ To **enable** this rule in the CLI or using the config file, you can use:
 
 ```bash [CLI]
 oxlint --deny no-irregular-whitespace
-```
+````
 
 ```json [Config (.oxlintrc.json)]
 {

diff --git a/src/docs/guide/usage/linter/rules/eslint/no-unassigned-vars.md b/src/docs/guide/usage/linter/rules/eslint/no-unassigned-vars.md
@@ -0,0 +1,69 @@
+<!-- This file is auto-generated by tasks/website/src/linter/rules/doc_page.rs. Do not edit it manually. -->
+
+<script setup>
+import { data } from '../version.data.js';
+const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_linter/src/rules/eslint/no_unassigned_vars.rs`;
+</script>
+
+# eslint/no-unassigned-vars <Badge type="info" text="Correctness" />
+
+<div class="rule-meta">
+<Alert class="default-on" type="success">
+<span class="emoji">✅</span> This rule is turned on by default.
+</Alert>
+</div>
+
+### What it does
+
+Disallow let or var variables that are read but never assigned
+
+### Why is this bad?
+
+This rule flags let or var declarations that are never assigned a value but are still read or used in the code.
+Since these variables will always be undefined, their usage is likely a programming mistake.
+
+### Examples
+
+Examples of **incorrect** code for this rule:
+
+```js
+let status;
+if (status === "ready") {
+  console.log("Ready!");
+}
+```
+
+Examples of **correct** code for this rule:
+
+```js
+let message = "hello";
+console.log(message);
+
+let user;
+user = getUser();
+console.log(user.name);
+```
+
+## How to use
+
+To **enable** this rule in the CLI or using the config file, you can use:
+
+::: code-group
+
+```bash [CLI]
+oxlint --deny no-unassigned-vars
+```
+
+```json [Config (.oxlintrc.json)]
+{
+  "rules": {
+    "no-unassigned-vars": "error"
+  }
+}
+```
+
+:::
+
+## References
+
+- <a v-bind:href="source" target="_blank" rel="noreferrer">Rule Source</a>
diff --git a/src/docs/guide/usage/linter/rules/eslint/no-useless-call.md b/src/docs/guide/usage/linter/rules/eslint/no-useless-call.md
@@ -26,13 +26,13 @@ So if the code about thisArg is a dynamic expression, this rule cannot judge cor
 Examples of **incorrect** code for this rule:
 
 ```js
-// These are same as `foo(1, 2, 3);`
+// These are the same as `foo(1, 2, 3);`
 foo.call(undefined, 1, 2, 3);
 foo.apply(undefined, [1, 2, 3]);
 foo.call(null, 1, 2, 3);
 foo.apply(null, [1, 2, 3]);
 
-// These are same as `obj.foo(1, 2, 3);`
+// These are the same as `obj.foo(1, 2, 3);`
 obj.foo.call(obj, 1, 2, 3);
 obj.foo.apply(obj, [1, 2, 3]);
 ```

diff --git a/src/docs/guide/usage/linter/rules/eslint/no-void.md b/src/docs/guide/usage/linter/rules/eslint/no-void.md
@@ -17,10 +17,10 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin
 
 Disallows the use of the `void` operator.
 
-Why is this bad
+### Why is this bad?
 
-The `void` operator is often used to get `undefined`,
-but this is unnecessary because `undefined` can be used directly instead.
+The `void` operator is often used to get `undefined`, but this is
+unnecessary because `undefined` can be used directly instead.
 
 ### Examples
 

diff --git a/src/docs/guide/usage/linter/rules/eslint/prefer-destructuring.md b/src/docs/guide/usage/linter/rules/eslint/prefer-destructuring.md
@@ -0,0 +1,116 @@
+<!-- This file is auto-generated by tasks/website/src/linter/rules/doc_page.rs. Do not edit it manually. -->
+
+<script setup>
+import { data } from '../version.data.js';
+const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_linter/src/rules/eslint/prefer_destructuring.rs`;
+</script>
+
+# eslint/prefer-destructuring <Badge type="info" text="Style" />
+
+<div class="rule-meta">
+<Alert class="fix" type="info">
+<span class="emoji">🚧</span> An auto-fix is still under development.
+</Alert>
+</div>
+
+### What it does
+
+Require destructuring from arrays and/or objects
+
+### Why is this bad?
+
+With JavaScript ES6, a new syntax was added for creating variables from an array index or object property,
+called destructuring. This rule enforces usage of destructuring
+instead of accessing a property through a member expression.
+
+### Examples
+
+Examples of **incorrect** code for this rule:
+
+```js
+// With `array` enabled
+const foo = array[0];
+bar.baz = array[0];
+// With `object` enabled
+const qux = object.qux;
+const quux = object["quux"];
+```
+
+Examples of **correct** code for this rule:
+
+```js
+// With `array` enabled
+const [foo] = array;
+const arr = array[someIndex];
+[bar.baz] = array;
+
+// With `object` enabled
+const { baz } = object;
+const obj = object.bar;
+```
+
+### Options
+
+This rule takes two arguments, both of which are objects.
+The first object parameter determines what types of destructuring the rule applies to.
+In the first object, there are two properties, array and object,
+that can be used to turn on or off the destructuring requirement for each of those types independently.
+By default, both are true.
+
+```json
+{
+  "prefer-destructuring": ["error", { "array": true, "object": true }]
+}
+```
+
+Alternatively, you can use separate configurations for different assignment types.
+The first argument accepts two other keys instead of array and object.
+One key is VariableDeclarator and the other is AssignmentExpression,
+which can be used to control the destructuring requirement for each of those types independently
+
+```json
+{
+  "prefer-destructuring": [
+    "error",
+    {
+      "VariableDeclarator": { "array": true, "object": true },
+      "AssignmentExpression": { "array": true, "object": true }
+    }
+  ]
+}
+```
+
+#### enforceForRenamedProperties
+
+The rule has a second object argument with a single key,
+enforceForRenamedProperties, which determines whether the object destructuring applies to renamed variables.
+
+```json
+{
+  "prefer-destructuring": ["error", { "array": true, "object": true }, { "enforceForRenamedProperties": true }]
+}
+```
+
+## How to use
+
+To **enable** this rule in the CLI or using the config file, you can use:
+
+::: code-group
+
+```bash [CLI]
+oxlint --deny prefer-destructuring
+```
+
+```json [Config (.oxlintrc.json)]
+{
+  "rules": {
+    "prefer-destructuring": "error"
+  }
+}
+```
+
+:::
+
+## References
+
+- <a v-bind:href="source" target="_blank" rel="noreferrer">Rule Source</a>
diff --git a/src/docs/guide/usage/linter/rules/jest/no-alias-methods.md b/src/docs/guide/usage/linter/rules/jest/no-alias-methods.md
@@ -20,7 +20,7 @@ This rule ensures that only the canonical name as used in the Jest documentation
 ### Why is this bad?
 
 These aliases are going to be removed in the next major version of Jest - see [jestjs/jest#13164](https://github.com/jestjs/jest/issues/13164) for more.
-This rule will makes it easier to search for all occurrences of the method within code, and it ensures consistency among the method names used.
+This rule will make it easier to search for all occurrences of the method within code, and it ensures consistency among the method names used.
 
 ### Examples
 

diff --git a/src/docs/guide/usage/linter/rules/jest/no-duplicate-hooks.md b/src/docs/guide/usage/linter/rules/jest/no-duplicate-hooks.md
@@ -17,6 +17,9 @@ Disallows duplicate hooks in describe blocks.
 ### Why is this bad?
 
 Having duplicate hooks in a describe block can lead to confusion and unexpected behavior.
+When multiple hooks of the same type exist, they all execute in order, which can make it
+difficult to understand the test setup flow and may result in redundant or conflicting
+operations. This makes tests harder to maintain and debug.
 
 ### Examples