迁移到 v9.x

ESLint v9.0.0 是 ESLint 的一个主要版本，因此，有一些您需要注意的重大更改。本指南旨在引导您了解这些重大更改。

下面的列表大致按预计每个更改影响的用户数量排序，其中第一个项目预计影响的用户最多。

不再支持 Node.js < v18.18, v19
新的默认配置格式 (eslint.config.js)
移除了多个格式化器
移除了 require-jsdoc 和 valid-jsdoc 规则
eslint:recommended 已更新
--quiet 不再运行设置为 "warn" 的规则
--output-file 现在即使输出为空也会写入文件到磁盘
当没有模式传递给 CLI 时，行为发生变化
仅包含严重程度的 /* eslint */ 注释现在保留配置文件中的选项
现在不允许对同一规则使用多个 /* eslint */ 注释
更严格的 /* exported */ 解析
no-constructor-return 和 no-sequences 规则模式更严格
默认情况下，no-implicit-coercion 中新增检查
no-invalid-regexp 中的大小写敏感标志
no-unused-vars 的 varsIgnorePattern 选项不再适用于 catch 参数
no-restricted-imports 现在接受具有相同 name 的多个配置条目
扁平配置中不再接受 "eslint:recommended" 和 "eslint:all" 字符串
no-inner-declarations 具有新的默认行为和一个新选项
no-unused-vars 现在默认将 caughtErrors 设置为 "all"
no-useless-computed-key 默认情况下标记类中不必要的计算成员名称
camelcase allow 选项仅接受字符串数组

集成开发者的重大更改

不再支持 Node.js < v18.18, v19
FlatESLint 现在是 ESLint
Linter 现在期望扁平配置格式

不再支持 Node.js < v18.18, v19

从 ESLint v9.0.0 开始，ESLint 官方放弃对这些 Node.js 版本的支持。ESLint 现在支持以下 Node.js 版本

Node.js v18.18.0 及以上
Node.js v20.9.0 及以上
Node.js v21 及以上

要解决： 当使用 ESLint v9.0.0 时，请确保您升级到至少 Node.js v18.18.0。一个需要仔细检查的重要事项是当通过编辑器集成使用 ESLint 时，您的编辑器所支持的 Node.js 版本。如果您无法升级，我们建议继续使用 ESLint v8.56.0，直到您可以升级 Node.js。

相关 issue： #17595

新的默认配置格式 (`eslint.config.js`)

正如我们在博客文章中宣布的那样，在 ESLint v9.0.0 中，eslint.config.js 是新的默认配置格式。之前的格式 eslintrc 现在已被弃用，将不会自动搜索。

要解决： 按照配置迁移指南将您的配置更新为新格式。如果您仍然需要使用已弃用的 eslintrc 配置格式，请将环境变量 ESLINT_USE_FLAT_CONFIG 设置为 false。

相关 issue： #13481

移除了多个格式化器

ESLint v9.0.0 已从核心中移除以下格式化器

移除的格式化器	替代 npm 包
`checkstyle`	`eslint-formatter-checkstyle`
`compact`	`eslint-formatter-compact`
`jslint-xml`	`eslint-formatter-jslint-xml`
`junit`	`eslint-formatter-junit`
`tap`	`eslint-formatter-tap`
`unix`	`eslint-formatter-unix`
`visualstudio`	`eslint-formatter-visualstudio`

要解决： 如果您通过 -f 命令行标志使用这些格式化器中的任何一个，您需要安装格式化器的相应包。

相关 issue： #17524

移除了 `require-jsdoc` 和 `valid-jsdoc` 规则

require-jsdoc 和 valid-jsdoc 规则已在 ESLint v9.0.0 中移除。这些规则最初在 2018 年被弃用。

要解决： 使用 eslint-plugin-jsdoc 中的替代规则。

相关 issue： #15820

`eslint:recommended` 已更新

eslint:recommended 中启用了四个新规则

此外，以下规则已从 eslint:recommended 中移除

要解决： 修复错误或禁用这些规则。

相关 issue： #15576, #17446, #17596

`--quiet` 不再运行设置为 `"warn"` 的规则

