Release 1.27.0 (#618)

Boshen · web-flow · commit 2a7f5623eec4 · 2025-11-11T01:05:03.000+08:00
Co-authored-by: Boshen &lt;1430279+Boshen@users.noreply.github.com&gt;
diff --git a/src/docs/guide/usage/linter/generated-cli.md b/src/docs/guide/usage/linter/generated-cli.md
@@ -1,3 +1,7 @@
+---
+search: false
+---
+
 ## Usage
 
 **`oxlint`** \[**`-c`**=_`<./.oxlintrc.json>`_\] \[_`PATH`_\]...
@@ -14,7 +18,7 @@
   If not provided, Oxlint will look for `.oxlintrc.json` in the current working directory.
 
 - **`--tsconfig`**=_`<./tsconfig.json>`_ &mdash;
-  TypeScript `tsconfig.json` path for reading path alias and project references for import plugin
+  TypeScript `tsconfig.json` path for reading path alias and project references for import plugin. If not provided, will look for `tsconfig.json` in the current working directory.
 - **`--init`** &mdash;
   Initialize oxlint configuration with default values
 
diff --git a/src/docs/guide/usage/linter/generated-config.md b/src/docs/guide/usage/linter/generated-config.md
@@ -1,3 +1,7 @@
+---
+search: false
+---
+
 # Oxlint Configuration File
 
 This configuration is aligned with ESLint v8's configuration schema (`eslintrc.json`).
diff --git a/src/docs/guide/usage/linter/generated-rules.md b/src/docs/guide/usage/linter/generated-rules.md
@@ -1,3 +1,7 @@
+---
+search: false
+---
+
 # Rules
 
 The progress of all rule implementations is tracked [here](https://github.com/oxc-project/oxc/issues/481).
@@ -516,7 +520,7 @@ Code that should be written in a more idiomatic way.
 | [no-new-func](/docs/guide/usage/linter/rules/eslint/no-new-func.html)                                                    | eslint     |         |          |
 | [no-return-assign](/docs/guide/usage/linter/rules/eslint/no-return-assign.html)                                          | eslint     |         | 🚧       |
 | [no-script-url](/docs/guide/usage/linter/rules/eslint/no-script-url.html)                                                | eslint     |         |          |
-| [no-template-curly-in-string](/docs/guide/usage/linter/rules/eslint/no-template-curly-in-string.html)                    | eslint     |         | ⚠️🛠️️       |
+| [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     |         |          |
 | [no-useless-computed-key](/docs/guide/usage/linter/rules/eslint/no-useless-computed-key.html)                            | eslint     |         | 🚧       |
 | [operator-assignment](/docs/guide/usage/linter/rules/eslint/operator-assignment.html)                                    | eslint     |         | ⚠️🛠️️       |
diff --git a/src/docs/guide/usage/linter/rules/eslint/no-compare-neg-zero.md b/src/docs/guide/usage/linter/rules/eslint/no-compare-neg-zero.md
@@ -18,13 +18,13 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin
 
 ### What it does
 
-Disallow comparing against -0
+Disallow comparing against `-0`
 
 ### Why is this bad?
 
-The rule should warn against code that tries to compare against -0,
-since that will not work as intended. That is, code like x === -0 will
-pass for both +0 and -0. The author probably intended Object.is(x, -0).
+The rule should warn against code that tries to compare against `-0`,
+since that will not work as intended. That is, code like `x === -0` will
+pass for both `+0` and `-0`. The author probably intended `Object.is(x, -0)`.
 
 ### Examples
 
diff --git a/src/docs/guide/usage/linter/rules/eslint/no-extra-boolean-cast.md b/src/docs/guide/usage/linter/rules/eslint/no-extra-boolean-cast.md
@@ -23,7 +23,7 @@ This rule disallows unnecessary boolean casts.
 ### Why is this bad?
 
 In contexts such as an if statement's test where the result of the expression will already be coerced to a Boolean,
-casting to a Boolean via double negation (!!) or a Boolean call is unnecessary.
+casting to a Boolean via double negation (`!!`) or a `Boolean` call is unnecessary.
 
 ### Examples
 
diff --git a/src/docs/guide/usage/linter/rules/eslint/no-template-curly-in-string.md b/src/docs/guide/usage/linter/rules/eslint/no-template-curly-in-string.md
@@ -8,9 +8,6 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin
 # eslint/no-template-curly-in-string <Badge type="info" text="Style" />
 
 <div class="rule-meta">
-<Alert class="fix" type="info">
-<span class="emoji">⚠️🛠️️</span> A dangerous auto-fix is available for this rule.
-</Alert>
 </div>
 
 ### What it does
diff --git a/src/docs/guide/usage/linter/rules/eslint/no-this-before-super.md b/src/docs/guide/usage/linter/rules/eslint/no-this-before-super.md
@@ -19,8 +19,8 @@ Requires calling `super()` before using `this` or `super`.
 
 ### Why is this bad?
 
-Getters should always return a value.
-If they don't, it's probably a mistake.
+In the constructor of derived classes, if `this`/`super` are used before `super()` calls,
+it raises a ReferenceError.
 
 ### Examples
 
diff --git a/src/docs/guide/usage/linter/rules/eslint/no-unsafe-optional-chaining.md b/src/docs/guide/usage/linter/rules/eslint/no-unsafe-optional-chaining.md
@@ -19,7 +19,7 @@ Disallow use of optional chaining in contexts where the undefined value is not a
 
 ### Why is this bad?
 
-The optional chaining (?.) expression can short-circuit with a return value of undefined.
+The optional chaining (`?.`) expression can short-circuit with a return value of undefined.
 Therefore, treating an evaluated optional chaining expression as a function, object, number, etc.,
 can cause TypeError or unexpected results. For example:
 
diff --git a/src/docs/guide/usage/linter/rules/eslint/no-unused-vars.md b/src/docs/guide/usage/linter/rules/eslint/no-unused-vars.md
@@ -80,7 +80,7 @@ is used or unused in a Vue file.
 
 The original ESLint rule recognizes `/* exported variableName */`
 comments as a way to indicate that a variable is used in another script
-and should not be considered unused. Since ES6 modules are now a TC39
+and should not be considered unused. Since ES modules are now a TC39
 standard, Oxlint does not support this feature.
 
 ### Examples
@@ -177,7 +177,7 @@ Examples of **incorrect** code for `/* exported variableName */` operation:
 ```js
 /* exported global_var */
 
-// Not respected, use ES6 modules instead.
+// Not respected, use ES modules instead.
 var global_var = 42;
 ```
 
diff --git a/src/docs/guide/usage/linter/rules/eslint/no-var.md b/src/docs/guide/usage/linter/rules/eslint/no-var.md
@@ -15,14 +15,14 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin
 
 ### What it does
 
-ECMAScript 6 allows programmers to create variables with block scope
+ECMAScript 2015 allows programmers to create variables with block scope
 instead of function scope using the `let` and `const` keywords. Block
 scope is common in many other programming languages and helps
 programmers avoid mistakes.
 
 ### Why is this bad?
 
-Using `var` in an es6 environment triggers this error
+Using `var` in an ES2015 environment triggers this error
 
 ### 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
@@ -19,7 +19,7 @@ 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,
+With JavaScript ES2015, 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.
 
diff --git a/src/docs/guide/usage/linter/rules/eslint/prefer-numeric-literals.md b/src/docs/guide/usage/linter/rules/eslint/prefer-numeric-literals.md
@@ -22,7 +22,7 @@ literals.
 
 The parseInt() and Number.parseInt() functions can be used to turn binary, octal, and
 hexadecimal strings into integers. As binary, octal, and hexadecimal literals are supported
-in ES6, this rule encourages use of those numeric literals instead of parseInt() or
+in ES2015, this rule encourages use of those numeric literals instead of parseInt() or
 Number.parseInt().
 
 ### Examples
diff --git a/src/docs/guide/usage/linter/rules/eslint/use-isnan.md b/src/docs/guide/usage/linter/rules/eslint/use-isnan.md
@@ -18,7 +18,7 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin
 
 ### What it does
 
-Disallows checking against NaN without using isNaN() call.
+Disallows checking against NaN without using `isNaN()` call.
 
 ### Why is this bad?
 
@@ -30,10 +30,10 @@ for Binary Floating-Point Arithmetic.
 Because NaN is unique in JavaScript by not being equal to anything, including itself,
 the results of comparisons to NaN are confusing:
 
-- NaN === NaN or NaN == NaN evaluate to false
-- NaN !== NaN or NaN != NaN evaluate to true
+- `NaN === NaN` or `NaN == NaN` evaluate to false
+- `NaN !== NaN` or `NaN != NaN` evaluate to true
 
-Therefore, use Number.isNaN() or global isNaN() functions to test whether a value is NaN.
+Therefore, use `Number.isNaN()` or global `isNaN()` functions to test whether a value is NaN.
 
 ### Examples
 
diff --git a/src/docs/guide/usage/linter/rules/import/named.md b/src/docs/guide/usage/linter/rules/import/named.md
@@ -50,7 +50,7 @@ Examples of **incorrect** code for this rule:
 // ./baz.js
 import { notFoo } from "./foo";
 
-// ES7 proposal
+// re-export
 export { notFoo as defNotBar } from "./foo";
 
 // will follow 'jsnext:main', if available
@@ -63,7 +63,7 @@ Examples of **correct** code for this rule:
 // ./bar.js
 import { foo } from "./foo";
 
-// ES7 proposal
+// re-export
 export { foo as bar } from "./foo";
 
 // node_modules without jsnext:main are not analyzed by default
diff --git a/src/docs/guide/usage/linter/rules/import/no-absolute-path.md b/src/docs/guide/usage/linter/rules/import/no-absolute-path.md
@@ -98,7 +98,7 @@ type: `boolean`
 
 default: `true`
 
-If set to `true`, dependency paths for ES6-style import statements will be resolved:
+If set to `true`, dependency paths for ES module import statements will be resolved:
 
 ```js
 import foo from "/foo"; // reported
diff --git a/src/docs/guide/usage/linter/rules/import/no-amd.md b/src/docs/guide/usage/linter/rules/import/no-amd.md
@@ -18,7 +18,7 @@ Forbids the use of AMD `require` and `define` calls.
 
 AMD (Asynchronous Module Definition) is an older module format
 that is less common in modern JavaScript development, especially
-with the widespread use of ES6 modules and CommonJS in Node.js.
+with the widespread use of ES modules and CommonJS in Node.js.
 AMD introduces unnecessary complexity and is often considered outdated.
 This rule enforces the use of more modern module systems to improve
 maintainability and consistency across the codebase.
diff --git a/src/docs/guide/usage/linter/rules/import/no-unassigned-import.md b/src/docs/guide/usage/linter/rules/import/no-unassigned-import.md
@@ -16,7 +16,7 @@ This rule aims to remove modules with side-effects by reporting when a module is
 
 ### Why is this bad?
 
-With both CommonJS' require and the ES6 modules' import syntax,
+With both CommonJS' require and the ES modules' import syntax,
 it is possible to import a module but not to use its result.
 This can be done explicitly by not assigning the module to a variable.
 Doing so can mean either of the following things:
diff --git a/src/docs/guide/usage/linter/rules/jsdoc/implements-on-classes.md b/src/docs/guide/usage/linter/rules/jsdoc/implements-on-classes.md
@@ -17,7 +17,7 @@ Reports an issue with any non-constructor function using `@implements`.
 ### Why is this bad?
 
 Constructor functions should be
-whether marked with `@class`, `@constructs`, or being an ES6 class constructor.
+whether marked with `@class`, `@constructs`, or being a class constructor.
 
 ### Examples
 
diff --git a/src/docs/guide/usage/linter/rules/jsdoc/no-defaults.md b/src/docs/guide/usage/linter/rules/jsdoc/no-defaults.md
@@ -18,7 +18,7 @@ It also optionally reports the presence of the square-bracketed optional argumen
 ### Why is this bad?
 
 The rule is intended to prevent the indication of defaults on tags
-where this would be redundant with ES6 default parameters.
+where this would be redundant with ES2015 default parameters.
 
 ### Examples
 
diff --git a/src/docs/guide/usage/linter/rules/react/no-is-mounted.md b/src/docs/guide/usage/linter/rules/react/no-is-mounted.md
@@ -12,11 +12,11 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin
 
 ### What it does
 
-This rule prevents using isMounted in ES6 classes
+This rule prevents using isMounted in classes
 
 ### Why is this bad?
 
-isMounted is an anti-pattern, is not available when using ES6 classes,
+isMounted is an anti-pattern, is not available when using classes,
 and it is on its way to being officially deprecated.///
 
 ### Examples
diff --git a/src/docs/guide/usage/linter/rules/react/prefer-es6-class.md b/src/docs/guide/usage/linter/rules/react/prefer-es6-class.md
@@ -13,7 +13,7 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin
 ### What it does
 
 React offers you two ways to create traditional components: using the ES5
-create-react-class module or the new ES6 class system.
+create-react-class module or the new ES2015 class system.
 
 ### Why is this bad?
 
diff --git a/src/docs/guide/usage/linter/rules/react/require-render-return.md b/src/docs/guide/usage/linter/rules/react/require-render-return.md
@@ -12,7 +12,7 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin
 
 ### What it does
 
-Enforce ES5 or ES6 class for returning value in render function
+Enforce ES5 or ES2015 class for returning value in render function
 
 ### Why is this bad?
 
diff --git a/src/docs/guide/usage/linter/rules/typescript/no-this-alias.md b/src/docs/guide/usage/linter/rules/typescript/no-this-alias.md
@@ -19,7 +19,7 @@ Disallow aliasing `this`
 
 ### Why is this bad?
 
-Assigning a variable to `this` instead of properly using arrow lambdas may be a symptom of pre-ES6 practices or not managing scope well.
+Assigning a variable to `this` instead of properly using arrow lambdas may be a symptom of pre-ES2015 practices or not managing scope well.
 
 ## Configuration
 
diff --git a/src/docs/guide/usage/linter/rules/typescript/no-var-requires.md b/src/docs/guide/usage/linter/rules/typescript/no-var-requires.md
@@ -16,7 +16,7 @@ Disallow `require` statements except in import statements
 
 ### Why is this bad?
 
-In other words, the use of forms such as var foo = require("foo") are banned. Instead use ES6 style imports or import foo = require("foo") imports.
+In other words, the use of forms such as var foo = require("foo") are banned. Instead use ES module imports or import foo = require("foo") imports.
 
 ```typescript
 var foo = require("foo");
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
@@ -15,7 +15,7 @@ const source = `https://github.com/oxc-project/oxc/blob/${ data }/crates/oxc_lin
 
 ### What it does
 
-Disallow certain triple slash directives in favor of ES6-style import declarations.
+Disallow certain triple slash directives in favor of ES module import declarations.
 
 ### Why is this bad?
 
diff --git a/src/docs/guide/usage/linter/rules/version.data.js b/src/docs/guide/usage/linter/rules/version.data.js
@@ -1,5 +1,5 @@
 export default {
   load() {
-    return "9a0c4ec6aa91615b41d80bea43c2da0a28f1f7f1";
+    return "32510006dd5be07faf8423035c5be43382c373a3";
   },
 };
