发布于 2023年10月26日在公告版块

弃用格式化规则

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

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

背景

ESLint 最初于 2013 年发布时，JavaScript 生态系统正处于一场关于源代码格式化是否应该成为静态代码检查工具一部分的争论之中。JSLint，最初的 JavaScript 静态代码检查工具，将作者的格式化偏好强烈地编码到工具中。这些偏好在 JSLint 的继任者 JSHint 中被延续并略微放宽，但到 2013 年，JSHint 宣布它正在弃用其格式化选项，并在下一个主要版本中删除它们。虽然这些选项从未被删除，但它们仍然显示此警告

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

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

JSCS 项目应运而生，以满足 JavaScript 开发者希望以更具体的方式格式化代码的需求。JSCS 与 ESLint 同年出现，人们尝试使用 JSHint、JSCS 和 ESLint 的不同组合来实现他们的静态代码检查和格式化需求，经历了一段实验期。

早期，我认为 ESLint 与 JSHint 合理竞争的唯一方法是确保 JSHint 的所有规则都有 ESLint 的等效规则。虽然 ESLint 的优势（至今仍然是）在于创建自定义规则，但我认为如果每个人都必须自己重新创建 JSHint 的规则，ESLint 就不会被广泛采用。我最初的计划是创建大约二十个核心规则，然后将其余的留给插件实现。

随着时间的推移，ESLint 收到越来越多的请求，要求将格式化和风格规则添加到核心中。许多请求提到他们不想在他们的代码上使用两个工具（ESLint 和 JSCS），如果 ESLint 可以做 JSCS 所做的一切，他们可以放弃 JSCS 并只使用 ESLint。因此，现在 ESLint 有了一个团队，我们专注于实现功能对等性以支持这种用例。最终，我们做得很好，JSCS 的使用量下降了，我们将 JSCS 合并到 ESLint 中。

当时我们不知道的是，JSHint 是正确的，虽然 ESLint 已经成为 JavaScript 中占主导地位的静态代码检查工具（和源代码格式化工具），但我们也承担了大量的工作。

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 志愿维护这些规则作为单独的包，使得这个决定更容易一些。我们希望本文中提到的可用选项之一能够确保人们可以继续以他们喜欢的方式格式化他们的源代码。