ESLint v8.0.0 迁移指南11 项破坏性变更全解析与升级实战【免费下载链接】eslintFind and fix problems in your JavaScript code.项目地址: https://gitcode.com/GitHub_Trending/es/eslint本指南基于 ESLint 仓库官方迁移文档编写系统梳理 ESLint v8.0.0 引入的全部破坏性变更覆盖普通用户、插件开发者与集成开发者三类人群逐项说明变更原因、影响范围、具体解法与对应源码实现依据。读完本文你可以独立完成从 ESLint 7 到 8 的平滑升级并理解meta.hasSuggestions、meta.fixable、ESLint类、/use-at-your-own-risk入口等新机制在底层是如何被强制校验的。变更总览按受影响用户规模排序v8.0.0 是 ESLint 的一个大版本major release官方在发布时做了若干破坏性变更。以下清单按“预计影响用户数量”从多到少排列前几项影响面最大面向普通用户的变更Node.js 10、13、15 不再支持移除codeframe与table两种内置 formattercomma-dangle规则 schema 校验更严格未使用的 disable 指令现在可被--fix自动移除eslint:recommended预设新增 4 条规则面向插件开发者的变更规则提供 suggestion 必须声明meta.hasSuggestions规则提供 fix 必须声明meta.fixableSourceCode#getComments()在RuleTester中会直接失败对象简写属性的 AST 格式发生变化面向集成开发者的变更CLIEngine类被彻底移除废弃的linter对象被移除/lib内部入口点被移除公共 API 边界正式收紧Node.js 10、13、15 不再支持Node.js 10、13、15 三个版本均在 2020 年至 2021 年初达到生命周期终点end of life。从 ESLint v8.0.0 起官方正式停止对它们的支持最低支持版本提升为Node.js 12.22 及以上Node.js 14 及以上Node.js 16 及以上升级建议使用 ESLint v8.0.0 时请确保运行环境至少为 Node.js12.22.0。特别要注意编辑器集成场景——很多 IDE 插件内置了自己的 Node.js 运行时升级 ESLint 前应先确认编辑器侧绑定的 Node.js 版本满足要求。如果当前环境确实无法升级 Node.js官方建议继续停留在 ESLint 7直到具备升级条件。移除codeframe与table内置 formatterv8.0.0 从核心代码中删除了codeframe和table两个 formatter。原因在于它们依赖的第三方库在 ESLint 其他模块中完全用不到移除后可以显著减小 ESLint 包体积从而加快安装速度。升级建议如果你之前用eslint -f codeframe或eslint -f table指定输出格式需要分别安装对应的独立包来继续使用npm install -D eslint-formatter-codeframe npm install -D eslint-formatter-table安装后仍可通过-f codeframe/-f table调用。comma-dangle规则 schema 校验更严格在 ESLint v7.0.0 中下面这种配置不会报错——因为规则只读取配置数组的第二个元素多出的第三个元素会被静默忽略{ rules: { comma-dangle: [error, never, { arrays: always }] } }在 v8.0.0 中这种配置会直接抛出校验错误。查看当前仓库中 comma-dangle 规则的 schema 定义 可以看到收紧后的结构schema 类型为arrayitems只允许一个元素且该元素要么是字符串枚举值要么是包含arrays、objects、imports、exports、functions五个键的对象同时additionalItems: false意味着数组中不允许出现任何多余元素additionalProperties: false则禁止对象中出现未知键。这正是“第三个元素导致报错”的底层原因。升级建议将规则配置改为数组只含两个元素且第二个元素为字符串或对象{ comma-dangle: [error, never] }或使用完整的对象形式所有键均可省略省略项默认跟随never行为{ comma-dangle: [ error, { arrays: never, objects: never, imports: never, exports: never, functions: never } ] }补充说明该规则实际支持的字符串枚举值为always-multiline、always、never、only-multiline对象内的各项还额外支持ignore对应源码中always-multiline: forceTrailingCommaIfMultiline、only-multiline: allowTrailingCommaIfMultiline、never: forbidTrailingComma等实现逻辑。未使用的 disable 指令现在可被自动修复在 v7.0.0 中命令行同时使用--report-unused-disable-directives与--fix时ESLint 只会修复规则问题而把未使用的 disable 指令原样留在代码里。v8.0.0 改变了这一行为这两个选项组合使用时未使用的 disable 指令会被自动删除。升级建议如果你仍希望保留未使用的 disable 指令不被删除请在命令行追加--fix-type problem,suggestion,layout将修复范围明确限制为这三类从而避开对指令的清理。eslint:recommended预设更新新增 4 条规则v8.0.0 在eslint:recommended预设中启用了 4 条新规则no-loss-of-precision禁止丢失精度的数字字面量no-nonoctal-decimal-escape禁止\8、\9这类非八进制十进制转义no-unsafe-optional-chaining禁止对可选链结果进行不安全的运算no-useless-backreference禁止正则中无用的反向引用这 4 条规则的实现均可从仓库中找到例如 no-loss-of-precision、no-nonoctal-decimal-escape、no-unsafe-optional-chaining、no-useless-backreference。升级建议使用eslint:recommended的项目升级后应重新运行 lint修复新增的错误或按需对个别规则进行显式关闭。仓库中的 eslint-recommended 测试 展示了 recommended 预设“推荐规则全部设为 error、非推荐规则不出现”的校验逻辑可作为升级后验证配置行为的参考。规则提供 suggestion 必须声明meta.hasSuggestionsv7.0.0 中规则提供 suggestions建议修复时无需告知 ESLint。v8.0.0 起凡是提供 suggestions 的规则必须在meta中设置meta.hasSuggestions: true否则运行时直接报错。升级建议按如下格式为你的规则添加元信息module.exports { meta: { hasSuggestions: true, }, create(context) { // your rule }, };这一校验在底层由 linter 的 report 拦截逻辑 强制实施当problem.suggestions存在而rule.meta.hasSuggestions ! true时会抛出Rules with suggestions must set the meta.hasSuggestions property to true.如果规则仍在用旧属性名meta.docs.suggestion则会额外提示该字段已被忽略并引导迁移。仓库中大量内置规则如 eqeqeq、no-console、no-implicit-coercion 等均已按此格式声明可作为参考样例。规则提供 fix 必须声明meta.fixablev7.0.0 中以函数形式而非对象形式导出的规则也能提供 fix。v8.0.0 起只有对象形式导出的规则允许提供 fix且必须设置meta.fixable为code或whitespace。升级建议如果你现有的规则是函数形式module.exports function (context) { // your rule };请改写为对象格式并补充meta.fixablemodule.exports { meta: { fixable: code, // or whitespace }, create(context) { // your rule }, };与 suggestions 同理该约束也在 linter 的 report 拦截逻辑 中强制校验problem.fix存在而rule.meta.fixable缺失时会抛出Fixable rules must set the meta.fixable property to code or whitespace.。对象格式也是当前仓库所有内置规则的统一写法详见 规则目录。SourceCode#getComments()在RuleTester中直接失败早在 ESLint v4.0.0 中SourceCode#getComments()就被标记为废弃但一直没有移除。v8.0.0 采取中间过渡方案不直接删除它而是让RuleTester在规则内部调用该方法时测试失败——生产环境下既有规则依然可以运行但开发者跑测试时会立刻发现该用法从而被强制迁移。该方法计划在 v9.0.0 中彻底移除。升级建议如果你的规则调用了SourceCode#getComments()请改用三个明确的方法替代相关用法详见 自定义规则文档中“访问注释”一节SourceCode#getCommentsBefore(node)获取节点之前的注释SourceCode#getCommentsAfter(node)获取节点之后的注释SourceCode#getCommentsInside(node)获取节点内部的注释对象简写属性 AST 格式变化Espree/Acorn 升级引起v8.0.0 引入了 Espree v8.0.0 以支持新语法而 Espree 内部又升级到 Acorn v8.0.0导致对象简写属性在 AST 中的表示方式发生变化。考虑如下代码const version 8; const x { version, };v7 与 v8 都会生成如下结构的属性节点{ type: Property, method: false, shorthand: true, computed: false, key: { type: Identifier, name: version }, kind: init, value: { type: Identifier, name: version } }注意key与value携带了完全相同的信息。但在 Acorn v8.0.0即 ESLint v8.0.0之前这两个节点实际是同一个对象因此可以用判断它们是否代表同一节点// true in ESLint v7.x, false in ESLint v8.0.0 if (propertyNode.key propertyNode.value) { // do something }v8.0.0 中key与value变成了两个独立对象恒为false。升级建议如果你的规则依赖这种“同一性”判断请改用以下两种方式之一使用propertyNode.shorthand判断该属性是否为简写属性节点使用每个节点的range属性判断key与value是否占据相同的源码区间。CLIEngine类被移除改用ESLint类CLIEngine类在 v8.0.0 中被彻底移除由ESLint类替代完整说明见 Node.js API 文档。下表是旧方法到新方法的完整映射CLIEngineESLintexecuteOnFiles(patterns)lintFiles(patterns)executeOnText(text, filePath, warnIgnored)lintText(text, options)getFormatter(name)loadFormatter(name)getConfigForFile(filePath)calculateConfigForFile(filePath)isPathIgnored(filePath)isPathIgnored(filePath)static outputFixes(results)static outputFixes(results)static getErrorResults(results)static getErrorResults(results)static getFormatter(name)已移除 ※1addPlugin(pluginId, definition)plugins构造选项getRules()已移除 ※2resolveFileGlobPatterns()已移除 ※3三个标记项的补充说明※1 旧的engine.getFormatter()原样返回加载到的包对象出于向后兼容考虑很难再为 formatter 增加新特性。新的eslint.loadFormatter()返回一个适配器对象它包装了加载到的包对象便于后续扩展该适配器还能访问ESLint实例用于计算默认数据例如基于已加载插件规则生成rulesMeta。因此ESLint类只实现了实例方法版本的loadFormatter()。※2CLIEngine#getRules()存在副作用所以被移除。若想基于 lint 结果获取规则的元信息请改用ESLint#getRulesMetaForResults()实现见 eslint.js若想获取全部内置规则可通过eslint/use-at-your-own-risk导入builtinRules属于不受支持的内部 API。※3 自 v6.0.0 起ESLint 遍历文件时就不再使用resolveFileGlobPatterns()的逻辑该方法早已名存实亡。升级建议将代码中的new CLIEngine(options)替换为new ESLint(options)并将executeOnFiles→lintFiles、executeOnText→lintText、getFormatter→loadFormatter等逐一对应改写。当前仓库的公共导出入口 api.js 中ESLint、Linter、RuleTester、SourceCode均来自顶层导出集成方可直接require(eslint)获取。废弃的linter对象被移除v7 时代遗留的linter单例对象在 v8.0.0 中被从 ESLint 包中删除。升级建议若你曾这样使用const { linter } require(eslint);请改为实例化Linter类const { Linter } require(eslint); const linter new Linter();当前仓库的 api.js 只导出Linter类而不导出旧linter单例Linter的verify、verifyAndFix等方法定义见 linter.js。/lib入口点被移除公共 API 边界正式收紧自 v8.0.0 起ESLint 严格定义其公共 API。此前可以通过require(eslint/lib/rules/semi)这类路径直捣内部文件的行为不再被允许。作为折中少量既有 API 通过/use-at-your-own-risk入口继续暴露但这些 API 不被正式支持可能随时变更或消失。升级建议如果你通过/lib直接访问规则const rule require(eslint/lib/rules/semi);请改为const { builtinRules } require(eslint/use-at-your-own-risk); const rule builtinRules.get(semi);如果你直接访问FileEnumeratorconst { FileEnumerator } require(eslint/lib/cli-engine/file-enumerator);请改为const { FileEnumerator } require(eslint/use-at-your-own-risk);从当前仓库看unsupported-api.js 正是/use-at-your-own-risk入口的实现它导出builtinRules即 lib/rules/index.js 中的LazyLoadingRuleMap以懒加载方式集中收集全部内置规则以及shouldUseFlatConfig。而eslint/lib/rules/...这类深层路径已不再是官方支持的导入方式内置规则的唯一推荐获取渠道就是builtinRules.get(name)。升级检查清单完成上述迁移后可按以下清单逐项核验运行环境确认 Node.js ≥ 12.22.0且编辑器集成的 Node 版本同步达标。formatter检查-f参数若使用codeframe/table安装对应的独立包。规则配置检查所有规则配置数组元素数量重点修正comma-dangle等规则的多余参数。CLI 组合选项若同时使用--report-unused-disable-directives与--fix确认是否接受 disable 指令被自动移除必要时追加--fix-type problem,suggestion,layout。recommended 预设重新运行 lint处理no-loss-of-precision、no-nonoctal-decimal-escape、no-unsafe-optional-chaining、no-useless-backreference四类新告警。自定义规则检查meta.hasSuggestions与meta.fixable是否声明函数形式规则是否已改写为对象形式是否仍调用SourceCode#getComments()是否依赖简写属性的key value同一性判断。集成代码用ESLint类替换CLIEngine用new Linter()替换linter单例将/lib深度导入改为顶层导入或/use-at-your-own-risk入口。跑一遍测试若你是插件开发者在RuleTester环境下运行全部规则测试确认没有因getComments()或 meta 声明缺失导致的失败。按此清单逐项处理即可平稳完成从 ESLint 7 到 8 的升级同时让你的插件与集成代码对齐 v8 之后的新 API 边界。【免费下载链接】eslintFind and fix problems in your JavaScript code.项目地址: https://gitcode.com/GitHub_Trending/es/eslint创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ESLint v8.0.0 迁移指南：11 项破坏性变更全解析与升级实战
ESLint v8.0.0 迁移指南11 项破坏性变更全解析与升级实战【免费下载链接】eslintFind and fix problems in your JavaScript code.项目地址: https://gitcode.com/GitHub_Trending/es/eslint本指南基于 ESLint 仓库官方迁移文档编写系统梳理 ESLint v8.0.0 引入的全部破坏性变更覆盖普通用户、插件开发者与集成开发者三类人群逐项说明变更原因、影响范围、具体解法与对应源码实现依据。读完本文你可以独立完成从 ESLint 7 到 8 的平滑升级并理解meta.hasSuggestions、meta.fixable、ESLint类、/use-at-your-own-risk入口等新机制在底层是如何被强制校验的。变更总览按受影响用户规模排序v8.0.0 是 ESLint 的一个大版本major release官方在发布时做了若干破坏性变更。以下清单按“预计影响用户数量”从多到少排列前几项影响面最大面向普通用户的变更Node.js 10、13、15 不再支持移除codeframe与table两种内置 formattercomma-dangle规则 schema 校验更严格未使用的 disable 指令现在可被--fix自动移除eslint:recommended预设新增 4 条规则面向插件开发者的变更规则提供 suggestion 必须声明meta.hasSuggestions规则提供 fix 必须声明meta.fixableSourceCode#getComments()在RuleTester中会直接失败对象简写属性的 AST 格式发生变化面向集成开发者的变更CLIEngine类被彻底移除废弃的linter对象被移除/lib内部入口点被移除公共 API 边界正式收紧Node.js 10、13、15 不再支持Node.js 10、13、15 三个版本均在 2020 年至 2021 年初达到生命周期终点end of life。从 ESLint v8.0.0 起官方正式停止对它们的支持最低支持版本提升为Node.js 12.22 及以上Node.js 14 及以上Node.js 16 及以上升级建议使用 ESLint v8.0.0 时请确保运行环境至少为 Node.js12.22.0。特别要注意编辑器集成场景——很多 IDE 插件内置了自己的 Node.js 运行时升级 ESLint 前应先确认编辑器侧绑定的 Node.js 版本满足要求。如果当前环境确实无法升级 Node.js官方建议继续停留在 ESLint 7直到具备升级条件。移除codeframe与table内置 formatterv8.0.0 从核心代码中删除了codeframe和table两个 formatter。原因在于它们依赖的第三方库在 ESLint 其他模块中完全用不到移除后可以显著减小 ESLint 包体积从而加快安装速度。升级建议如果你之前用eslint -f codeframe或eslint -f table指定输出格式需要分别安装对应的独立包来继续使用npm install -D eslint-formatter-codeframe npm install -D eslint-formatter-table安装后仍可通过-f codeframe/-f table调用。comma-dangle规则 schema 校验更严格在 ESLint v7.0.0 中下面这种配置不会报错——因为规则只读取配置数组的第二个元素多出的第三个元素会被静默忽略{ rules: { comma-dangle: [error, never, { arrays: always }] } }在 v8.0.0 中这种配置会直接抛出校验错误。查看当前仓库中 comma-dangle 规则的 schema 定义 可以看到收紧后的结构schema 类型为arrayitems只允许一个元素且该元素要么是字符串枚举值要么是包含arrays、objects、imports、exports、functions五个键的对象同时additionalItems: false意味着数组中不允许出现任何多余元素additionalProperties: false则禁止对象中出现未知键。这正是“第三个元素导致报错”的底层原因。升级建议将规则配置改为数组只含两个元素且第二个元素为字符串或对象{ comma-dangle: [error, never] }或使用完整的对象形式所有键均可省略省略项默认跟随never行为{ comma-dangle: [ error, { arrays: never, objects: never, imports: never, exports: never, functions: never } ] }补充说明该规则实际支持的字符串枚举值为always-multiline、always、never、only-multiline对象内的各项还额外支持ignore对应源码中always-multiline: forceTrailingCommaIfMultiline、only-multiline: allowTrailingCommaIfMultiline、never: forbidTrailingComma等实现逻辑。未使用的 disable 指令现在可被自动修复在 v7.0.0 中命令行同时使用--report-unused-disable-directives与--fix时ESLint 只会修复规则问题而把未使用的 disable 指令原样留在代码里。v8.0.0 改变了这一行为这两个选项组合使用时未使用的 disable 指令会被自动删除。升级建议如果你仍希望保留未使用的 disable 指令不被删除请在命令行追加--fix-type problem,suggestion,layout将修复范围明确限制为这三类从而避开对指令的清理。eslint:recommended预设更新新增 4 条规则v8.0.0 在eslint:recommended预设中启用了 4 条新规则no-loss-of-precision禁止丢失精度的数字字面量no-nonoctal-decimal-escape禁止\8、\9这类非八进制十进制转义no-unsafe-optional-chaining禁止对可选链结果进行不安全的运算no-useless-backreference禁止正则中无用的反向引用这 4 条规则的实现均可从仓库中找到例如 no-loss-of-precision、no-nonoctal-decimal-escape、no-unsafe-optional-chaining、no-useless-backreference。升级建议使用eslint:recommended的项目升级后应重新运行 lint修复新增的错误或按需对个别规则进行显式关闭。仓库中的 eslint-recommended 测试 展示了 recommended 预设“推荐规则全部设为 error、非推荐规则不出现”的校验逻辑可作为升级后验证配置行为的参考。规则提供 suggestion 必须声明meta.hasSuggestionsv7.0.0 中规则提供 suggestions建议修复时无需告知 ESLint。v8.0.0 起凡是提供 suggestions 的规则必须在meta中设置meta.hasSuggestions: true否则运行时直接报错。升级建议按如下格式为你的规则添加元信息module.exports { meta: { hasSuggestions: true, }, create(context) { // your rule }, };这一校验在底层由 linter 的 report 拦截逻辑 强制实施当problem.suggestions存在而rule.meta.hasSuggestions ! true时会抛出Rules with suggestions must set the meta.hasSuggestions property to true.如果规则仍在用旧属性名meta.docs.suggestion则会额外提示该字段已被忽略并引导迁移。仓库中大量内置规则如 eqeqeq、no-console、no-implicit-coercion 等均已按此格式声明可作为参考样例。规则提供 fix 必须声明meta.fixablev7.0.0 中以函数形式而非对象形式导出的规则也能提供 fix。v8.0.0 起只有对象形式导出的规则允许提供 fix且必须设置meta.fixable为code或whitespace。升级建议如果你现有的规则是函数形式module.exports function (context) { // your rule };请改写为对象格式并补充meta.fixablemodule.exports { meta: { fixable: code, // or whitespace }, create(context) { // your rule }, };与 suggestions 同理该约束也在 linter 的 report 拦截逻辑 中强制校验problem.fix存在而rule.meta.fixable缺失时会抛出Fixable rules must set the meta.fixable property to code or whitespace.。对象格式也是当前仓库所有内置规则的统一写法详见 规则目录。SourceCode#getComments()在RuleTester中直接失败早在 ESLint v4.0.0 中SourceCode#getComments()就被标记为废弃但一直没有移除。v8.0.0 采取中间过渡方案不直接删除它而是让RuleTester在规则内部调用该方法时测试失败——生产环境下既有规则依然可以运行但开发者跑测试时会立刻发现该用法从而被强制迁移。该方法计划在 v9.0.0 中彻底移除。升级建议如果你的规则调用了SourceCode#getComments()请改用三个明确的方法替代相关用法详见 自定义规则文档中“访问注释”一节SourceCode#getCommentsBefore(node)获取节点之前的注释SourceCode#getCommentsAfter(node)获取节点之后的注释SourceCode#getCommentsInside(node)获取节点内部的注释对象简写属性 AST 格式变化Espree/Acorn 升级引起v8.0.0 引入了 Espree v8.0.0 以支持新语法而 Espree 内部又升级到 Acorn v8.0.0导致对象简写属性在 AST 中的表示方式发生变化。考虑如下代码const version 8; const x { version, };v7 与 v8 都会生成如下结构的属性节点{ type: Property, method: false, shorthand: true, computed: false, key: { type: Identifier, name: version }, kind: init, value: { type: Identifier, name: version } }注意key与value携带了完全相同的信息。但在 Acorn v8.0.0即 ESLint v8.0.0之前这两个节点实际是同一个对象因此可以用判断它们是否代表同一节点// true in ESLint v7.x, false in ESLint v8.0.0 if (propertyNode.key propertyNode.value) { // do something }v8.0.0 中key与value变成了两个独立对象恒为false。升级建议如果你的规则依赖这种“同一性”判断请改用以下两种方式之一使用propertyNode.shorthand判断该属性是否为简写属性节点使用每个节点的range属性判断key与value是否占据相同的源码区间。CLIEngine类被移除改用ESLint类CLIEngine类在 v8.0.0 中被彻底移除由ESLint类替代完整说明见 Node.js API 文档。下表是旧方法到新方法的完整映射CLIEngineESLintexecuteOnFiles(patterns)lintFiles(patterns)executeOnText(text, filePath, warnIgnored)lintText(text, options)getFormatter(name)loadFormatter(name)getConfigForFile(filePath)calculateConfigForFile(filePath)isPathIgnored(filePath)isPathIgnored(filePath)static outputFixes(results)static outputFixes(results)static getErrorResults(results)static getErrorResults(results)static getFormatter(name)已移除 ※1addPlugin(pluginId, definition)plugins构造选项getRules()已移除 ※2resolveFileGlobPatterns()已移除 ※3三个标记项的补充说明※1 旧的engine.getFormatter()原样返回加载到的包对象出于向后兼容考虑很难再为 formatter 增加新特性。新的eslint.loadFormatter()返回一个适配器对象它包装了加载到的包对象便于后续扩展该适配器还能访问ESLint实例用于计算默认数据例如基于已加载插件规则生成rulesMeta。因此ESLint类只实现了实例方法版本的loadFormatter()。※2CLIEngine#getRules()存在副作用所以被移除。若想基于 lint 结果获取规则的元信息请改用ESLint#getRulesMetaForResults()实现见 eslint.js若想获取全部内置规则可通过eslint/use-at-your-own-risk导入builtinRules属于不受支持的内部 API。※3 自 v6.0.0 起ESLint 遍历文件时就不再使用resolveFileGlobPatterns()的逻辑该方法早已名存实亡。升级建议将代码中的new CLIEngine(options)替换为new ESLint(options)并将executeOnFiles→lintFiles、executeOnText→lintText、getFormatter→loadFormatter等逐一对应改写。当前仓库的公共导出入口 api.js 中ESLint、Linter、RuleTester、SourceCode均来自顶层导出集成方可直接require(eslint)获取。废弃的linter对象被移除v7 时代遗留的linter单例对象在 v8.0.0 中被从 ESLint 包中删除。升级建议若你曾这样使用const { linter } require(eslint);请改为实例化Linter类const { Linter } require(eslint); const linter new Linter();当前仓库的 api.js 只导出Linter类而不导出旧linter单例Linter的verify、verifyAndFix等方法定义见 linter.js。/lib入口点被移除公共 API 边界正式收紧自 v8.0.0 起ESLint 严格定义其公共 API。此前可以通过require(eslint/lib/rules/semi)这类路径直捣内部文件的行为不再被允许。作为折中少量既有 API 通过/use-at-your-own-risk入口继续暴露但这些 API 不被正式支持可能随时变更或消失。升级建议如果你通过/lib直接访问规则const rule require(eslint/lib/rules/semi);请改为const { builtinRules } require(eslint/use-at-your-own-risk); const rule builtinRules.get(semi);如果你直接访问FileEnumeratorconst { FileEnumerator } require(eslint/lib/cli-engine/file-enumerator);请改为const { FileEnumerator } require(eslint/use-at-your-own-risk);从当前仓库看unsupported-api.js 正是/use-at-your-own-risk入口的实现它导出builtinRules即 lib/rules/index.js 中的LazyLoadingRuleMap以懒加载方式集中收集全部内置规则以及shouldUseFlatConfig。而eslint/lib/rules/...这类深层路径已不再是官方支持的导入方式内置规则的唯一推荐获取渠道就是builtinRules.get(name)。升级检查清单完成上述迁移后可按以下清单逐项核验运行环境确认 Node.js ≥ 12.22.0且编辑器集成的 Node 版本同步达标。formatter检查-f参数若使用codeframe/table安装对应的独立包。规则配置检查所有规则配置数组元素数量重点修正comma-dangle等规则的多余参数。CLI 组合选项若同时使用--report-unused-disable-directives与--fix确认是否接受 disable 指令被自动移除必要时追加--fix-type problem,suggestion,layout。recommended 预设重新运行 lint处理no-loss-of-precision、no-nonoctal-decimal-escape、no-unsafe-optional-chaining、no-useless-backreference四类新告警。自定义规则检查meta.hasSuggestions与meta.fixable是否声明函数形式规则是否已改写为对象形式是否仍调用SourceCode#getComments()是否依赖简写属性的key value同一性判断。集成代码用ESLint类替换CLIEngine用new Linter()替换linter单例将/lib深度导入改为顶层导入或/use-at-your-own-risk入口。跑一遍测试若你是插件开发者在RuleTester环境下运行全部规则测试确认没有因getComments()或 meta 声明缺失导致的失败。按此清单逐项处理即可平稳完成从 ESLint 7 到 8 的升级同时让你的插件与集成代码对齐 v8 之后的新 API 边界。【免费下载链接】eslintFind and fix problems in your JavaScript code.项目地址: https://gitcode.com/GitHub_Trending/es/eslint创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考