迁移到 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。

相关问题(s)：#17595

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

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

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

相关问题(s)：#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 命令行标志使用其中任何一个格式化程序，则需要安装相应格式化程序的包。

相关问题(s)：#17524

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

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

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

相关问题(s)：#15820

`eslint:recommended` 已更新

eslint:recommended 中已启用四条新规则

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

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

相关问题(s)：#15576, #17446, #17596

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

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

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

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

相关问题(s)：#16450

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

在 ESLint v9.0.0 之前，--output-file 标志在输出为空时将跳过将文件写入磁盘。然而，在 ESLint v9.0.0 中，--output-file 现在始终将文件写入磁盘，即使输出为空。此更新确保 --output-file 的行为更加一致和可靠。

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

相关问题： #17660

未传递模式到 CLI 时行为变更

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

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

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

相关问题： #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

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

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

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

// my-file.js

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

相关问题： #17381

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

在 ESLint v9.0.0 之前，如果正在检查的文件包含针对同一个规则的多个 /* 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 */ 注释。

相关问题： #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

相关问题： #17622

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

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

此问题已在 ESLint v9.0.0 中修复。

no-constructor-return 规则不接受任何选项。
no-sequences 规则可以接受一个选项，该选项是一个包含属性 "allowInParentheses"（布尔值）的对象。

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

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

相关问题： #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

相关问题： #17832

`no-invalid-regexp` 中区分大小写的标志

在 ESLint v9.0.0 中，选项 allowConstructorFlags 现在区分大小写。

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

相关问题： #16574

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

在早期版本的 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 选项。

相关问题： #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 的条目，则您可能需要删除意外的条目。

相关问题： #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

相关问题： #17488

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

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

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

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

解决方法：如果您想在任何情况下（无论是否为严格模式）都报告块级 function，请将 blockScopeFunctions 选项设置为 "disallow"。

相关问题： #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 可选捕获绑定的环境中直接运行的代码时，请将 caughtErrors 选项设置为 "none"。否则，请删除未使用捕获的错误。

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

相关问题： #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 来恢复到之前的行为。

相关问题： #18042

`camelcase` 允许选项只接受字符串数组

以前，camelcase 规则不会强制执行 allow 选项为字符串数组。在 ESLint v9.0.0 中，allow 选项现在只接受字符串数组。

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

相关问题： #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)`

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

相关问题： #16999, #13481

删除了 `sourceCode.getComments()`

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

解决方法： 使用 sourceCode.getCommentsBefore()、sourceCode.getCommentsAfter() 或 sourceCode.getCommentsInside() 替代。

相关问题： #14744

删除了 `CodePath#currentSegments`

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

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

相关问题： #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。

相关问题： #16999

不再支持函数式规则

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

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

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

相关问题： #14709

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

从 ESLint v9.0.0 开始，如果对没有指定 meta.schema 属性的规则传递了任何选项，则会抛出错误。传递

解决方法

如果您的规则需要选项，请将 meta.schema 属性设置为规则选项的 JSON Schema 格式描述。ESLint 将使用此模式来验证配置的选项，并防止对您的规则进行无效或意外的输入。
如果您的规则不需要任何选项，则无需采取任何措施。此更改可确保最终用户不会错误地为不需要选项的规则配置选项。
（不建议） 您也可以将 meta.schema 设置为 false 来禁用此验证，但强烈建议您在规则需要选项时提供模式，并在规则不需要选项时省略模式（或设置为 []），以便 ESLint 可以确保用户配置的有效性。

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

相关问题： #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）必须翻译成扁平化配置系统。有关翻译您可能正在使用的其他键的详细信息，请参阅配置迁移指南。

相关问题(s)：#13481

严格的 `RuleTester` 检查

为了帮助开发高质量的自定义规则，这些规则没有常见的错误，ESLint v9.0.0 对 RuleTester 实施了一些更改

测试用例 output 必须与 code 不同。 在 ESLint v8.x 中，如果 output 与 code 相同，它会断言没有自动修复。当查看测试用例时，并不总是立即清楚 output 是否与 code 不同，尤其是当字符串很长或多行时，这使得开发人员难以确定测试用例是否期望自动修复。在 ESLint v9.0.0 中，为了避免这种歧义，RuleTester 现在在测试 output 与测试 code 具有相同值时抛出错误。因此，现在指定 output 必须意味着测试用例期望自动修复并断言其结果。如果测试用例不期望自动修复，请省略 output 属性或将其设置为 null。这会断言没有自动修复。
测试错误对象必须指定 message 或 messageId。 为了提高测试覆盖率的质量，RuleTester 现在在测试错误对象中没有指定 message 或 messageId 时抛出错误。
测试错误对象必须在实际错误提供建议时指定 suggestions。 在 ESLint v8.x 中，如果从测试错误对象中省略了 suggestions 属性，RuleTester 不会执行任何与建议相关的检查，因此很容易忘记断言测试用例是否会产生建议。在 ESLint v9.0.0 中，省略 suggestions 属性会断言实际错误不会提供建议，而如果实际错误确实提供建议，则需要指定 suggestions 属性。我们强烈建议您通过指定测试建议对象的数组来详细测试建议，但您也可以指定 suggestions: <number> 来断言建议的数量。
测试建议对象必须指定 output。 为了提高测试覆盖率的质量，RuleTester 现在在测试建议对象中未指定 output 属性时抛出错误。
测试建议对象必须指定 desc 或 messageId。 为了提高测试覆盖率的质量，RuleTester 现在在测试建议对象中没有指定 desc 或 messageId 属性时抛出错误。也不允许同时指定两者。如果除了 messageId 之外您还希望断言建议描述文本，那么请添加 data 属性。
建议消息必须是唯一的。 因为建议通常在编辑器中以下拉列表的形式显示，所以对于同一个 lint 问题，两个建议不应该有相同的消息。否则，就无法知道任何给定建议将做什么。此额外的检查会自动运行。
建议必须更改代码。 预计建议通过更改代码来修复报告的问题。RuleTester 现在在建议测试 output 与测试 code 相同时抛出错误。
建议必须生成有效的语法。 为了使规则建议有用，它们需要是有效的语法。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

相关问题(s)：#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

相关问题(s)：#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 选项不再适用于捕获参数

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

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

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

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

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

camelcase 允许选项只接受字符串数组

删除了多个 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` 选项不再适用于捕获参数

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

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

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

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

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

`camelcase` 允许选项只接受字符串数组

删除了多个 `context` 方法

删除了 `sourceCode.getComments()`

删除了 `CodePath#currentSegments`

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

`FlatRuleTester` 现在是 `RuleTester`

严格的 `RuleTester` 检查

`FlatESLint` 现在是 `ESLint`

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