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

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

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

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

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

回顾：ESLint 自定义

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

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

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

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

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

ESLint 自定义示例：TypeScript

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

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

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

eslint-config-prettier

eslint-config-prettier是一个共享配置 ，它禁用了与格式化相关的规则。你可以通过在 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，经常被用来一次启用许多规则。这些配置之所以流行，是因为它们建立了一个众所周知的、有意见的风格指南和代码逻辑检查。它们的缺点是它们经常过于武断------甚至启用了格式化规则。

开发者通过知道 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这样武断的共享配置。许多项目从一个更简单的配置集开始：

1. 开始："eslint:recommended"，ESLint 的内置推荐配置
2. 如果使用 TypeScript："plugin:@typescript-eslint/recommended"或"plugin:@typescript-eslint/recommended-type-checked"，用于推荐的 TypeScript 规则
3. 任何框架或库特定的插件，如eslint-plugin-jsx-a11y的"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可以打印出文件的完整列表。

eslint-plugin-prettier

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

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

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

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

扩展该配置：

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

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

eslint-plugin-prettier 为何经常有害

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

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

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

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

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

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

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

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

结论

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

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

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

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

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

💡 Configuring ESLint, Prettier, and TypeScript Together是我的一篇博客文章，更详细地介绍了如何配置这些工具。

祝大家快乐 linting！🎉

致谢

非常感谢Anisha Malde建议我写一篇关于这个领域的解释文章，并帮助构思内容。谢谢！🙌

感谢Ben Scott，eslint-config-prettier的维护者之一，审阅了这篇文章，并建议了如何描述eslint-plugin-prettier的澄清和更正。

感谢Simon Lydell，eslint-config-prettier的原始创建者和长期维护者，审阅了这篇文章，并建议了npx eslint-config-prettier方法。

我们还应该注意到，尽管我个人不同意现在使用eslint-config-prettier和eslint-plugin-prettier，但它们多年来一直是合法有用的工具，非常感谢所有贡献者和维护者！

参考地址：www.joshuakgoldberg.com/blog/you-pr...