近日，ESLint 官推消息，ESLint 将在下一个次要版本弃用核心格式化规则，并建议开发者使用源代码格式化工具。

2023年9月23日，ESLint v8.50.0 版本发布，一个小的版本升级。同时 ESLint 计划在 v9.0.0 中放弃对 Node.js < 18 和 Node.js 19 的支持。

ESLint 计划在 2023 年 11 月 3 日发布的 ESLint v8.53.0 版本中正式弃用格式化规则。格式化规则是那些简单地强制执行代码约定，例如空格、分号、字符串格式等的规则。ESLint 团队认为这是一个正确的决定，具体原因会在本文中讨论。

主要内容如下：

• 背景介绍

• JavaScript 爆发式增长和维护负担

• 要废弃的规则

• 替代方案

1.背景介绍

ESLint 发布于 2013 年，当时关于是否将代码格式化作为代码规范工具的一部分是存在争议的。最初的 JavaScript 内核工具 JSLint 将作者的格式偏好大量编码到工具中。这些偏好在 JSLint 的后继者 JSHint 中得到了延续，并略有松动，但到 2013 年，JSHint 宣布放弃格式化选项，并将在下一个主要版本中删除这些选项。虽然这些选项从未被移除，但仍会显示此警告：

JSCS 项目应运而生，以满足 JavaScript 开发人员越来越多地以更具体的方式格式化其代码的需求。与 ESLint 同年出现，人们开始尝试使用 JSHint、JSCS 和 ESLint 的不同组合来满足他们的代码检查和格式化需求。

一开始，ESLint 要与 JSHint 合理竞争的唯一方法就是确保所有可用的 JSHint 规则具有 ESLint 的等效规则。尽管 ESLint 的优势在于创建自定义规则（现在仍然如此），但是如果每个人都必须为自己重新创建 JSHint 规则，ESLint不会受到太多采纳。z最初的计划是创建几十个核心规则，然后将其余规则作为插件实现。

随着时间的推移，ESLint 收到越来越多的请求，希望将格式化和代码风格规则添加到核心功能中。其中许多请求提到他们不想在他们的代码中同时使用两个工具（ESLint 和 JSCS ），如果 ESLint 能够做到 JSCS 所做的一切，他们可以放弃 JSCS ，仅使用ESLint。因此，现在 ESLint 有了一个团队，他们专注于实现功能平衡，以支持这种需求。最终，ESLint 团队做得非常好，JSCS 的使用率持续下降，他们将 JSCS 合并到了 ESLint 中。

当时，ESLint 团队没有意识到的是 JSHint 的想法是正确的，尽管 ESLint 已经成为 JavaScript 的主要代码检查工具（源代码格式化工具）。

2.JavaScript 的爆炸式增长和维护负担

在接下来的几年里，特别是在 ECMAScript 6 和 React 的推动下，人们编写 JavaScript 的方式发生了巨大变化。越来越受欢迎的风格指南，如 Airbnb 和 Standard ，鼓励 JavaScript 开发人员更加具体地了解代码是如何编写的。因此，ESLint 被大量要求在格式规则上提供异常和选项。在过去的十年中，出现了各种怪异的代码风格，并伴随着要求在 ESLint 核心规则中强制执行这些风格的请求。每次引入新的语法，都会收到一大堆更新现有规则和实施新规则的请求。

随着核心规则达到 300 条，ESLint 团队尝试通过冻结样式规则来减少维护负担，以便不再费力地支持每个人的个人偏好。这在某种程度上有所帮助，但还不够。

