【工程化】代码世界的“纪律委员”：ESLint 与 Prettier 的协同作战

【工程化】代码世界的“纪律委员”：ESLint 与 Prettier 的协同作战

所属专栏： 《前端小技巧集合：让你的代码更优雅高效》
上一篇： 【TypeScript】TypeScript 的灵魂：深入理解泛型编程的强大威力
作者： 码力无边

✨ 引言：那场关于“单引号还是双引号”的“圣战”，是时候结束了

嘿，各位在代码世界里追求秩序与和谐的道友们，我是码力无边！

在我们的前端团队协作中，除了技术方案的讨论，有一种“争论”似乎永远不会停歇，甚至能上升到“信仰”的高度。我们称之为——代码风格之战。

• 张三（坚定的双引号党）：“JavaScript 的字符串，当然要用双引号，这才是正统！”
• 李四（优雅的单引号派）：“呵，单引号简洁明了，少按一次 Shift 键，不香吗？”
• 王五（末尾分号守护者）：“我无法忍受一行代码的末尾没有分号，这就像一句话没有句号，浑身难受！”
• 赵六（自由不羁派）：“分号？那是上个时代的束缚。ASI (自动分号插入) 才是未来！”

这样的“圣战”，小到缩进用两个空格还是四个空格，大到 if 语句的大括号要不要换行，几乎可以在任何一个团队里点燃“战火”。这些争论不仅浪费时间，影响团队情绪，更糟糕的是，它导致了代码库的风格混乱不堪，一个文件里可能同时存在多种“方言”，给后续的阅读和维护带来了巨大的心智负担。

除了风格问题，还有更深层次的代码质量问题：

• 某个同事不小心定义了一个变量，但从未使用过。
• 有人在 useEffect 的依赖项里，忘记添加了某个变量。
• if ( a = b ) 这样的手误，本意是比较，却写成了赋值。

这些潜在的 bug 和坏味道，光靠 Code Review 是很难完全发现的。

为了终结这场无休止的“战争”，并建立起一道坚不可摧的“代码质量防线”，前端工程化为我们派来了两位“纪律委员”，它们就是大名鼎鼎的 ESLint 和 Prettier。

然而，很多人常常混淆它俩的职责，或者在配置时让它俩“打架”。今天，码力无边就将带你彻底理清这两位“委员”的关系，让你学会如何配置它们，让它们像一对配合默契的“黄金搭档”一样，协同作战，自动地为你的代码库带来秩序、规范与和平。

一、职责分明：谁是“质量警察”，谁是“风格造型师”？

要让它们完美协作，首先必须明确它们各自的分工。它们解决的是不同维度的问题。

ESLint：代码世界的“质量警察”

• 核心职责：代码质量检查 (Linting)。
• 工作内容：ESLint 会深入分析你的代码的语法和逻辑（AST - 抽象语法树），然后根据你配置的一系列规则 (rules)，来发现潜在的问题和 bug。
• 执法范围：
  • 发现潜在错误：比如，使用了未声明的变量、在 switch 语句中缺少 break、不允许出现 debugger 语句等。
  • 强制最佳实践：比如，推荐使用 === 而不是 ==、禁止使用 var 等。
  • 检查 Hooks 规则：eslint-plugin-react-hooks 插件可以检查你是否在循环中调用了 Hook，或者 useEffect 的依赖项是否完整。
  • 也管一部分风格：ESLint 的规则库里，也包含了很多关于代码风格的规则，比如引号类型、分号、缩进等。而这，正是它与 Prettier 职责重叠、可能产生冲突的地方。

一句话总结：ESLint 主要关心你的代码“写得对不对，好不好”。

Prettier：代码世界的“首席风格造型师”

• 核心职责：代码格式化 (Formatting)。
• 工作内容：Prettier 对你的代码逻辑毫不关心。它只有一个目标：拿过你的代码，忽略掉你原本所有的风格，然后按照它自己的一套（或者你配置的）固定的、有主见的 (opinionated) 风格，重新“打印”出一份格式完全统一的代码。
• 执法范围：
  • 代码宽度：自动在合适的时机换行，保证代码不超过设定的最大宽度。
  • 引号：统一使用单引号或双引号。
  • 分号：在所有语句末尾添加或删除分号。
  • 逗号：在对象或数组的末尾添加尾逗号。
  • 空格、缩进、括号…… 所有关乎“代码长相”的事情，它都管。