在 ESLint v9.0.0 之前，--quiet CLI 标志会运行所有设置为 "error" 或 "warn" 的规则，然后隐藏设置为 "warn" 的规则的结果。在 ESLint v9.0.0 中，当设置为 "warn" 时，--quiet 将阻止规则执行。这可以提高包含许多设置为 "warn" 的规则的配置的性能。

如果使用了 --max-warnings，则 --quiet 不会阻止设置为 "warn" 的规则的执行，但会抑制这些规则的输出。

要解决： 在大多数情况下，此更改是透明的。但是，如果您运行设置为 "warn" 的规则，该规则会更改可供其他规则使用的数据（例如，如果该规则使用 sourceCode.markVariableAsUsed()），则这可能会导致行为更改。在这种情况下，您需要将规则设置为 "error" 或停止使用 --quiet。

相关 issue： #16450

`--output-file` 现在即使输出为空也会写入文件到磁盘

在 ESLint v9.0.0 之前，如果输出为空，--output-file 标志会跳过将文件写入磁盘。但是，在 ESLint v9.0.0 中，--output-file 现在始终如一地将文件写入磁盘，即使输出为空也是如此。此更新确保了 --output-file 更一致和可靠的行为。

要解决： 检查您对 --output-file 标志的使用情况，特别是如果您的流程依赖于文件的存在或不存在（基于输出内容）。如有必要，请更新您的脚本或配置以适应此更改。

相关 issue： #17660

当没有模式传递给 CLI 时，行为发生变化

在 ESLint v9.0.0 之前，在没有任何文件或目录模式的情况下运行 ESLint CLI 将导致没有文件被 lint，并且会以代码 0 退出。这令人困惑，因为不清楚实际上什么都没有发生。在 ESLint v9.0.0 中，此行为已更新

扁平配置。 如果您正在使用扁平配置，您可以运行 npx eslint 或 eslint（如果全局安装），ESLint 将假定您要 lint 当前目录。实际上，不传递任何模式等同于传递 .。
eslintrc。 如果您正在使用已弃用的 eslintrc 配置，当您在没有任何模式的情况下运行 CLI 时，您现在将收到一个错误。

要解决： 在大多数情况下，无需更改，您可能会发现一些您认为 ESLint 正在运行但实际上并没有运行的位置。如果您想保留 v8.x 的行为，即不传递任何模式会导致 ESLint 以代码 0 退出，请将 --pass-on-no-patterns 标志添加到 CLI 调用中。

相关 issue： #14308

仅包含严重程度的 `/* eslint */` 注释现在保留配置文件中的选项

在 ESLint v9.0.0 之前，配置注释（例如 /* eslint curly: "warn" */ 或 /* eslint curly: ["warn"] */）将完全覆盖配置文件中为该规则指定的任何配置，从而强制执行该规则的默认选项。

在 ESLint v9.0.0 中，配置注释的行为与配置文件中规则配置的合并方式对齐，这意味着仅包含严重程度的配置注释现在保留配置文件中指定的选项，并且仅覆盖严重程度。

例如，如果您有以下配置文件

// eslint.config.js

export default [{
    rules: {
        curly: ["error", "multi"]
    }
}];
1
2
3
4
5
6
7

和以下配置注释

// my-file.js

/* eslint curly: "warn" */
1
2
3

当 lint my-file.js 时，curly 规则的最终配置将是 curly: ["warn", "multi"]。

请注意，此更改仅影响在配置文件中使用选项配置了相同规则，并使用不带选项的配置注释的情况。在所有其他情况下（例如，规则仅使用配置注释配置），行为与 ESLint v9.0.0 之前的行为保持相同。

要解决： 我们预计在大多数情况下无需更改，因为使用配置注释配置的规则通常尚未在配置文件中配置。但是，如果您需要配置注释完全覆盖来自配置文件的配置并强制执行默认选项，则需要至少指定一个选项

// my-file.js

/* eslint curly: ["warn", "all"] */
1
2
3

相关 issue： #17381

现在不允许对同一规则使用多个 `/* eslint */` 注释

