发布于 2023 年 10 月 26 日，归类于公告

格式规则弃用

ESLint 的下一个小版本更新将弃用核心格式规则。我们建议您使用源代码格式化工具来代替。

在计划于 2023 年 11 月 3 日星期五发布的 ESLint v8.53.0 中，我们将正式弃用我们的格式规则。格式规则是指那些仅强制执行关于空格、分号、字符串格式等的代码规范的规则。由于多种原因（将在本文中讨论），这对 ESLint 的未来发展是正确的决定。然而，要理解我们是如何走到这一步的，回顾一下过去是有帮助的。

背景

当 ESLint 最初在 2013 年发布时，JavaScript 生态系统正陷入一场关于源代码格式化是否应成为 linter 一部分的辩论中。最初的 JavaScript linter JSLint，在其工具中大量编码了作者的格式偏好。这些偏好被继承并在 JSLint 的继任者 JSHint 中有所放宽，但到 2013 年，JSHint 宣布它将弃用其格式化选项，并将在下一个主要版本中删除它们。虽然这些选项从未被删除，但它们仍然显示此警告

警告此选项已被弃用，将在 JSHint 的下一个主要版本中删除。

JSHint 正在将其范围限制在代码正确性问题上。如果您想强制执行与代码风格相关的规则，请查看 JSCS 项目。

JSCS 项目的诞生是为了满足 JavaScript 开发者对以更具体方式格式化代码日益增长的需求。与 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 已成为 JavaScript 的主要 linter（和源代码格式化工具），但我们也为此承担了很多工作。

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

在随后的几年里，尤其是在 ECMAScript 6 和 React 的增长的刺激下，人们编写 JavaScript 的方式发生了巨大的变化。像 Airbnb 和 Standard 这样越来越流行的风格指南鼓励 JavaScript 开发者更具体地了解他们的代码是如何编写的。结果，ESLint 被关于格式化规则的例外和选项的请求淹没了。在过去的十年中，我们看到了各种各样的怪异风格，并伴随着在 ESLint 核心规则中强制执行这些风格的请求。并且每次引入新语法时，我们都会收到大量更新现有规则和实现新规则的请求。

当我们接近核心中的 300 条规则时，我们试图通过冻结风格规则来减轻维护负担，这样我们就不会再追逐角落案例来支持每个人的个人偏好。这在某种程度上有所帮助，但还不够。

规则冲突。 人们期望核心规则能够彼此良好协作，这意味着没有两条规则应该标记相同的问题，也没有任何两条核心规则会给出相互冲突的建议。当核心规则少于 30 条时，这很容易做到，但当规则达到 300 条时，即使不是不可能，也变得非常困难。
不切实际的期望。 拥有大量格式化规则的核心，用户期望每个可能的风格指南都应该仅通过核心规则来实现，而无需涉及插件。这给团队带来了更大的压力，要求他们继续添加选项，这也增加了核心的大小。
努力与价值错位。 不断添加新选项和例外以支持每个人的风格指南的维护负担落在了 ESLint 团队身上，而价值却被少数用户提取了。
机会成本。 我们花在维护格式化规则上的时间越多，我们花在对我们的大量用户有益的事情上的时间就越少。
缺乏兴趣。 虽然 ESLint 受益于外部贡献，但这些贡献者对追逐空格的角落案例根本不感兴趣。ESLint 团队本身将这些规则的优先级排在任何其他工作之下，这通常导致问题长期未解决。
一致性问题。 因为 ESLint 的规则被设计为原子的，并且无法访问其他规则，所以我们会遇到这样的问题：由于信息在另一个规则中，因此无法正确修复错误。例如，如果自动修复需要添加新的一行代码，它需要知道文件是如何缩进的，以便应用正确的修复。然而，indent 规则控制 ESLint 的缩进，这意味着其他规则需要在没有缩进的情况下应用修复，然后相信 indent 规则会在随后的过程中修复缩进。

随着 ESLint 年龄的增长，所有这些问题都在持续增长，我们终于到了无法跟上它们的程度。

已弃用的规则

以下列表包含将在 v8.53.0 中弃用的所有规则

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

您应该怎么做

我们建议使用源代码格式化工具而不是 ESLint 来格式化您的代码。源代码格式化工具旨在理解整个文件并在整个文件中应用一致的格式。虽然您可能不像使用 ESLint 那样对例外情况有那么多的控制权，但权衡之处在于您将获得的简洁性和速度，而不是使用数十个单独的规则配置 ESLint。我们推荐以下两种格式化工具

Prettier - 一个基于 JavaScript 的格式化工具，支持格式化大量语言
dprint - 一个基于 Rust 的格式化工具，支持较小范围的语言

如果您不喜欢使用专门的源代码格式化工具的想法，您也可以使用 @stylistic/eslint-plugin-js 用于 JavaScript 或 @stylistic/eslint-plugin-ts 用于 TypeScript。这些软件包包含来自 ESLint 核心和 typescript-eslint 的已弃用格式规则。这些软件包由 Anthony Fu 维护，他已决定继续维护这些规则。如果您想继续使用本文中提到的规则，那么我们建议您切换到这些软件包。

结论

我们知道很多人依赖 ESLint 来实现代码质量和格式化目的，因此，我们不会轻易做出像这样重要的决定。不幸的是，我们一直以来的做事方式无法进一步扩展，我们需要做出这个改变。专用源代码格式化工具的普及和流行使得这个决定变得稍微容易一些，Anthony Fu 自愿将这些规则作为单独的软件包维护也是如此。我们希望本文中提到的可用选项之一将确保人们能够继续以他们喜欢的方式格式化他们的源代码。