一句话总结：Prettier 只关心你的代码“长得好不好看”。

二、协同作战：让“警察”和“造型师”成为朋友

既然 ESLint 也管风格，Prettier 也管风格，那它俩一起工作时，岂不是会“打架”？比如，ESLint 要求你用双引号，而 Prettier 却固执地把它格式化成单引号，来回拉扯，永无宁日。

这正是配置这对“黄金搭档”的关键所在：让它们分工明确，避免职责重叠。

协同原则：

1. 代码质量：完全交给 ESLint 负责。
2. 代码风格：完全交给 Prettier 负责。
3. 解决冲突：利用工具，把 ESLint 中所有与代码风格相关的规则全部禁用掉，让它专心做“质量警察”，不再对“穿着打扮”指手画脚。

配置步骤（以 VS Code + 现代前端项目为例）

Step 1: 安装依赖

# 安装 ESLint 和 Prettier 核心pnpm add -D eslint prettier# 安装解决冲突的两个关键包# eslint-config-prettier: 禁用 ESLint 中与 Prettier 冲突的风格规则# eslint-plugin-prettier: 将 Prettier 的规则作为 ESLint 的规则来运行，# 这样不符合 Prettier 风格的代码，会在 ESLint 检查时直接报错pnpm add -D eslint-config-prettier eslint-plugin-prettier# (可选但强烈推荐) 安装你需要的 ESLint 配置和插件# 比如，用于 TypeScript 和 React 的pnpm add -D @typescript-eslint/parser @typescript-eslint/eslint-plugin eslint-plugin-react eslint-plugin-react-hooks

Step 2: 配置 .eslintrc.cjs (或 .js, .json)
这是告诉 ESLint 如何工作的“警局规章”。

// .eslintrc.cjsmodule.exports = { parser: \'@typescript-eslint/parser\', // 使用 TS 解析器 extends: [ \'eslint:recommended\', \'plugin:react/recommended\', \'plugin:@typescript-eslint/recommended\', \'plugin:react-hooks/recommended\', // 关键！这一项必须放在最后！ // 它会覆盖掉前面所有配置中与 Prettier 冲突的规则 \'plugin:prettier/recommended\', ], plugins: [\'react-refresh\'], rules: { // 在这里可以自定义你的 ESLint 规则 // 比如，你想关闭某个规则 \'@typescript-eslint/no-explicit-any\': \'off\', // 或者修改某个规则的严重级别 \'react/react-in-jsx-scope\': \'off\', \'react-refresh/only-export-components\': \'warn\', // Prettier 的规则会在这里被 eslint-plugin-prettier 启用 // 如果有不符合 Prettier 的格式，ESLint 会报错 }, // ... 其他配置};

核心就在于 extends 数组中的 \'plugin:prettier/recommended\'，它其实是 eslint-config-prettier 和 eslint-plugin-prettier 的一个快捷方式，帮你完成了“禁用 ESLint 风格规则”和“启用 Prettier 规则校验”两件大事。

Step 3: 配置 .prettierrc (或 .js, .json)
这是告诉 Prettier 如何打扮你的代码的“造型指南”。

// .prettierrc{ \"semi\": true, \"singleQuote\": true, \"trailingComma\": \"es5\", \"printWidth\": 100, \"tabWidth\": 2, \"arrowParens\": \"always\"}

Prettier 的配置项很少，因为它本身就是“有主见的”。

Step 4: 配置 VS Code (或其他编辑器)
让编辑器在你保存文件时，自动帮你“执法”。