在 ESLint v9.0.0 之前，如果正在 lint 的文件包含对同一规则的多个 /* eslint */ 配置注释，则将应用最后一个，而其他注释将被静默忽略。例如

/* eslint semi: ["error", "always"] */
/* eslint semi: ["error", "never"] */

foo() // valid, because the configuration is "never"
1
2
3
4

在 ESLint v9.0.0 中，将应用第一个，而其他注释将报告为 lint 错误

/* eslint semi: ["error", "always"] */
/* eslint semi: ["error", "never"] */ // error: Rule "semi" is already configured by another configuration comment in the preceding code. This configuration is ignored.

foo() // error: Missing semicolon
1
2
3
4

要解决： 删除重复的 /* eslint */ 注释。

相关 issue： #18132

更严格的 `/* exported */` 解析

在 ESLint v9.0.0 之前，/* exported */ 指令错误地允许以下语法

/* exported foo: true, bar: false */

// and

/* exported foo bar */
1
2
3
4
5

此示例中的 true 和 false 对 ESLint 的行为没有影响，实际上是一个解析错误。

在 ESLint v9.0.0 中，任何后跟冒号和值的 /* exported */ 变量都将被忽略为无效。

要解决： 更新任何 /* exported */ 指令以消除冒号和后续值，并确保变量名之间有逗号，例如

/* exported foo, bar */
1

相关 issue： #17622

`no-constructor-return` 和 `no-sequences` 规则模式更严格

在以前版本的 ESLint 中，no-constructor-return 和 no-sequences 规则错误地接受了无效选项。

这已在 ESLint v9.0.0 中修复

no-constructor-return 规则不接受任何选项。
no-sequences 规则可以接受一个选项，即具有属性 "allowInParentheses" (boolean) 的对象。

{
    "rules": {
        "no-constructor-return": ["error"],
        "no-sequences": ["error", { "allowInParentheses": false }]
    }
}
1
2
3
4
5
6

要解决： 如果 ESLint 报告任何这些规则的无效配置，请更新您的配置。

相关 issue： #16879

默认情况下，`no-implicit-coercion` 中新增检查

在 ESLint v9.0.0 中，默认情况下，no-implicit-coercion 规则还会报告以下情况

-(-foo);
foo - 0;
1
2

要解决： 如果您想保留此规则之前的行为，请设置 "allow": ["-", "- -"]。

{
    "rules": {
        "no-implicit-coercion": [2, { "allow": ["-", "- -"] } ],
    }
}
1
2
3
4
5

相关 issue： #17832

`no-invalid-regexp` 中的大小写敏感标志

在 ESLint v9.0.0 中，选项 allowConstructorFlags 现在是大小写敏感的。

要解决： 如果需要，请更新您的配置。

相关 issue： #16574

`no-unused-vars` 的 `varsIgnorePattern` 选项不再适用于 catch 参数

在以前版本的 ESLint 中，no-unused-vars 的 varsIgnorePattern 选项错误地忽略了 catch 子句中指定的错误。在 ESLint v9.0.0 中，varsIgnorePattern 不再适用于 catch 子句中的错误。例如

/*eslint no-unused-vars: ["error", { "caughtErrors": "all", "varsIgnorePattern": "^err" }]*/

try {
    //...
} catch (err) { // 'err' will be reported.
    console.error("errors");
}

1
2
3
4
5
6
7
8

要解决： 如果您想为 catch 子句变量名指定忽略模式，请除了 varsIgnorePattern 之外，还使用 caughtErrorsIgnorePattern 选项。

相关 issue： #17540

`no-restricted-imports` 现在接受具有相同 `name` 的多个配置条目

在以前版本的 ESLint 中，如果 no-restricted-imports 规则的配置的 paths 数组中的多个条目具有相同的 name 属性，则只会应用最后一个，而之前的条目将被忽略。

从 ESLint v9.0.0 开始，所有条目都适用，允许为不同的导入名称指定不同的消息。例如，您现在可以像这样配置规则

