每个开发团队都有类似的故事。一个 pull request 挂在那里半天没动。不是因为逻辑有问题或 API 契约变了，而是因为两个评审员在争论对象字面量是否需要尾随逗号。讨论串越来越长。有人发了一个风格指南链接。另一个人用另一个指南反驳。等到代码合并时，所有参与者都已经失去了他们原本要构建的功能的上下文。
这些争论代价高昂。它们消耗了高级工程师数小时的时间，在队友之间制造了轻微的怨恨，并误导初级开发者认为软件工程主要就是为了在分号问题上赢得争论。最糟糕的是？产品并不关心这些。你的用户永远不会注意到空格还是制表符。他们只会注意到你因为忙于争论引号而没能修复的 bug。
一致性确实很重要。看起来像是由同一个人编写的代码库更容易阅读、更容易评审、也更容易调试。错误在于试图通过人工来强制执行这种一致性。
将枯燥的工作自动化
解决方法很简单。完全将格式化从人类判断中剥离出来。交给那些没有自我意识且不会疲倦的工具。
三个工具可以干净利落地处理这个问题。
Prettier 会自动对你的代码进行重新格式化。它不需要征求许可。你不再需要考虑行宽、引号风格，或者如何将一个长函数签名拆分到多行。你只需保存文件，Prettier 就会使其保持一致。
ESLint 处理 Prettier 不会触及的问题。它能捕获未使用的变量、无法触及的代码、React hooks 中缺失的依赖项，以及历史上会导致 bug 的模式。如果配置得当，它会避开格式化问题，专注于实际的代码质量。
Husky 会安装一个 pre-commit hook，在自动化检查通过之前，阻止任何内容进入你的代码库。它将你的 Git 流水线变成了一个把关者，而不是一个建议箱。
它们共同形成了一个紧密的闭环。你在本地可以随心所欲地编写代码。当你提交时，工具会对代码进行清理和检查。只有通过后，代码才会离开你的机器。
为什么这个特定的技术栈有效
你可以花几周时间手动调整 ESLint 规则。请抵制这种冲动。这里的目标是停止争论风格，而不是创造一个新的“风格指南策展人”全职工作。
Prettier 的设计是有意带有“主见”的。它提供的配置选项有限，因为每一个选项都可能引发未来的争论。它的默认设置是合理的。选择一小部分覆盖项，写下来，然后继续前进。
如果让 ESLint 自由发挥，它会试图同时强制执行代码质量和格式化规则（如分号的使用和缩进大小）。这会与 Prettier 产生冲突，因为两个工具都会尝试编辑相同的字符。eslint-config-prettier 包通过禁用所有与 Prettier 冲突的 ESLint 规则解决了这个问题。这种职责分离至关重要。Prettier 负责外观，ESLint 负责逻辑。
仅在持续集成（CI）中运行检查太晚了。等到 CI 失败时，你已经提交了混乱的代码，切换到了另一个任务，甚至可能已经开启了一个 pull request。修复它需要另一次提交、另一次推送、另一次等待周期。Husky 将这个反馈循环缩短到了几秒钟。lint-staged 通过仅针对你实际修改的文件运行工具，而不是在每次提交时扫描整个代码库，从而提高了速度。
分步设置
以下设置针对现代 JavaScript 或 React 项目，但通过微调也可以应用于 TypeScript、Vue 或 Node。请在项目根目录下运行每一步。
首先将所有内容作为开发依赖进行安装：
npm install -D prettier eslint husky lint-staged eslint-config-prettier