04-23 17:51 富途_企业服务业务部_前端工程师

关注

别再用 ESLint 格式化你的代码了！原理揭秘。

公众号：程序员白特，欢迎一起交流学习~

来源：公众号-前端从进阶到入院

多年来，我一直呼吁“停止使用 ESLint 进行格式化”[1]。我认为像Prettier[2]这样的格式化工具和像ESLint[3]这样的 linter 是两种不同的工具，它们有不同的用途。虽然你可以使用 ESLint 进行格式化，这要归功于ESLint Stylistic[4]，但ESLint 建议使用一个单独的专用格式化工具[5]，typescript-eslint 也建议不要使用 ESLint 进行格式化[6]。

以下两个工具通常被用来帮助 ESLint 与 Prettier 更好地交互：

`eslint-config-prettier`[7]：一个 ESLint _共享配置_，它禁用了与格式化相关的规则
`eslint-plugin-prettier`[8]：一个 ESLint _插件_，它将 Prettier 作为规则在 ESLint 内部运行

我认为在大多数项目中，这两个工具都不再有用。本文将解释每个工具的用途、它们之间的区别，以及为什么我通常不使用它们。

回顾：ESLint 自定义

ESLint[9]通过让用户单独配置“规则”或对代码库进行检查来工作。ESLint 将执行代码解析成规则可以理解的形式、将代码传递给这些规则，并让你知道任何由这些规则发出的报告。

ESLint 具有高度可扩展性：这意味着你可以自定义其运行的许多方面。最常见的自定义方式有：

解析器[10]：替换 ESLint 内置的 JavaScript 解析器，以支持读取与原生 JavaScript 语法不同的代码
插件[11]：提供一组可配置的规则
共享配置[12]：为任何数量的规则提供配置选项，无论是作为独立的 npm 包还是作为_插件_的一部分

请注意，_插件_和_共享配置_是两个不同的东西。

插件使规则可用，而不配置这些规则。
共享配置配置 ESLint 自带的规则和/或之前在插件中提供的规则。

ESLint 自定义示例：TypeScript

如果你使用 ESLint 来检查 TypeScript 代码，那么你希望使用所有三种自定义：

解析器：`@typescript-eslint/parser`[13]支持解析 TypeScript 代码
插件：`@typescript-eslint/eslint-plugin`[14]加载特定于 TypeScript 的规则
共享配置：与@typescript-eslint/eslint-plugin一起打包的共享设置，可以一次性配置许多规则，例如`plugin:@typescript-eslint/recommended`[15]。

请注意，typescript-eslint 的_共享配置_来自@typescript-eslint/eslint-pluginnpm 包。因此，它们前面有plugin:前缀：这是 ESLint 知道在哪里找到配置的方式。

`eslint-config-prettier`

`eslint-config-prettier`[16]是一个_共享配置_，它禁用了与格式化相关的规则。你可以通过在 ESLint 配置中的"extends"数组中列出它来加载它：

{
  "extends": [
    // （简写为"eslint-config-prettier"）
    "prettier"
  ]
}

eslint-config-prettier的唯一目的是关闭规则。在内部，它看起来像一个对象，其中包含许多值为0或"off"的属性。大致如下：

{
  "curly": "off",
  "no-unexpected-multiline": "off",
  "@babel/object-curly-spacing": "off",
  "@typescript-eslint/lines-around-comment": "off"
}

`eslint-config-prettier` 为何出现

过去，流行的共享配置，如 `eslint-config-airbnb`[17]，经常被用来一次启用许多规则。这些配置之所以流行，是因为它们建立了一个众所周知的、有意见的风格指南和代码逻辑检查。它们的缺点是它们经常过于武断——甚至启用了格式化规则。

开发者通过知道 ESLint 按照它们在"extends"下列出的顺序评估配置来绕过这些格式化规则。eslint-config-prettier可以在项目的 ESLint 配置中最后列出，以关闭之前插件启用的任何格式化规则。

{
  "extends": [
    // 1. 配置许多ESLint规则，包括启用一些格式化规则
    "airbnb",
    // 2. 仅禁用之前配置中的格式化规则
    "prettier"
  ]
}

通过从eslint-config-prettier最后扩展，项目可以在不运行 ESLint 中的格式化规则的情况下获得那些流行共享配置的好处。

`eslint-config-prettier` 为何通常不必要

在过去几年中，ESLint 最佳实践在两个方面（以及其他方面）得到了发展：

ESLint 核心和大多数社区插件已经确定，在共享配置中启用过于武断的规则——尤其是风格化规则——会让开发者不喜欢 ESLint 而没有太多实际好处
ESLint 和 typescript-eslint 的推荐规则集已经包括了大多数有益的逻辑规则，这些规则集如eslint-config-airbnb主要用于这些规则

因此，许多新项目没有感觉到需要加载如eslint-config-airbnb这样武断的共享配置。许多项目从一个更简单的配置集开始：