{
    rules: {
        "no-restricted-imports": ["error", {
            paths: [
                {
                    name: "react-native",
                    importNames: ["Text"],
                    message: "import 'Text' from 'ui/_components' instead"
                },
                {
                    name: "react-native",
                    importNames: ["View"],
                    message: "import 'View' from 'ui/_components' instead"
                }
            ]
        }]
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

import { Text } from "react-native" 和 import { View } from "react-native" 都将被报告，并带有不同的消息。

在以前版本的 ESLint 中，使用此配置只会报告 import { View } from "react-native"。

要解决： 如果您的此规则配置具有多个具有相同 name 的条目，您可能需要删除意外的条目。

相关 issue： #15261

扁平配置中不再接受 `"eslint:recommended"` 和 `"eslint:all"`

在 ESLint v8.x 中，eslint.config.js 可以通过将字符串插入配置数组来引用 "eslint:recommended" 和 "eslint:all" 配置，如下例所示

// eslint.config.js
export default [
    "eslint:recommended",
    "eslint:all"
];
1
2
3
4
5

在 ESLint v9.0.0 中，不再支持此格式，并且会导致错误。

要解决： 请改用 @eslint/js 包

// eslint.config.js
import js from "@eslint/js";

export default [
    js.configs.recommended,
    js.configs.all
];
1
2
3
4
5
6
7

相关 issue： #17488

`no-inner-declarations` 具有新的默认行为和一个新选项

ESLint v9.0.0 在 no-inner-declarations 规则中引入了一个名为 blockScopeFunctions 的新选项，默认情况下，当 languageOptions.ecmaVersion 设置为 2015 或更高版本时，该选项允许块级 function 在严格模式下使用。

/*eslint no-inner-declarations: "error"*/
"use strict";

if (test) {
    function foo () { }  // no error
}
1
2
3
4
5
6

要解决： 如果您想在每种情况下都报告块级 function，而不管是否为严格模式，请将 blockScopeFunctions 选项设置为 "disallow"。

相关 issue： #15576

`no-unused-vars` 现在默认将 `caughtErrors` 设置为 `"all"`

ESLint v9.0.0 更改了 no-unused-vars 规则的 caughtErrors 选项的默认值。以前，它默认为 "none"，从不检查捕获的错误是否被使用。现在，它默认为 "all"，以检查捕获的错误是否被使用。

/*eslint no-unused-vars: "error"*/
try {}
catch (error) {
    // 'error' is defined but never used
}
1
2
3
4
5

要解决： 如果您想允许未使用的捕获错误，例如在编写将直接在不支持 ES2019 可选 catch 绑定的环境中运行的代码时，请将 caughtErrors 选项设置为 "none"。否则，请删除未使用的捕获错误。

/*eslint no-unused-vars: "error"*/
try {}
catch {
    // no error
}
1
2
3
4
5

相关 issue： #17974

`no-useless-computed-key` 默认情况下标记类中不必要的计算成员名称

在 ESLint v9.0.0 中，no-useless-computed-key 规则的 enforceForClassMembers 选项的默认值从 false 更改为 true。此更改的效果是，默认情况下，类中不必要的计算成员名称将被标记。

/*eslint no-useless-computed-key: "error"*/

class SomeClass {
    ["someMethod"]() {} // ok in ESLint v8, error in ESLint v9.
}
1
2
3
4
5

要解决： 修复规则报告的问题，或通过将 enforceForClassMembers 选项设置为 false 来恢复到之前的行为。

相关 issue： #18042

`camelcase` allow 选项仅接受字符串数组

以前，camelcase 规则没有强制 allow 选项必须是字符串数组。在 ESLint v9.0.0 中，allow 选项现在仅接受字符串数组。

要解决： 如果 ESLint 报告此规则的无效配置，请更新您的配置。

相关 issue： #18232

移除了多个 `context` 方法

ESLint v9.0.0 从 context 对象中移除了多个已弃用的方法，并将它们移动到 SourceCode 对象上

在 `context` 上移除	在 `SourceCode` 上的替代方法
`context.getSource()`	`sourceCode.getText()`
`context.getSourceLines()`	`sourceCode.getLines()`
`context.getAllComments()`	`sourceCode.getAllComments()`
`context.getNodeByRangeIndex()`	`sourceCode.getNodeByRangeIndex()`
`context.getComments()`	`sourceCode.getCommentsBefore()`, `sourceCode.getCommentsAfter()`, `sourceCode.getCommentsInside()`
`context.getCommentsBefore()`	`sourceCode.getCommentsBefore()`
`context.getCommentsAfter()`	`sourceCode.getCommentsAfter()`
`context.getCommentsInside()`	`sourceCode.getCommentsInside()`
`context.getJSDocComment()`	`sourceCode.getJSDocComment()`
`context.getFirstToken()`	`sourceCode.getFirstToken()`
`context.getFirstTokens()`	`sourceCode.getFirstTokens()`
`context.getLastToken()`	`sourceCode.getLastToken()`
`context.getLastTokens()`	`sourceCode.getLastTokens()`
`context.getTokenAfter()`	`sourceCode.getTokenAfter()`
`context.getTokenBefore()`	`sourceCode.getTokenBefore()`
`context.getTokenByRangeStart()`	`sourceCode.getTokenByRangeStart()`
`context.getTokens()`	`sourceCode.getTokens()`
`context.getTokensAfter()`	`sourceCode.getTokensAfter()`
`context.getTokensBefore()`	`sourceCode.getTokensBefore()`
`context.getTokensBetween()`	`sourceCode.getTokensBetween()`
`context.parserServices`	`sourceCode.parserServices`
`context.getDeclaredVariables()`	`sourceCode.getDeclaredVariables()`

除了上表中的方法外，还有一些其他方法也被移动，但需要不同的方法签名

在 `context` 上移除	在 `SourceCode` 上的替代方法
`context.getAncestors()`	`sourceCode.getAncestors(node)`
`context.getScope()`	`sourceCode.getScope(node)`
`context.markVariableAsUsed(name)`	`sourceCode.markVariableAsUsed(name, node)`

要解决： 使用博客文章中推荐的自动化升级工具。

相关 issue： #16999, #13481

移除了 `sourceCode.getComments()`

ESLint v9.0.0 移除了已弃用的 sourceCode.getComments() 方法。

要解决： 替换为 sourceCode.getCommentsBefore(), sourceCode.getCommentsAfter(), 或 sourceCode.getCommentsInside()。

相关 issue： #14744

移除了 `CodePath#currentSegments`

ESLint v9.0.0 移除了已弃用的 CodePath#currentSegments 属性。

要解决： 按照博客文章中的建议更新您的代码。

相关 issue： #17457

代码路径现在是预先计算的

在 ESLint v9.0.0 之前，代码路径是在规则使用的相同 AST 遍历期间计算的，这意味着传递给诸如 onCodePathStart 和 onCodePathSegmentStart 等方法的信息是不完整的。具体来说，诸如 CodePath#childCodePaths 和 CodePathSegment#nextSegments 等数组属性开始时为空，然后在遍历完成时填充适当的信息，这意味着这些数组可能具有不同的元素，具体取决于您何时检查它们的值。

ESLint v9.0.0 现在在规则使用的遍历之前预先计算代码路径信息。因此，无论代码路径信息在规则内部的何处被访问，它现在都是完整的。

要解决： 如果您正在访问 CodePath 或 CodePathSegment 上的任何数组属性，您需要更新您的代码。具体来说

如果您正在检查任何数组属性的 length，请确保您正在使用相对比较运算符（如 <, >, <=, 和 >=）而不是等于。
如果您正在访问 CodePathSegment 上的 nextSegments, prevSegments, allNextSegments, 或 allPrevSegments 属性，或 CodePath#childCodePaths，请验证您的代码是否仍然按预期工作。为了向后兼容，请考虑将检查这些属性的逻辑移动到 onCodePathEnd 中。

相关 issue： #16999

不再支持函数式规则

ESLint v9.0.0 放弃了对函数式规则的支持。函数式规则是通过导出函数而不是具有 create() 方法的对象来创建的规则。此规则格式在 2016 年已被弃用。

要解决： 将您的规则更新为最新的规则格式。对于用 CommonJS 编写的规则，您还可以使用 eslint-transforms。

eslint-plugin/prefer-object-rule 规则可以帮助强制使用对象式规则，并自动修复任何剩余的函数式规则。

相关 issue： #14709

对于带有选项的规则，`meta.schema` 是必需的

从 ESLint v9.0.0 开始，如果任何选项传递给未指定 meta.schema 属性的规则，将会抛出一个错误。

要解决

如果您的规则期望选项，请将 meta.schema 属性设置为规则选项的 JSON Schema 格式描述。此模式将由 ESLint 用于验证配置的选项，并防止规则的无效或意外输入。
如果您的规则不期望任何选项，则无需执行任何操作。此更改确保最终用户不会错误地为不期望选项的规则配置选项。
（不推荐） 您也可以将 meta.schema 设置为 false 以禁用此验证，但强烈建议如果规则期望选项则提供模式，如果规则不期望选项则省略模式（或设置为 []），以便 ESLint 可以确保用户的配置有效。

eslint-plugin/require-meta-schema 规则可以帮助强制要求规则在需要时具有模式。

相关 issue： #14709

`FlatRuleTester` 现在是 `RuleTester`

正如我们在博客文章中宣布的那样，临时的 FlatRuleTester 类已重命名为 RuleTester，而 v8.x 中的 RuleTester 类已被移除。此外，来自 eslint/use-at-your-own-risk 的 FlatRuleTester 导出也已被移除。

需要解决： 更新你的规则测试以使用新的 RuleTester。为此，你需要进行以下一些常见更改：

注意 ecmaVersion 和 sourceType 的新默认值。 默认情况下，RuleTester 使用扁平配置的默认值 ecmaVersion: "latest" 和 sourceType: "module"。如果某些测试预期旧的默认值 ecmaVersion: 5 和 sourceType: "script"，则可能会导致这些测试失败。如果你想使用旧的默认值，你需要像这样在你的 RuleTester 中手动指定：
```
// use eslintrc defaults
const ruleTester = new RuleTester({
    languageOptions: {
        ecmaVersion: 5,
        sourceType: "script"
    }
});
1
2
3
4
5
6
7
```

将 parserOptions 更改为 languageOptions。 如果你在测试中设置了 ecmaVersion 或 sourceType，请将它们从 parserOptions 移动到 languageOptions，就像这样：

ruleTester.run("my-rule", myRule, {
    valid: [
        {
            code: "foo",
            parserOptions: {
                ecmaVersion: 6
            }
        }
    ]
});

// becomes

ruleTester.run("my-rule", myRule, {
    valid: [
        {
            code: "foo",
            languageOptions: {
                ecmaVersion: 6
            }
        }
    ]
});
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

转换其他配置键。 曾经在 eslintrc 配置系统上运行的键（例如 env 和 parser）必须转换为扁平配置系统。有关转换你可能正在使用的其他键的详细信息，请参阅配置迁移指南。

相关 issue： #13481

更严格的 `RuleTester` 检查

为了帮助开发高质量的自定义规则，使其免受常见错误的影响，ESLint v9.0.0 对 RuleTester 实施了多项更改：

测试用例的 output 必须与 code 不同。 在 ESLint v8.x 中，如果 output 与 code 相同，则断言没有自动修复。在查看测试用例时，并不总是立即清楚 output 是否与 code 不同，特别是当字符串更长或多行时，这使得开发人员难以确定测试用例是否期望自动修复。在 ESLint v9.0.0 中，为了避免这种歧义，如果测试 output 与测试 code 具有相同的值，RuleTester 现在会抛出错误。因此，指定 output 现在必然意味着测试用例期望自动修复并断言其结果。如果测试用例不期望自动修复，请省略 output 属性或将其设置为 null。这会断言没有自动修复。
测试错误对象必须指定 message 或 messageId。 为了提高测试覆盖率的质量，如果测试错误对象上既未指定 message 也未指定 messageId，RuleTester 现在会抛出错误。
如果实际错误提供了建议，则测试错误对象必须指定 suggestions。 在 ESLint v8.x 中，如果从测试错误对象中省略了 suggestions 属性，则 RuleTester 不会对建议执行任何检查，因此很容易忘记断言测试用例是否产生建议。在 ESLint v9.0.0 中，省略 suggestions 属性会断言实际错误不提供建议，而如果实际错误确实提供建议，则需要指定 suggestions 属性。我们强烈建议你通过指定测试建议对象数组来详细测试建议，但你也可以指定 suggestions: <number> 来仅断言建议的数量。
测试建议对象必须指定 output。 为了提高测试覆盖率的质量，如果测试建议对象上未指定 output 属性，RuleTester 现在会抛出错误。
测试建议对象必须指定 desc 或 messageId。 为了提高测试覆盖率的质量，如果测试建议对象上既未指定 desc 也未指定 messageId 属性，RuleTester 现在会抛出错误。也不允许同时指定两者。如果除了 messageId 之外，你还想断言建议描述文本，那么还要添加 data 属性。
建议消息必须是唯一的。 由于建议通常在编辑器中显示为下拉列表，因此对于同一 lint 问题的任何两个建议都具有相同的消息非常重要。否则，不可能知道任何给定建议将做什么。此附加检查会自动运行。
建议必须更改代码。 建议应通过更改代码来修复报告的问题。如果建议测试的 output 与测试的 code 相同，RuleTester 现在会抛出错误。
建议必须生成有效的语法。 为了使规则建议有用，它们需要是有效的语法。RuleTester 现在使用与 code 值相同的语言选项解析建议的输出，如果解析失败，则抛出错误。
测试用例必须是唯一的。 相同的测试用例可能会引起混淆，并且在长测试文件中很难手动检测到。重复项现在会自动检测到，并且可以安全地删除。
filename 和 only 必须是预期的类型。 RuleTester 现在检查测试对象的 filename 和 only 属性的类型。如果指定，filename 必须是字符串值。如果指定，only 必须是布尔值。
消息不能有未替换的占位符。 RuleTester 现在还会检查消息中是否仍有 {{ placeholder }}，因为它们的值未通过各自的 context.report() 调用中的 data 传递。

需要解决： 使用 RuleTester 运行你的规则测试，并修复发生的任何错误。你需要进行的更改以满足 RuleTester 与 ESLint v8.x 兼容。

相关问题： #15104, #15735, #16908, #18016

`FlatESLint` 现在是 `ESLint`

正如我们在博客文章中宣布的那样，临时的 FlatESLint 类已重命名为 ESLint，而 v8.x 中的 ESLint 类已重命名为 LegacyESLint。

需要解决： 如果你当前正在使用 ESLint 类，请验证你的测试是否使用新的 ESLint 类通过。并非所有旧选项都受支持，因此你可能需要更新传递给构造函数的参数。有关详细信息，请参阅Node.js API 参考。

如果你仍然需要 v8.x ESLint 功能，请像这样使用 LegacyESLint 类：

const { LegacyESLint } = require("eslint/use-at-your-own-risk");
1

相关 issue： #13481

`Linter` 现在期望扁平配置格式

在 ESLint v9.0.0 中，传递给 Linter#verify() 和 Linter#verifyAndFix() 方法的 config 参数应为扁平配置格式。

此外，方法 Linter#defineRule()、Linter#defineRules()、Linter#defineParser() 和 Linter#getRules() 不再可用。

需要解决： 如果你正在使用 Linter 类，请验证你的测试是否通过。

如果你传递的配置对象与扁平配置格式不兼容，则需要更新代码。

// eslintrc config format
linter.verify(code, {
    parserOptions: {
        ecmaVersion: 6
    }
});

// flat config format
linter.verify(code, {
    languageOptions: {
        ecmaVersion: 6
    }
});
1
2
3
4
5
6
7
8
9
10
11
12
13

有关转换你可能正在使用的其他键的详细信息，请参阅配置迁移指南。

规则和解析器可以直接在配置中定义。

// eslintrc mode
linter.defineRule("my-rule1", myRule1);
linter.defineRules({
    "my-rule2": myRule2,
    "my-rule3": myRule3
});
linter.defineParser("my-parser", myParser);
linter.verify(code, {
    rules: {
        "my-rule1": "error",
        "my-rule2": "error",
        "my-rule3": "error"
    },
    parser: "my-parser"
});

// flat config mode
linter.verify(code, {
    plugins: {
        "my-plugin-foo": {
            rules: {
                "my-rule1": myRule1
            }
        },
        "my-plugin-bar": {
            rules: {
                "my-rule2": myRule2,
                "my-rule3": myRule3
            }
        }
    },
    rules: {
        "my-plugin-foo/my-rule1": "error",
        "my-plugin-bar/my-rule2": "error",
        "my-plugin-bar/my-rule3": "error"
    },
    languageOptions: {
        parser: myParser
    }
});
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

如果你仍然需要 v8.x Linter 功能，请将 configType: "eslintrc" 传递给构造函数，如下所示：

const linter = new Linter({ configType: "eslintrc" });

linter.verify(code, {
    parserOptions: {
        ecmaVersion: 6
    }
});

linter.getRules();
1
2
3
4
5
6
7
8
9

相关 issue： #13481

编辑此页面

迁移到 v9.x

目录

用户的重大更改

插件开发者的重大更改

集成开发者的重大更改

不再支持 Node.js < v18.18, v19

新的默认配置格式 (eslint.config.js)

移除了多个格式化器

移除了 require-jsdoc 和 valid-jsdoc 规则

eslint:recommended 已更新

--quiet 不再运行设置为 "warn" 的规则

--output-file 现在即使输出为空也会写入文件到磁盘

当没有模式传递给 CLI 时，行为发生变化

仅包含严重程度的 /* eslint */ 注释现在保留配置文件中的选项

现在不允许对同一规则使用多个 /* eslint */ 注释

更严格的 /* exported */ 解析

no-constructor-return 和 no-sequences 规则模式更严格

默认情况下，no-implicit-coercion 中新增检查

no-invalid-regexp 中的大小写敏感标志

no-unused-vars 的 varsIgnorePattern 选项不再适用于 catch 参数

no-restricted-imports 现在接受具有相同 name 的多个配置条目

扁平配置中不再接受 "eslint:recommended" 和 "eslint:all"

no-inner-declarations 具有新的默认行为和一个新选项

no-unused-vars 现在默认将 caughtErrors 设置为 "all"

no-useless-computed-key 默认情况下标记类中不必要的计算成员名称

camelcase allow 选项仅接受字符串数组

移除了多个 context 方法

移除了 sourceCode.getComments()

移除了 CodePath#currentSegments

代码路径现在是预先计算的

不再支持函数式规则

对于带有选项的规则，meta.schema 是必需的

FlatRuleTester 现在是 RuleTester

更严格的 RuleTester 检查

FlatESLint 现在是 ESLint

Linter 现在期望扁平配置格式

新的默认配置格式 (`eslint.config.js`)

移除了 `require-jsdoc` 和 `valid-jsdoc` 规则

`eslint:recommended` 已更新

`--quiet` 不再运行设置为 `"warn"` 的规则

`--output-file` 现在即使输出为空也会写入文件到磁盘

仅包含严重程度的 `/* eslint */` 注释现在保留配置文件中的选项

现在不允许对同一规则使用多个 `/* eslint */` 注释

更严格的 `/* exported */` 解析

`no-constructor-return` 和 `no-sequences` 规则模式更严格

默认情况下，`no-implicit-coercion` 中新增检查

`no-invalid-regexp` 中的大小写敏感标志

`no-unused-vars` 的 `varsIgnorePattern` 选项不再适用于 catch 参数

`no-restricted-imports` 现在接受具有相同 `name` 的多个配置条目

扁平配置中不再接受 `"eslint:recommended"` 和 `"eslint:all"`

`no-inner-declarations` 具有新的默认行为和一个新选项

`no-unused-vars` 现在默认将 `caughtErrors` 设置为 `"all"`

`no-useless-computed-key` 默认情况下标记类中不必要的计算成员名称

`camelcase` allow 选项仅接受字符串数组

移除了多个 `context` 方法

移除了 `sourceCode.getComments()`

移除了 `CodePath#currentSegments`

对于带有选项的规则，`meta.schema` 是必需的

`FlatRuleTester` 现在是 `RuleTester`

更严格的 `RuleTester` 检查

`FlatESLint` 现在是 `ESLint`

`Linter` 现在期望扁平配置格式