1. 安装 VS Code 插件：ESLint 和 Prettier - Code formatter。
2. 打开 VS Code 的设置 (settings.json)，添加以下配置：

   { \"editor.formatOnSave\": true, // 开启保存时自动格式化 \"editor.defaultFormatter\": \"esbenp.prettier-vscode\", // 将 Prettier 设置为默认格式化器 \"editor.codeActionsOnSave\": { // 开启保存时自动执行 ESLint 修复 \"source.fixAll.eslint\": true }}

大功告成！ 现在，当你写代码时：

• 如果你写了有潜在 bug 或不符合最佳实践的代码（比如忘记 useEffect 依赖），ESLint 插件会实时地在你编辑器里划出红线警告你。
• 当你按下 Ctrl + S (保存) 时：
  • Prettier 会首先“暴力”地将你的代码重新格式化，解决所有风格问题。
  • 然后，ESLint 会进行 --fix 操作，自动修复那些它可以修复的质量问题（比如自动删除未使用的 import）。

从此，你的团队再也不用为代码风格而争吵，所有的代码在提交前，都已经被两位“纪律委员”严格地审查和打理过了。

三、结合 Git Hooks：建立最后的防线

为了防止有人没有配置好编辑器就提交了不规范的代码，我们还可以在 git commit 之前，设置一道“门禁”。这就是 Git Hooks。

我们可以使用 husky 和 lint-staged 这两个库来轻松实现：

• husky: 让你能轻松地在项目中配置 Git Hooks。
• lint-staged: 让你只对那些被 git add 到暂存区的文件，执行 lint 和 format 操作，而不是对整个项目，速度极快。

配置过程（简述）：

1. 安装：pnpm add -D husky lint-staged
2. 初始化 Husky: npx husky install
3. 在 package.json 中添加 lint-staged 的配置：

   \"lint-staged\": { \"*.{js,jsx,ts,tsx}\": [ \"eslint --fix\", \"prettier --write\" ]}

4. 添加 pre-commit hook: npx husky add .husky/pre-commit \"npx lint-staged\"

现在，每当有人执行 git commit 时，husky 就会触发 pre-commit 钩子，lint-staged 会自动对暂存区的文件执行 ESLint 修复和 Prettier 格式化。如果不规范的代码无法被自动修复，commit 过程就会被中断，从而强制保证了所有进入代码库的代码都是干净、规范的。

写在最后：自动化是团队协作的基石

ESLint 和 Prettier，以及与之配套的自动化流程，是现代前端工程化体系中不可或-缺的一环。它们带来的价值，远不止是“让代码变好看”那么简单。

• 它们节省了 Code Review 中最宝贵的时间和精力，让团队可以专注于更高层次的架构和逻辑问题，而不是反复纠结于分号和引号。
• 它们降低了新成员融入团队的门槛，新人无需死记硬背长篇的《代码规范文档》，只需跟着工具的提示走，就能自然地写出符合团队规范的代码。
• 它们通过自动化的方式，将“规范”内化为了团队的“肌肉记忆”，从根本上提升了整个项目的代码质量和长期可维护性。

所以，道友们，如果你所在的团队还在为代码风格而“内耗”，或者还在为代码质量问题而头疼，那么请立刻行动起来，请来 ESLint 和 Prettier 这两位“纪律委员”，让自动化和规范，成为你们团队协作最坚实的基石。

专栏预告与互动：

我们已经为代码质量建立了坚固的防线。但在前端开发中，调试是另一项与我们形影不离的核心技能。console.log 虽然好用，但它只是调试世界的“冰山一角”。

下一篇，我们将深入 Chrome DevTools 的奇妙世界，学习除了 console.log 之外，还有哪些能让你的调试效率翻倍的“魔法”，比如条件断点、日志断点、以及各种 console 的高级用法！

感觉码力无边的“纪律委员”组合拳让你对代码规范有了全新的认识？别忘了点赞、收藏、关注，你的每一次支持，都是我分享更多“工程化秘籍”的强大动力！

今日论道： Prettier 的核心理念是“有主见的 (opinionated)”，它提供的配置项非常有限，这是为了避免新的风格争论。你喜欢这种“专制”的风格，还是更倾向于像 ESLint 一样提供海量可配置的规则，让团队拥有更高的自由度？在评论区分享你的看法，我们一起探讨！