Published under: Release Notes
1 min read
在 ESLint v8.53.0 中，计划于 2023 年 11 月 3 日星期五发布，我们将正式弃用我们的格式化规则。格式化规则是那些仅用于强制执行代码约定的规则，例如空格、分号、字符串格式等。出于本文讨论的各种原因，这是 ESLint 未来发展的正确决定。然而，为了理解我们是如何走到这一步的，回顾过去一下会很有帮助。
🌐 In ESLint v8.53.0, scheduled to be released on Friday, November 3, 2023, we will formally deprecate our formatting rules. Formatting rules are those rules that simply enforce code conventions around spacing, semicolons, string formats, etc. For a variety of reasons, which are discussed in this post, this is the right decision for ESLint going forward. However, to understand how we got here, it’s helpful to look backward for a moment.
背景
🌐 Background
当 ESLint 于 2013 年首次发布时，JavaScript 生态系统正陷入关于源代码格式化是否应当成为代码检查工具一部分的争论中。JSLint，最初的 JavaScript 代码检查工具，将其作者的格式化偏好强烈地编码进了工具中。这些偏好在 JSLint 的继任者 JSHint 中得以保留并略微放宽，但到 2013 年，JSHint 已宣布将弃用其格式化选项，并将在下一个主要版本中移除它们。虽然这些选项从未被移除，它们仍然显示此警告：
🌐 When ESLint was initially released in 2013, the JavaScript ecosystem was embroiled in a debate about whether or not source code formatting should be part of a linter. JSLint, the original JavaScript linter, heavily encoded its author’s formatting preferences into the tool. Those preferences were carried over and loosened a bit in JSLint’s successor, JSHint, but by 2013, JSHint had announced that it was deprecating its formatting options and would be removing them in the next major release. While the options were never removed, they still show this warning:
警告 此选项已被弃用，并将在 JSHint 的下一个主要版本中移除。
JSHint 正在将其范围限制在代码正确性问题上。如果你希望执行与代码风格相关的规则，请查看 JSCS 项目。
JSCS 项目诞生是为了满足 JavaScript 开发者日益增长的以更具体方式格式化代码的需求。它与 ESLint 出现在同一年，当时人们尝试使用 JSHint、JSCS 和 ESLint 的不同组合来实现他们的代码检查和格式化需求，因此有一段实验期。
🌐 The JSCS project was born to cater to the growing desire of JavaScript developers to format their code in more specific ways. Appearing in the same year as ESLint, there was a bit of an experimentation period as people tried using different combinations of JSHint, JSCS, and ESLint to achieve their linting and formatting needs.
起初，我认为 ESLint 想要合理地与 JSHint 竞争，唯一的方法就是确保所有可用的 JSHint 规则都有 ESLint 的对应规则。虽然 ESLint 的优势在于创建自定义规则（现在仍然是），但我认为如果每个人都必须为自己重新创建 JSHint 规则，ESLint 不会被广泛采用。我最初的计划是制作几十条核心规则，然后将其余部分留给插件来实现。
🌐 Early on, I thought the only way for ESLint to reasonably compete with JSHint was to ensure that all available JSHint rules had ESLint equivalents. While the strength of ESLint was (and still is) in creating custom rules, I didn’t think ESLint would get much adoption if everyone had to recreate the JSHint rules for themselves. My initial plan was to make a couple dozen core rules and then leave the rest to be implemented as plugins.
随着时间的推移，ESLint 收到了越来越多的请求，希望在核心中添加格式化和风格规则。许多请求提到，他们不想在代码上使用两个工具（ESLint 和 JSCS），如果 ESLint 能做 JSCS 所做的所有事情，他们就可以放弃 JSCS，只使用 ESLint。因此，现在 ESLint 有了一个团队，我们专注于实现功能等价以支持这种使用场景。最终，我们做得非常出色，以至于 JSCS 的使用量下降了，我们将 JSCS 合并到 ESLint。
🌐 As time went on, ESLint received more and more requests to add formatting and stylistic rules to the core. Many of the requests mentioned that they didn’t want to use two tools (ESLint and JSCS) on their code and if ESLint could do everything that JSCS did, they could drop JSCS and just use ESLint. And so, now that ESLint had a team, we focused on getting feature parity to support this use case. Eventually, we did such a good job that JSCS usage dropped and we merged JSCS into ESLint.
当时我们不知道的是，JSHint 的想法是正确的，尽管 ESLint 已经成为 JavaScript 的主流代码检查工具（和源代码格式化工具），我们也已经签下了很多工作。
🌐 What we didn’t know at the time was that JSHint had the right idea, and although ESLint had become the dominant linter (and source code formatter) for JavaScript, we had also signed up for a lot of work.
JavaScript 的爆炸性增长与维护负担
🌐 JavaScript’s explosion and the maintenance burden
在随后的几年里，尤其是在 ECMAScript 6 和 React 的发展推动下，人们编写 JavaScript 的方式发生了巨大的变化。日益流行的风格指南，如 Airbnb 和 Standard，鼓励 JavaScript 开发者对代码的书写方式更为具体。因此，ESLint 收到了大量关于格式化规则的例外和选项请求。在过去的十年中，我们见识了各种奇怪的代码风格，并伴随着希望在 ESLint 核心规则中强制执行这些风格的请求。每当引入新的语法时，我们都会收到大量请求，要求更新现有规则或实现新规则。
🌐 In the ensuing years, and especially spurred on by ECMAScript 6 and the growth of React, the way people were writing JavaScript was changing dramatically. Increasingly popular style guides like Airbnb and Standard encouraged JavaScript developers to get more specific about how their code was written. As a result, ESLint was inundated with requests for exceptions and options on formatting rules. Over the last ten years, we’ve seen all manner of bizarre styles accompanied by requests to enforce them in ESLint core rules. And every time new syntax is introduced, we get a flurry of requests to update existing rules and implement new rules.
当我们的核心规则接近300条时，我们尝试通过冻结风格规则来减少维护负担，这样我们就不再追逐每个人个人偏好的边缘情况。这在一定程度上有所帮助，但还不够。
🌐 As we approached 300 rules in the core, we tried to reduce the maintenance burden by freezing stylistic rules so that we were no longer chasing down corner cases to support everyone’s personal preferences. That helped somewhat, but not enough.
- 规则冲突。 人们期望核心规则彼此协调，这意味着不会有两个规则标记同一个问题，也不会有两个核心规则给出相互矛盾的建议。当核心规则少于30条时，这很容易做到，但当有300条规则时，实现这一点变得困难，甚至不可能。
- 不切实际的期望。 由于有大量核心的格式规则，用户期望仅靠核心规则就能实现每一种可能的风格指南，而无需使用插件。这给团队带来了更大的压力，迫使他们继续添加选项，同时也增加了核心的体积。
- 努力与价值不匹配。 不断增加新选项和例外以支持每个人的风格指南的维护负担落在 ESLint 团队身上，而价值却被少数用户获取。
- 机会成本。 我们花在维护格式规则上的时间越多，就用在对大量用户有益的事情上的时间就越少。
- 缺乏兴趣。 虽然 ESLint 受益于外部的贡献者，但这些贡献者对追踪空格的边角情况并不感兴趣。ESLint 团队本身也将这些规则的优先级远低于其他任何工作，这通常导致问题长时间悬而未决。
- 一致性问题。 由于 ESLint 的规则设计为原子性的，并且不能访问其他规则，我们会遇到一些问题，例如无法正确修复错误，因为相关信息在另一个规则中。例如，如果自动修复需要添加一个新的代码行，它需要知道文件的缩进方式才能应用正确的修复。然而，
indent规则控制 ESLint 的缩进，这意味着其他规则需要在不处理缩进的情况下应用修复，然后相信indent规则会在随后的执行中修复缩进。
随着 ESLint 的发展，所有这些问题持续增长，我们最终到了一个根本无法跟上它们的地步。
🌐 All of these problems continued to grow as ESLint got older, and we’re finally at a point where we just cannot keep up with them.
已弃用的规则
🌐 The deprecated rules
以下列表包含将在 v8.53.0 中弃用的所有规则：
🌐 The following list contains all of the rules that will be deprecated in v8.53.0:
array-bracket-newlinearray-bracket-spacingarray-element-newlinearrow-parensarrow-spacingblock-spacingbrace-stylecomma-danglecomma-spacingcomma-stylecomputed-property-spacingdot-locationeol-lastfunc-call-spacingfunction-call-argument-newlinefunction-paren-newlinegenerator-star-spacingimplicit-arrow-linebreakindentjsx-quoteskey-spacingkeyword-spacinglinebreak-stylelines-between-class-memberslines-around-commentmax-lenmax-statements-per-linemultiline-ternarynew-parensnewline-per-chained-callno-confusing-arrowno-extra-parensno-extra-semino-floating-decimalno-mixed-operatorsno-mixed-spaces-and-tabsno-multi-spacesno-multiple-empty-linesno-tabsno-trailing-spacesno-whitespace-before-propertynonblock-statement-body-positionobject-curly-newlineobject-curly-spacingobject-property-newlineone-var-declaration-per-lineoperator-linebreakpadded-blockspadding-line-between-statementsquote-propsquotesrest-spread-spacingsemisemi-spacingsemi-stylespace-before-blocksspace-before-function-parenspace-in-parensspace-infix-opsspace-unary-opsspaced-commentswitch-colon-spacingtemplate-curly-spacingtemplate-tag-spacingwrap-iifewrap-regexyield-star-spacing
所有这些规则将在下一个版本中被废弃，但至少在 ESLint v10.0.0 之前不会被移除（如果不是更晚的话）。你仍然可以继续使用它们，尽管你可能会在 ESLint CLI 中看到废弃警告。
🌐 All of these rules will be deprecated as of the next release, but will not be removed until at least ESLint v10.0.0 (if not later). You can continue to use them although you may see deprecation warnings in the ESLint CLI.
你应该做的事相反
🌐 What you should do instead
我们建议使用源代码格式化工具而不是 ESLint 来格式化你的代码。源代码格式化工具旨在理解整个文件，并在整个文件中应用一致的格式化。虽然你可能不像使用 ESLint 那样对例外情况有那么多控制，但这样做的好处是，相比配置包含数十条单独规则的 ESLint，你会获得更简单和更快速的体验。我们推荐两种格式化工具：
🌐 We recommend using a source code formatter instead of ESLint for formatting your code. Source code formatters are built to understand the entire file and apply consistent formatting throughout. While you might not have as much control over exceptions as with ESLint, the tradeoff is the simplicity and speed you’ll get vs. configuring ESLint with dozens of individual rules. There are two formatters that we recommend:
如果使用专用源代码格式化工具的想法对你没有吸引力，你也可以使用 JavaScript 的 @stylistic/eslint-plugin-js 或 TypeScript 的 @stylistic/eslint-plugin-ts。这些包分别包含来自 ESLint 核心和 typescript-eslint 的已弃用格式化规则。这些包由 Anthony Fu 维护，他决定继续维护这些规则。如果你希望继续使用本文中提到的规则，那么我们建议切换到这些包。
🌐 If the idea of using a dedicated source code formatter doesn’t appeal to you, you can also use @stylistic/eslint-plugin-js for JavaScript or @stylistic/eslint-plugin-ts for TypeScript. These packages contain the deprecated formatting rules from the ESLint core and typescript-eslint, respectively. The packages are maintained by Anthony Fu, who has decided to continue maintaining these rules going forward. If you’d like to continue using the rules mentioned in this post, then we recommend switching to these packages.
结论
🌐 Conclusion
我们知道很多人依赖 ESLint 来保证代码质量和格式，因此，我们不会轻率地做出像这样的重大决定。不幸的是，我们一直以来的做法无法再大幅扩展，因此我们需要做出这个改变。专用源代码格式化工具的普及和流行使这个决定变得相对容易，同时 Anthony Fu 自愿将规则维护为一个独立的包也是一个原因。我们希望本文提到的可用选项之一能够确保人们继续以自己喜欢的方式格式化源代码。
🌐 We know that a lot of people rely on ESLint for code quality and formatting purposes, and as such, we don’t take significant decisions like this lightly. Unfortunately, the way we’ve been doing things just won’t scale much further and we needed to make this change. The ubiquity and popularity of dedicated source code formatters made this decision somewhat easier, as was Anthony Fu volunteering to maintain the rules as a separate package. We hope that one of the available options mentioned in this post will ensure that people can continue formatting their source code in their preferred way.
