给前端以福利，给编程以复利。大家好，我是大家的林语冰。
00. 观前须知
ESLint 是一款提高代码质量的静态分析工具，旨在使代码风格更加一致，同时避免错误。
ESLint 主要包括两大类规则：代码质量规则和格式化规则。不幸的是，以后 ESLint 有且仅有代码质量规则了......
去年的 ESLint 8.53 中，ESLint 官宣废除所有格式化规则，在项目中使用此类规则会被警告。在官方博客中，ESLint 团队提及 ESLint 10 可能会完全废除所有格式化规则，而目前最新的 ESLint 主版本已经到达 ESLint 9.2 了，是时候未雨绸缪了。
本期一起来回顾 ESLint 废除格式化规则的诸多幕后原因和技术细节，以及为什么 ESLint 团队笃信此乃势在必行的正确选择。
免责声明
本文属于是语冰的直男翻译了属于是，略有删改，仅供粉丝参考。英文原味版请传送 。
01. 背景
2013 年 ESLint 首发时，JS 生态系统陷入了关于源码格式化是否应该纳入 linter 工具的斗嘴。
JSLint 是地球上第一个 JS linter，“JSLint 之父”将其格式化规则大量编码到 JSLint 中。这些风格偏好在 JSLint 的继任者 JSHint 中得到了延续和松耦。
但 2013 年，JSHint 宣布废除格式化规则，且会在下个主版本中删除。虽然这些规则从未被删除，但仍会展示警告：
警告：格式化规则已废除，且会在下个主版本中删除。JSHint 将其范畴限制在代码准确性的问题上。如果你想强制执行源码格式化规则，请传送到 JSCS 项目。
JSCS 项目的诞生旨在满足 JS 开发者日益增长的愿望，精准地格式化开发者的代码。ESLint 出现的同段实验期，用户尝试使用 JSHint、JSCS 和 ESLint 的不同组合来实现其 linting 和格式化需求。
早期，我认为 ESLint 与 JSHint 分庭抗礼的唯一方式在于，确保所有可用的 JSHint 规则都有 ESLint 版本的等效功能。
虽然 ESLint 从古至今的优势一直是创建自定义规则，但如果每个人都必须自己重建 JSHint 规则，ESLint 势必不会得到大规模采用。我最初的计划是制定几十条核心规则，然后将其余规则作为插件来实现。
随着时间的推移，ESLint 收到越来越多向核心源码添加格式化规则的需求。许多需求提到它们不想在代码中同时使用两种工具：ESLint + JSCS，如果 ESLint 可以纳入 JSCS 的功能，它们可以果断弃用 JSCS，且只使用 ESLint。
因此，现在 ESLint 有一个团队，我们关注实现等价功能来支持这种用户场景。最终，我们的工作十分出色，JSCS 的使用率下降了，我们将 JSCS 合并到了 ESLint。
那时我们还太年轻，不知道 JSHint 的想法才是正确的，尽管 ESLint 已经成为 JS 的主流 linter 和源码格式化工具，但我们涉及了太多工作。
02. JS 技术爆炸和维护负担
在 ES6 和 React 发展的推动下，大家编写 JS 的方式今非昔比。Airbnb 和 Standard 等人气爆棚的风格指南鼓励 JS 开发者精确掌握其代码的优雅编写方式。
结果，ESLint 被关于格式化规则的需求淹没了。
在过去十年里，我们见证了各种奇葩的代码风格，并伴随着在 ESLint 核心规则中强制执行它们的需求。每次引入 ES6 新语法时，我们都会收到一系列更新现有规则和实现新规则的需求。
当核心规则接近 300 条时，我们试图通过冻结风格规则来减轻维护负担，这样我们就避免了极端情况，以此支持用户的个人偏好。这有所帮助，但还不够。
- 规则冲突。用户期望核心规则能够“梦幻联动”，这意味着，任意两个规则都不应标记相同的问题，任意两个核心规则也不应给出相互冲突的建议。虽然当核心规则少于 30 条时，这轻而易举，但当规则超过 300 条时，这就难如脱单，甚至是不可能事件。
- 不切实际的期望。有了大量核心格式化规则，用户期望每种样式指南都应该只使用核心规则就可以实现，而无需涉及插件。这让 ESLint 团队雪上加雪，要求它们继续添加选项，这也增加了 ESLint 核心源码的规模。
- 努力 vs 价值错位。不断添加新选项和例外，支持用户的风格指南的维护重担压在了 ESLint 团队身上，而价值却只被少数用户提取。
- 机会成本。我们花在维护格式化规则上的时间越多，花在利于大量用户事情上的时间就越少。
- 索然无趣。虽然 ESLint 受益于外部贡献，但这些贡献者对纠结空格等极端情况不感兴趣。ESLint 团队本身认为这些规则的优先级远远低于其他工作，这常常使问题长时间悬而未决。
- 一致性问题。由于 ESLint 的规则被设计为原子性，且无法访问其他规则，因此我们会遭遇无法正确修复错误的问题，因为信息位于另一个规则中。举个栗子，如果自动修复需要添加新的代码行，则需要知道文件如何缩进才能应用正确的修复。但是，
indent规则控制 ESLint 的缩进，这意味着，其他规则需要应用不带缩进的修复，然后相信indent规则将在后续传递中修复缩进。
随着 ESLint 朽化，这些问题与日俱增，我们终于遭遇了压死骆驼的最后一根稻草。
所有源码格式化规则将在 ESLint 8.53 的下一个版本中废除，但至少要等到 ESLint 10 才会被删除。尽管你可能会在 ESLint CLI 中亲眼目睹废除的警告，但你还可以继续使用它们。
03. 你该如何是好
我们建议使用源码格式化工具，而不是诉诸 ESLint 来格式化代码。源码格式化工具旨在理解整个文件，并在整个文件中应用一致的格式。
虽然你可能无法像 ESLint 那样对异常有大量控制，但与使用数十个单独的规则配置 ESLint 相比，你将获得简单性和速度的权衡。
我们推荐下列两种格式化工具：
- Prettier：基于 JS 的格式化程序，支持多语言格式化
- dprint：基于 Rust 的格式化程序，支持迷你的语言集
如果你对使用专用源码格式化工具的想法不感兴趣，你还可以使用针对 JS 的 @stylistic/eslint-plugin-js 或针对 TS 的 @stylistic/eslint-plugin-ts。这些 npm 包分别包含 ESLint 核心和 typescript-eslint 中废除的格式规则。
这些软件包由 AntFu 维护，他决定继续维护这些规则。如果你想继续使用 ESLint 的源码格式化规则，那么我们建议切换到这些软件包。
04. 高潮总结
我们知道很多用户依赖 ESLint 来提高代码质量和格式化源码，因此，我们不会轻易做出这样的重大决定。
不幸的是，我们一直以来的行事方式已经进退两难，我们被迫这样改变。专用源码格式化工具的普遍存在和人气爆棚使这一决定变得更加容易，因为 AntFu 自愿将源码格式化规则作为单独的包来维护。
我们由衷期望本文的可用备选方案之一能确保用户可以继续以自己喜欢的方式格式化源代码。
参考文献
- ESLint：
- Blog：
- v9.2：
粉丝互动
本期话题是：你更喜欢使用 ESLint 一劳永逸，还是更青睐 ESLint + Prettier 分而治之？你可以在本文下方自由言论，文明科普。
欢迎持续关注“前端俱乐部”，给前端以福利，给编程以复利。
坚持阅读的小伙伴可以给自己点赞！谢谢大家的点赞，掰掰~