迁移至 v10.x

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

🌐 ESLint v10.0.0 is a major release of ESLint, and as such, has several breaking changes that you need to be aware of. This guide is intended to walk you through the breaking changes.

为了帮助进行此迁移，ESLint 提供了迁移 codemods，以自动执行本指南中描述的许多更改。所有官方 ESLint codemods 都可以在 eslint/codemods 仓库及 Codemod Registry 中获得。

🌐 To help with this migration, ESLint provides migration codemods to automate many of the changes described in this guide. All official ESLint codemods are available in the eslint/codemods repository and through the Codemod Registry.

使用迁移代码修改工具

🌐 Use migration codemods

@eslint/v9-to-v10 codemod 将 ESLint 项目从 v9 升级到 v10。它包含四个可以独立运行的单独 codemod：

🌐 The @eslint/v9-to-v10 codemod upgrades ESLint projects from v9 to v10. It includes four individual codemods that can also be run independently:

@eslint/v9-to-v10-config：移除旧的环境变量和命令行选项
@eslint/v9-to-v10-custom-rules：替换已移除的 context 和 SourceCode 方法
@eslint/v9-to-v10-ruletester：清理 RuleTester 测试用例
@eslint/v9-to-v10-linter-api：修复 Linter/ESLint API 的使用

npx codemod @eslint/v9-to-v10
1

在 Codemod 注册表中了解更多信息。

🌐 Learn more in the Codemod Registry.

Codemods 是一个起点。请审核更改，并查看以下重大更改，以了解 codemods 未覆盖的内容。

🌐 Codemods are a starting point. Review the changes and consult the breaking changes below for anything the codemods do not cover.

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

🌐 The lists below are ordered roughly by the number of users each change is expected to affect, where the first items are expected to affect the most users.