开始："eslint:recommended"，ESLint 的内置推荐配置
如果使用 TypeScript："plugin:@typescript-eslint/recommended"或"plugin:@typescript-eslint/recommended-type-checked"，用于推荐的 TypeScript 规则
任何框架或库特定的插件，如`eslint-plugin-jsx-a11y`[18]的"plugin:jsx-a11y/recommended"

如果你不使用一个启用格式化规则的遗留 ESLint 共享配置，你很可能不需要eslint-config-prettier。 如果在"extends"列表末尾添加eslint-config-prettier，如果一开始没有启用格式化规则，则什么也不做。因此，大多数项目从eslint-config-prettier中没有获得任何好处。

此外，使用eslint-config-prettier冗余地使用可能会出现两个令人困惑的问题：

在 ESLint 配置中看到对prettier的引用可能会让新接触该领域的开发者感到困惑。
没有什么可以阻止项目在 ESLint 配置的"overrides"或"rules"属性下手动重新启用格式化规则。

我现在建议大多数新项目不要包含eslint-config-prettier。

💡 不确定是否可以安全地从"extends"中删除prettier？尝试删除它，然后运行npx eslint-config-prettier some/file.js，看看它是否指出了任何冲突的规则。运行 ESLint 时使用`--print-config`[19]可以打印出文件的完整列表。

`eslint-plugin-prettier`

eslint-plugin-prettier是一个 ESLint _插件_，它提供了两样东西：

一个自定义规则，prettier/prettier，它在一个 ESLint 规则中运行所有 Prettier
一个共享配置，plugin:prettier/recommended，它启用了prettier/prettier规则

例如，在 ESLint 的遗留配置格式中，你可以通过扩展其推荐配置来启用它：

{
  "extends": ["plugin:prettier/recommended"]
}

扩展该配置：

将eslint-plugin-prettier添加到扩展插件的"plugins"列表中，从而加载prettier/prettier规则
启用prettier/prettier规则
将eslint-config-prettier添加到扩展配置的"extends"列表中

这种方法的优点是你不需要单独配置 Prettier 和 ESLint。你可以有一个文件——你的 ESLint 配置——启用两者。

`eslint-plugin-prettier` 为何经常有害

eslint-plugin-prettier以eslint-plugin-prettier的方式在 ESLint 规则中运行 Prettier 有两个大问题：

行为：它将 Prettier 的报告与 ESLint 的报告合并，根据我的经验，这会让不熟悉这些工具的开发者感到困惑
性能：现在格式化被阻塞在所有 linting 上，这通常比格式化慢得多

性能点在使用类型检查规则[20]的项目中可能会变得很糟糕。

如果prettier/prettier是唯一产生包含自动修复器的报告的 lint 规则，则 linting 必须运行两次
如果任何其他规则引入自动修复，一个或多个额外的周期可能从prettier/prettier修复格式问题与那些自动修复

😬 请记住，lint 规则没有格式设置的可见性。它们的自动修复器不太可能产生与你的格式化工具对齐的代码。

类型检查的 linting 本质上通常至少与在所有 linted 文件上运行 TypeScript 类型检查器一样慢。Rust-Based JavaScript Linters: Fast, But No Typed Linting Right Now[21]解释了原因。运行额外的 linting 多次累积 - 并导致对 ESLint 和 typescript-eslint 性能的错误负面看法。

**我强烈建议你不要使用eslint-plugin-prettier。**我们在typescript-eslint 格式化常见问题解答[22]和typescript-eslint 性能故障排除文档[23]中甚至明确建议不要使用eslint-plugin-prettier。

如果prettier/prettier在你的 ESLint 配置中启用，你可以采取的最佳步骤是将其从配置中删除，并完全卸载eslint-plugin-prettier包。否则，你可以手动禁用该规则("prettier/prettier": "off"在"rules"下)。到那时，你仍然启用了eslint-config-prettier共享配置。

结论

_格式化_和_linting_是两个单独的问题。将两者混合可能会对你的开发工具的性能和可理解性产生负面影响。我的标准存储库模板，`create-typescript-app`[24]，明确将两者分开。

如果你的 ESLint 配置引用了`eslint-config-prettier`[25]，我建议你尝试将其从配置中删除。你可能不再需要它了。

如果你的 ESLint 配置引用了`eslint-plugin-prettier`[26]，我强烈建议你改用单独的 ESLint 启用 Prettier。运行prettier/prettier规则可能会给你的项目带来显著的性能问题。

无论你的 ESLint 配置启用了哪些工具，如果你已经有一段时间没有对其进行大修，我强烈建议：

确保"eslint:recommended"在你的规则扩展中
如果你使用 TypeScript：
确保至少启用了`plugin:@typescript-eslint/recommended`[27] - 或者更好的是，启用了`plugin:@typescript-eslint/recommended-type-checked`[28]
查看`create-typescript-app`[29]的`.eslintrc.cjs`[30]，查看任何适用于你项目的规则或插件
查看github.com/dustinspecker/awesome-eslint[31]，查看任何与你的项目相关的其他插件