• 规则冲突：人们期望核心规则之间相互兼容，这意味着没有两个规则应该标记相同的问题，也没有两个核心规则应该给出相互矛盾的建议。虽然在不到30个核心规则时很容易实现，但是随着规则增加到 300 个，要做到这一点变得困难，甚至是不可能的。
• 不切实际的期望：随着大量的格式化规则核心，用户期望仅仅通过核心规则而不涉及插件就能够达到各种可能的样式指南。这给团队增加了更多的压力，需要继续添加选项，也增加了核心的大小。
• 工作量与价值不匹配：不断添加新选项和例外以支持每个人的样式指南的维护负担落在了 ESLint 团队身上，而价值则被少数用户提取出来。
• 机会成本：团队花在维护格式化规则上的时间越多，花在对大量用户有益的事情上的时间就越少。
• 缺乏兴趣：虽然 ESLint 受益于外部贡献，但这些贡献者对于解决间隙空格问题并不感兴趣。ESLint 团队本身将这些规则的优先级远远低于其他工作，这经常导致问题长时间没有解决。
• 一致性问题：由于 ESLint 规则的设计是原子式的，无法访问其他规则，因此会遇到这样的问题：由于信息存在于其他规则中，因此无法正确修复错误。例如，如果自动修复程序需要添加一行新代码，它就需要知道文件的缩进方式，以便应用正确的修复。然而，缩进规则控制着 ESLint 的缩进，这意味着其他规则需要在不缩进的情况下应用修复，然后相信缩进规则会在后续处理中修复缩进。

随着 ESLint 的发展，所有这些问题都在不断增加，ESLint 团队已经到了无法解决这些问题的地步。

3.要废弃的规则

以下列表包含了 v8.53.0 中将废弃的所有规则：

• array-bracket-newline
• array-bracket-spacing
• array-element-newline
• arrow-parens
• arrow-spacing
• block-spacing
• brace-style
• comma-dangle
• comma-spacing
• comma-style
• computed-property-spacing
• dot-location
• eol-last
• func-call-spacing
• function-call-argument-newline
• function-paren-newline
• generator-star-spacing
• implicit-arrow-linebreak
• indent
• jsx-quotes
• key-spacing
• keyword-spacing
• linebreak-style
• lines-between-class-members
• lines-around-comment
• max-len
• max-statements-per-line
• multiline-ternary
• new-parens
• newline-per-chained-call
• no-confusing-arrow
• no-extra-parens
• no-extra-semi
• no-floating-decimal
• no-mixed-operators
• no-mixed-spaces-and-tabs
• no-multi-spaces
• no-multiple-empty-lines
• no-tabs
• no-trailing-spaces
• no-whitespace-before-property
• nonblock-statement-body-position
• object-curly-newline
• object-curly-spacing
• object-property-newline
• one-var-declaration-per-line
• operator-linebreak
• padded-blocks
• padding-line-between-statements
• quote-props
• quotes
• rest-spread-spacing
• semi
• semi-spacing
• semi-style
• space-before-blocks
• space-before-function-paren
• space-in-parens
• space-infix-ops
• space-unary-ops
• spaced-comment
• switch-colon-spacing
• template-curly-spacing
• template-tag-spacing
• wrap-iife
• wrap-regex
• yield-star-spacing

所有这些规则都将在下一个版本中被弃用，但至少在 ESLint v10.0.0 之前（如果不是更晚的话）不会被移除。您可以继续使用这些规则，尽管您可能会在 ESLint CLI 中看到弃用警告。

4.替代方案

ESLint 团队建议使用源代码格式化工具而不是 ESLint 来格式化您的代码。源代码格式器可以理解整个文件，并在整个文件中应用一致的格式。虽然您可能无法像使用 ESLint 那样对异常情况进行更多控制，但与使用数十条单独规则配置 ESLint 相比，这样做的好处是简单快捷。推荐使用两种格式器：

• Prettier：基于 JavaScript 的格式化工具，支持大量语言的格式化
• dprint：基于 Rust 的格式化工具，支持较小语种集

如果你不喜欢使用专用的源代码格式化工具，也可以使用 @stylistic/eslint-plugin-js 用于 JavaScript 或 @stylistic/eslint-plugin-ts 用于 TypeScript。这些软件包分别包含 ESLint core 和 typescript-eslint 中废弃的格式化规则。Anthony Fu（一个狂热的开源者） 决定继续维护这些包包含的这些规则。

5.最后

现在很多开发者都依赖 ESLint 来提高代码质量和格式化，因此 ESLint 团队不会轻易做出这样的重大决定。不幸的是，他们一直以来的工作方式无法继续扩展，因此需要做出改变。专用源代码格式化工具的普遍性和受欢迎程度让这一决定变得更加容易，而 Anthony Fu 也自愿将规则作为一个单独的软件包进行维护。