Node.js < v20.19, v21, v23 不再受支持
eslint:recommended 已更新
新配置文件查找算法
旧配置格式不再支持
JSX 引用现在已被跟踪
eslint-env 评论被报告为错误
Jiti < v2.2.0 不再受支持
通配符模式中的 POSIX 字符类
stylish 格式化程序现在使用原生 styleText 替代 chalk
radix 规则的已弃用选项
no-shadow-restricted-names 现在默认报告 globalThis
func-names 架构更严格
no-invalid-regexp 的 allowConstructorFlags 选项现在仅接受唯一项 (#no-invalid-regexp)
name 属性已添加到 ESLint 核心配置

对插件开发者的重大更改

🌐 Breaking changes for plugin developers

Node.js < v20.19, v21, v23 不再受支持
旧配置格式不再支持
JSX 引用现在已被跟踪
在无效 RuleTester 情况的错误中移除 type 属性
Program AST 节点范围覆盖整个源文本
修复器方法现在需要字符串 text 参数
ScopeManager 实现的新要求
移除已弃用的 context 成员
移除已弃用的 SourceCode 方法
禁止有效 RuleTester 测试用例中的 errors 或 output
通配符模式中的 POSIX 字符类

对集成开发者的重大更改

🌐 Breaking changes for integration developers

Node.js < v20.19, v21, v23 不再受支持
新配置文件查找算法
旧配置格式不再支持
在 LintMessage 对象中移除 nodeType 属性
通配符模式中的 POSIX 字符类

Node.js < v20.19, v21, v23 不再受支持

从 ESLint v10.0.0 开始，ESLint 正式停止支持这些版本的 Node.js。ESLint 现在支持以下版本的 Node.js：

🌐 ESLint is officially dropping support for these versions of Node.js starting with ESLint v10.0.0. ESLint now supports the following versions of Node.js:

Node.js v20.19.0 及以上版本
Node.js v22.13.0 及以上版本
Node.js v24 及以上版本

要解决的问题： 使用 ESLint v10.0.0 时，请确保至少升级到 Node.js v20.19.0。一个需要特别注意的事项是，当通过编辑器集成使用 ESLint 时，要仔细检查你的编辑器支持的 Node.js 版本。如果无法升级，我们建议在能够升级 Node.js 之前继续使用 ESLint v9。

相关问题： #19969

`eslint:recommended` 已更新

eslint:recommended中已启用三条新规则：

🌐 Three new rules have been enabled in eslint:recommended:

处理方式： 修复错误或禁用这些规则。

相关问题： #19966

新的配置文件查找算法

在 ESLint v9 中，可以通过 v10_config_lookup_from_file 功能标志启用备用配置查找行为。此行为使 ESLint 从每个被 Lint 的文件所在目录开始，向上搜索文件系统根目录来定位 eslint.config.*。在 ESLint v10.0.0 中，此行为现在是默认行为，并且 v10_config_lookup_from_file 标志已被移除。尝试使用此标志将导致错误。

🌐 In ESLint v9, the alternate config lookup behavior could be enabled with the v10_config_lookup_from_file feature flag. This behavior made ESLint locate eslint.config.* by starting from the directory of each linted file and searching up towards the filesystem root. In ESLint v10.0.0, this behavior is now the default and the v10_config_lookup_from_file flag has been removed. Attempting to use this flag will now result in an error.

Codemod: 使用 @eslint/v9-to-v10-config codemod 从你的设置中移除旧的标志。

收件人：

手动移除旧版标志：
- CLI：移除 --flag v10_config_lookup_from_file。
- 环境：从 ESLINT_FLAGS 中移除 v10_config_lookup_from_file。
- API：从传递给 new ESLint() 或 new Linter() 的 flags 数组中移除 "v10_config_lookup_from_file"。
如果你依赖之前的（基于当前工作目录的）查找行为，请通过 --config path/to/eslint.config.js 提供一个明确的配置路径。

相关问题： RFC120，#19967

旧配置格式不再支持

ESLint v9 引入了一种基于 eslint.config.js 文件的新默认配置格式。旧格式，使用 .eslintrc 或 .eslintrc.json，仍然可以在 v9 中通过将 ESLINT_USE_FLAT_CONFIG 环境变量设置为 false 来启用。

🌐 ESLint v9 introduced a new default configuration format based on the eslint.config.js file. The old format, which used .eslintrc or .eslintrc.json, could still be enabled in v9 by setting the ESLINT_USE_FLAT_CONFIG environment variable to false.

从 ESLint v10.0.0 开始，不再支持旧的配置格式。

🌐 Starting with ESLint v10.0.0, the old configuration format is no longer supported.

Codemod: 使用 @eslint/v9-to-v10 codemod 来自动化完成大部分迁移。使用 @eslint/v9-to-v10-linter-api codemod 来更新已弃用的 FlatESLint 和 LegacyESLint 用法。

收件人：

或者按照配置迁移指南中的说明进行操作。
请注意，被弃用的 API FlatESLint 和 LegacyESLint 已被移除。请始终使用 ESLint。
Linter 类的 configType 选项不能再设置为 "eslintrc"。请移除该选项以使用新的配置格式。

相关问题： #13481

JSX 引用现在已被跟踪

ESLint v10.0.0 现在跟踪 JSX 引用，从而能够正确分析 JSX 元素的作用域。

🌐 ESLint v10.0.0 now tracks JSX references, enabling correct scope analysis of JSX elements.

以前，ESLint 不会跟踪由 JSX 标识符创建的引用，这可能导致依赖作用域信息的规则产生不正确的结果。例如：

🌐 Previously, ESLint did not track references created by JSX identifiers, which could lead to incorrect results from rules that rely on scope information. For example:

import { Card } from "./card.jsx";

export function createCard(name) {
	return <Card name={name} />;
}
1
2
3
4
5

在 v10.0.0 之前，ESLint 无法识别 <Card> 是导入的 Card 的引用，这可能导致误报，例如报告 Card 为“已定义但未使用” (no-unused-vars)，或者漏报，例如如果移除导入，则未能报告 Card 未定义 (no-undef)。从 v10.0.0 开始，<Card> 被视为对作用域中变量的普通引用。这使 JSX 的处理符合开发者预期，并改善了使用 JSX 的现代 JavaScript 应用的 linting 体验。

🌐 Prior to v10.0.0, ESLint did not recognize that <Card> is a reference to the imported Card, which could result in false positives such as reporting Card as “defined but never used” (no-unused-vars) or false negatives such as failing to report Card as undefined (no-undef) if the import is removed. Starting with v10.0.0, <Card> is treated as a normal reference to the variable in scope. This brings JSX handling in line with developer expectations and improves the linting experience for modern JavaScript applications using JSX.

收件人：

对于用户：
- 带有 JSX 的文件可能会出现新的代码检查报告。请相应更新你的代码，或在需要时调整规则配置。
- 以前用于绕过 ESLint 缺乏 JSX 引用跟踪的规则（例如，@eslint-react/jsx-uses-vars）现在不再需要。在你的配置中删除或禁用它们。
针对插件开发者：依赖作用域分析的自定义规则现在可能会遇到 JSXIdentifier 引用。请更新规则以正确处理这些情况。

相关问题： #19495

`eslint-env` 评论被报告为错误

在现已废弃的 ESLint v8 配置系统中，可以使用 /* eslint-env */ 注释为文件定义全局变量。当前的配置系统不支持此类注释，并且从 ESLint v10.0.0 开始，它们在代码检查期间会被报告为错误。

🌐 In the now obsolete ESLint v8 configuration system, /* eslint-env */ comments could be used to define globals for a file. The current configuration system does not support such comments, and starting with ESLint v10.0.0, they are reported as errors during linting.

error: /* eslint-env */ comments are no longer supported at file.js:1:1:
> 1 | /* eslint-env node -- Used in Node.js */
    | ^
1
2
3

处理方式： 从你的代码中删除任何 eslint-env 注释。如果你仍在使用旧的配置系统并且需要迁移帮助，请查看迁移指南。

相关问题： #13481

Jiti < v2.2.0 不再受支持

ESLint 正式停止支持低于 v2.2.0 的 jiti 版本。

🌐 ESLint is officially dropping support for versions of jiti that are less than v2.2.0.

要处理： 如果你用 TypeScript 编写了配置文件，并且安装了 jiti v2.1.2 或更早版本，请确保在使用 ESLint v10.0.0 时至少将其更新到 2.2.0。

相关问题： #19765

glob模式中的POSIX字符类

ESLint v10.0.0 使用最新版本的 minimatch，它在括号表达式中支持 POSIX 字符类。ESLint 依赖 minimatch 将文件名与通配符模式进行匹配，例如配置中的 files、ignores 和 globalIgnores() 所定义的模式，或通过 CLI 传递的模式。

🌐 ESLint v10.0.0 uses the latest version of minimatch, which supports POSIX character classes in bracket expressions. ESLint relies on minimatch to match file names against glob patterns, such as those defined in files, ignores, and globalIgnores() within a config, or passed via the CLI.

例如，要检查所有文件名以大写字母开头的 .js 文件，现在你可以运行：

🌐 For example, to lint all .js files whose names begin with an uppercase letter, you can now run:

npx eslint "**/[[:upper:]]*.js"
1

这里，[[:upper:]] 是一个 POSIX 字符类，用于匹配不同字母表中的大写字母。

🌐 Here, [[:upper:]] is a POSIX character class that matches uppercase letters in different alphabets.

要解决的问题： 如果你配置、CLI 参数或 Node.js API 调用中的任何全局匹配模式看起来包含 POSIX 字符类，请确认它们能够按预期匹配文件。

相关问题: eslint/rewrite#66

`stylish` 格式化器现在使用本地的 `styleText` 而不是 `chalk`

从 ESLint v10.0.0 开始，内置的 stylish 格式化程序不再依赖第三方 chalk 库来生成彩色输出。相反，它现在使用 Node.js 原生的 styleText API，这在确定彩色输出方式上引入了两个重大变更：

🌐 Starting in ESLint v10.0.0, the built-in stylish formatter no longer depends on the third-party chalk library for colorized output. Instead, it now uses Node.js’s native styleText API, which introduces two breaking changes regarding how colorized output is determined:

首先，styleText 在确定是否禁用彩色输出时会检查更多的环境变量，并遵循 Node.js 自身关于何时启用或禁用颜色的规则。这意味着它比 ESLint 之前基于 chalk 的逻辑尊重更多的环境变量和终端能力。例如：
- [NO_COLOR](https://nodejs.cn/api/cli.html#no_colorany) 现在在所有遵循此约定的工具中都能一致地禁用颜色。
- NODE_DISABLE_COLORS 也受到尊重，使 ESLint 的行为与 Node.js 本身保持一致。
请注意，FORCE_COLOR 环境变量仍然支持用来强制启用颜色。
其次，--color 和 --no-color CLI 标志在决定是否使用彩色输出时，现在优先于环境变量。此更改确保通过 CLI 标志明确设置的用户偏好被优先考虑。然而，如果未提供任何标志，将像以前一样考虑环境变量。

收件人：

检查与终端颜色相关的任何环境配置（例如，CI 默认值或 shell 配置文件）。如果在升级到 v10.0.0 后 ESLint 的输出显示为无颜色，请检查环境中是否设置了 NO_COLOR 或 NODE_DISABLE_COLORS（或类似设置）。
如果你依赖混合方法（例如，同时使用 --color 标志和设置 NO_COLOR 环境变量），请注意 CLI 标志现在优先，并相应地调整你的设置。

相关问题： #20012

`radix` 规则的已弃用选项

从 ESLint v10.0.0 开始，radix 规则的字符串选项 "always" 和 "as-needed" 已被弃用。设置这些选项中的任意一个不会改变该规则的行为，该规则现在总是强制提供基数，就像指定 "always" 选项（默认）时的情况一样。由于默认的基数取决于 parseInt() 的第一个参数，因此该规则假定始终需要第二个参数（基数）。

🌐 As of ESLint v10.0.0, string options "always" and "as-needed" of the radix rule are deprecated. Setting either of these options doesn’t change the behavior of this rule, which now always enforces providing a radix, as it was the case when the "always" option (default) was specified. Since the default radix depends on the first argument of parseInt(), this rule assumes that the second argument (the radix) is always needed.

此规则的默认行为未更改。

🌐 The default behavior of this rule has not been changed.

收件人：

如果你使用此规则时未指定任何选项，则无需执行任何操作。
如果你在使用此规则时明确指定了 "always" 选项，请删除该选项。此规则的行为将保持不变。
如果你在使用带有 "as-needed" 选项的此规则，请移除该选项，并更新你的代码以始终向 parseInt() 函数提供第二个参数。或者，你可以禁用此规则。

相关问题： #19916

`no-shadow-restricted-names` 现在默认报告 `globalThis`

在 ESLint v10.0.0 中，no-shadow-restricted-names 规则现在默认将 globalThis 视为受限名称。因此，reportGlobalThis 选项现在默认值为 true（以前为 false）。因此，像 const globalThis = "foo"; 或 function globalThis() {} 这样的声明现在将默认被报告。

🌐 In ESLint v10.0.0, the no-shadow-restricted-names rule now treats globalThis as a restricted name by default. Consequently, the reportGlobalThis option now defaults to true (previously false). As a result, declarations such as const globalThis = "foo"; or function globalThis() {} will now be reported by default.

收件人：

将名为 globalThis 的本地标识符重命名以避免遮蔽全局变量。
或者，通过显式配置规则来恢复之前的行为：

{
	"rules": {
		"no-shadow-restricted-names": ["error", { "reportGlobalThis": false }]
	}
}
1
2
3
4
5

相关问题： #19673

`func-names` 模式更严格

在 ESLint v10.0.0 中，func-names 规则的模式现在不允许在选项数组中有额外的项目。之前，包含超过允许选项的额外数组元素的配置会被接受，但会被忽略。现在，这类配置被视为无效。

🌐 In ESLint v10.0.0, the func-names rule schema now disallows extra items in the options array. Previously, configurations that included additional array elements beyond the allowed options were accepted but ignored. Such configurations are now considered invalid.

例如，由于多余的元素 "foo"，此配置现在无效：

🌐 For example, this configuration is now invalid due to the extra element "foo":

/*eslint func-names: ["error", "always", { "generators": "never" }, "foo"]*/
1

收件人：

从你的 func-names 配置中删除任何多余的数组元素，使其只包含：
- 一个基本字符串选项："always" | "as-needed" | "never"，并且
- 可选的，对象选项：{ "generators": "always" | "as-needed" | "never" }。

相关问题： #20134

`no-invalid-regexp` 的 `allowConstructorFlags` 选项现在只接受唯一的项目

在 ESLint v10.0.0 中，no-invalid-regexp 的 allowConstructorFlags 选项不再接受重复的标志作为输入。之前，数组中含有重复标志的配置是被接受的，但会被视为具有唯一标志配置的情况。现在，这类配置被认为是无效的，并会导致配置错误。

🌐 In ESLint v10.0.0, the allowConstructorFlags option of no-invalid-regexp no longer accepts duplicate flags as input. Previously, configurations with duplicate flags in the array were accepted but treated the same as having unique flags. Such configurations are now considered invalid and will result in a configuration error.

例如，由于重复的 "u" 标志，此配置现在无效：

🌐 For example, this configuration is now invalid due to the duplicate "u" flag:

/*eslint no-invalid-regexp: ["error", { "allowConstructorFlags": ["u", "y", "u"] }]*/
1

要解决的问题： 从你的 no-invalid-regexp 规则的 allowConstructorFlags 数组配置中移除任何重复的标志。每个标志在数组中只能出现一次。

相关问题： #18755

已向 ESLint 核心配置添加 `name` 属性

在 ESLint v10.0.0 中，name 属性已恢复到从 @eslint/js 导出的 ESLint 核心配置。这一属性之前由于与传统 eslintrc 配置系统不兼容而被移除。现在，由于不再支持 eslintrc，name 属性已被重新添加。

🌐 In ESLint v10.0.0, the name property has been restored to the ESLint core configs exported from @eslint/js. This property was previously removed due to incompatibility with the legacy eslintrc configuration system. Now that eslintrc is no longer supported, the name property has been added back.

对于大多数用户来说，这一更改不需要任何操作。然而，如果你正在使用来自 @eslint/eslintrc 的 FlatCompat 工具的 @eslint/js v10.x，则应将 @eslint/eslintrc 升级到最新版本以确保兼容性。

🌐 This change should not require any action for most users. However, if you are using @eslint/js v10.x with the FlatCompat utility from @eslint/eslintrc, you should upgrade @eslint/eslintrc to the latest version to ensure compatibility.

请注意： 如果你正在使用 FlatCompat，请将 @eslint/eslintrc 升级到最新版本。

相关问题： #19864

在无效 `RuleTester` 情况下错误中移除 `type` 属性

在 ESLint v10.0.0 中，规则无效测试用例中的已弃用 type 属性已被移除。在测试用例中使用 type 属性现在会抛出错误。

🌐 In ESLint v10.0.0, the deprecated type property in errors of invalid test cases for rules has been removed. Using the type property in test cases now throws an error.

代码修改工具（Codemod）： 使用 @eslint/v9-to-v10-ruletester 代码修改工具来自动执行此更改。

处理方法： 手动从无效测试用例中的错误对象中删除 type 属性。

相关问题： #19029

`Program` AST 节点范围覆盖整个源文本

ESLint v10.0.0 改变了 Program AST 节点的范围计算方式：它现在覆盖整个源文本，包括任何前导和尾随的注释及空白。

🌐 ESLint v10.0.0 changes how the Program AST node’s range is calculated: it now spans the entire source text, including any leading and trailing comments and whitespace.

之前，Program 节点的范围不包括前导和尾随的注释/空白，这可能会让人感到不直观。例如：

🌐 Previously, the Program node’s range excluded leading and trailing comments/whitespace, which could be unintuitive. For example:

// Leading comment
const x = 1;
// Trailing comment
1
2
3

在 ESLint v9 及更早版本中，Program.range 仅涵盖 const x = 1;（不包括周围的注释/空白）。

🌐 In ESLint v9 and earlier, Program.range covers only const x = 1; (excludes surrounding comments/whitespace).

从 ESLint v10.0.0 开始，Program.range 覆盖整个源文本，包括前导和尾随的注释/空白。

🌐 Starting with ESLint v10.0.0, Program.range covers the entire source text, including the leading and trailing comments/whitespace.

收件人：

对于规则和插件作者：如果你的代码依赖于之前的 Program.range 行为，或者依赖于假设该行为的 SourceCode 方法（例如 sourceCode.getCommentsBefore(programNode) 用于检索所有前置注释），请更新你的逻辑。如果你的代码在 Program 节点上报告问题，请更新逻辑以在 Program 节点内的第一个语句上报告问题，即 node.body[0] ?? node，以确保指令 /* eslint-disable your-rule */ 仍然可以正常工作。
对于自定义解析器：将 Program.range 设置为覆盖完整的源文本（通常为 [0, code.length]）。

相关问题： eslint/js#648

修复器方法现在需要字符串 `text` 参数

在 ESLint v10.0.0 中，所有接受 text 参数的规则修复方法现在都要求该参数为字符串。提供非字符串值将抛出 TypeError。

🌐 In ESLint v10.0.0, all rule fixer methods that accept a text argument now require that it be a string. Providing a non-string value will throw a TypeError.

受影响的方法：

🌐 Affected methods:

insertTextBefore(nodeOrToken, text)
insertTextBeforeRange(range, text)
insertTextAfter(nodeOrToken, text)
insertTextAfterRange(range, text)
replaceText(nodeOrToken, text)
replaceTextRange(range, text)

**注意：**确保传递给修复器方法的 text 值是一个字符串。

相关问题： #18807

`ScopeManager` 实现的新要求

在 ESLint v10.0.0 中，自定义 ScopeManager 实现必须自动解析代码中声明的全局变量的引用，包括 var 和 function 声明，并提供一个实例方法 addGlobals(names: string[])，该方法在全局作用域中创建具有给定名称的变量并解析对它们的引用。

🌐 In ESLint v10.0.0, custom ScopeManager implementations must automatically resolve references to global variables declared in the code, including var and function declarations, and provide an instance method addGlobals(names: string[]) that creates variables with the given names in the global scope and resolves references to them.

默认的 ScopeManager 实现 eslint-scope 已经被更新。

🌐 The default ScopeManager implementation eslint-scope has already been updated.

此更改不影响自定义规则。

🌐 This change does not affect custom rules.

要解决： 如果你维护一个提供自定义 ScopeManager 实现的自定义解析器，请更新你的自定义 ScopeManager 实现。

相关问题: eslint/js#665

移除已弃用的 `context` 成员

在 ESLint v9.x 中，我们废弃了以下方法和属性：

🌐 In ESLint v9.x, we deprecated the following methods and properties:

context.getCwd()
context.getFilename()
context.getPhysicalFilename()
context.getSourceCode()
context.parserOptions
context.parserPath

在 ESLint v10.0.0 中，所有这些成员均已被移除。

🌐 In ESLint v10.0.0, all of these members have been removed.

代码修改工具: 使用 @eslint/v9-to-v10-custom-rules 代码修改工具来自动化此更改。

要处理： 在你的自定义规则中，进行以下更改：

于 `context` 移除	于 `context` 替换
`context.getCwd()`	`context.cwd`
`context.getFilename()`	`context.filename`
`context.getPhysicalFilename()`	`context.physicalFilename`
`context.getSourceCode()`	`context.sourceCode`
`context.parserOptions`	`context.languageOptions` 或 `context.languageOptions.parserOptions`
`context.parserPath`	无替换。

你可以使用 eslint-transforms 工具对已移除的 context 方法进行更改。要使用该工具，首先安装它，然后运行 v9-rule-migration 转换，如下所示：

🌐 You can make changes for the removed context methods using the eslint-transforms utility. To use the utility, first install it and then run the v9-rule-migration transform, like this:

# install the utility
npm install eslint-transforms -g

# apply the transform to one file
eslint-transforms v9-rule-migration rule.js

# apply the transform to all files in a directory
eslint-transforms v9-rule-migration rules/
1
2
3
4
5
6
7
8

被移除的 context 属性必须手动处理，因为可能没有一一对应的替代品。

🌐 The removed context properties must be done manually as there may not be a direct one-to-one replacement.

相关问题： eslint/eslint#16999

移除已弃用的 `SourceCode` 方法

以下已弃用的 SourceCode 方法已在 ESLint v10.0.0 中移除：

🌐 The following deprecated SourceCode methods have been removed in ESLint v10.0.0:

getTokenOrCommentBefore()
getTokenOrCommentAfter()
isSpaceBetweenTokens()
getJSDocComment()

这些方法在多个主要版本中已被弃用，主要用于已弃用的格式化规则和 ESLint 内部工具。使用这些方法的自定义规则必须更新为使用它们的现代替代方法。

🌐 These methods have been deprecated for multiple major versions and were primarily used by deprecated formatting rules and internal ESLint utilities. Custom rules using these methods must be updated to use their modern replacements.

代码修改工具: 使用 @eslint/v9-to-v10-custom-rules 代码修改工具来自动化此更改。

要处理： 在你的自定义规则中，进行以下更改：

于 `SourceCode` 移除	替代
`getTokenOrCommentBefore(nodeOrToken, skip)`	`getTokenBefore(nodeOrToken, { includeComments: true, skip })`
`getTokenOrCommentAfter(nodeOrToken, skip)`	`getTokenAfter(nodeOrToken, { includeComments: true, skip })`
`isSpaceBetweenTokens(first, second)`	`isSpaceBetween(first, second)`
`getJSDocComment(node)`	无替代

兼容性补丁可在 @eslint/compat 包中获取，以帮助过渡。

🌐 Compatibility patches are available in the @eslint/compat package to help with the transition.

相关问题： #20113

禁止 `errors` 或 `output` 的有效 RuleTester 测试用例

在 ESLint v10.0.0 中，RuleTester 对测试用例的结构变得更加严格。有效的测试用例（那些不应产生任何 lint 错误的用例）不再允许包含 errors 或 output 属性。

🌐 In ESLint v10.0.0, the RuleTester has become more strict about test case structure. Valid test cases (those that should not produce any linting errors) are no longer allowed to have errors or output properties.

更改内容：

以前，有效的测试用例可以包括 errors 或 output 属性，但这些属性会被忽略。
现在，在有效的测试用例中包含这些属性将导致测试失败。

无效用法示例：

🌐 Example of invalid usage:

// This will now throw an error in ESLint v10.0.0
const validTestCases = [
	{
		code: "const foo = 'bar';",
		errors: 0, // ❌ Not allowed in valid test cases
		output: "const foo = 'bar';", // ❌ Not allowed in valid test cases
	},
];

ruleTester.run("rule-id", rule, { valid: validTestCases, invalid: [] });
1
2
3
4
5
6
7
8
9
10

代码修改工具（Codemod）： 使用 @eslint/v9-to-v10-ruletester 代码修改工具来自动执行此更改。

处理方法： 手动从有效测试用例中移除任何 errors/output 属性。

相关问题： #18960

在 `LintMessage` 对象中移除 `nodeType` 属性

在 ESLint v10.0.0 中，LintMessage 对象上已弃用的 nodeType 属性已被移除。这会影响之前依赖 message.nodeType 的 Node.js API 使用者（例如，自定义格式化程序和编辑器/工具集成）。

🌐 In ESLint v10.0.0, the deprecated nodeType property on LintMessage objects has been removed. This affects consumers of the Node.js API (for example, custom formatters and editor/tool integrations) that previously relied on message.nodeType.

代码修改工具（Codemod）： 使用 @eslint/v9-to-v10-linter-api 代码修改工具来自动化此更改。

处理方法： 手动删除你在集成和格式化程序中使用的所有 message.nodeType。

相关问题： #19029

迁移至 v10.x

使用迁移代码修改工具

目录

对用户的重大更改

对插件开发者的重大更改

对集成开发者的重大更改

Node.js < v20.19, v21, v23 不再受支持

eslint:recommended 已更新

新的配置文件查找算法

旧配置格式不再支持

JSX 引用现在已被跟踪

eslint-env 评论被报告为错误

Jiti < v2.2.0 不再受支持

glob模式中的POSIX字符类

stylish 格式化器现在使用本地的 styleText 而不是 chalk

radix 规则的已弃用选项

no-shadow-restricted-names 现在默认报告 globalThis

func-names 模式更严格

no-invalid-regexp 的 allowConstructorFlags 选项现在只接受唯一的项目

已向 ESLint 核心配置添加 name 属性

在无效 RuleTester 情况下错误中移除 type 属性

Program AST 节点范围覆盖整个源文本

修复器方法现在需要字符串 text 参数

ScopeManager 实现的新要求

移除已弃用的 context 成员

移除已弃用的 SourceCode 方法

禁止 errors 或 output 的有效 RuleTester 测试用例

在 LintMessage 对象中移除 nodeType 属性

`eslint:recommended` 已更新

`eslint-env` 评论被报告为错误

`stylish` 格式化器现在使用本地的 `styleText` 而不是 `chalk`

`radix` 规则的已弃用选项

`no-shadow-restricted-names` 现在默认报告 `globalThis`

`func-names` 模式更严格

`no-invalid-regexp` 的 `allowConstructorFlags` 选项现在只接受唯一的项目

已向 ESLint 核心配置添加 `name` 属性

在无效 `RuleTester` 情况下错误中移除 `type` 属性

`Program` AST 节点范围覆盖整个源文本

修复器方法现在需要字符串 `text` 参数

`ScopeManager` 实现的新要求

移除已弃用的 `context` 成员

移除已弃用的 `SourceCode` 方法

禁止 `errors` 或 `output` 的有效 RuleTester 测试用例

在 `LintMessage` 对象中移除 `nodeType` 属性