Prettier 集成深度解析

## 关于代码格式化工具 Prettier 的一些个人看法

在项目里写代码，时间长了总会遇到一些让人头疼的小问题。比如团队里每个人对代码格式的偏好不太一样，有的人喜欢在逗号后面加个空格，有的人觉得不加更清爽；有的人习惯把很长的函数调用拆成好几行，有的人则倾向于全部挤在一行里。这些差异本身没什么对错，但混在一起就容易让代码库看起来有点杂乱，每次代码评审总要花不少时间讨论缩进和换行，挺浪费精力的。

Prettier 这个东西，就是专门来解决这类问题的。它不是又一个告诉你“应该怎么写”的代码风格检查工具，而是一个直接动手帮你“重写”格式的工具。你可以把它想象成一个非常固执的、有强迫症的排版助手。你只管把代码的逻辑写对，写完之后交给它，它就会按照一套预设的、非常严格的规则，把代码的排版整理得整整齐齐。它处理的范围很广，从前端的 JavaScript、JSX、CSS，到后端的 Java、PHP，甚至 Markdown 和 YAML 文件，它都能照顾到。

它的工作方式很直接。你可以在编辑器里安装它的插件，这样每次保存文件时，它就会自动运行，瞬间把当前文件的格式整理好。你也可以在项目的构建流程里加入一个检查步骤，确保提交到仓库的代码都是经过它格式化过的。这样一来，整个代码库的样式就统一了，像是出自同一个人之手。这带来的好处很明显，团队成员再也不用为代码样式争论，可以把注意力完全集中在逻辑和设计上。代码评审时，一眼看过去清清爽爽，修改了什么功能一目了然。

开始用 Prettier 并不复杂。通常是在项目根目录下新建一个名为.prettierrc的配置文件。这个文件可以是空的，空文件就意味着使用它所有默认的规则。当然，你也可以在里面写上几行，覆盖掉一两个你实在无法接受的默认设置，比如把默认的双引号改成单引号，或者把行宽从 80 个字符调整到 100。配置好后，通过 npm 或 yarn 安装它，然后在package.json的脚本里加一条命令，比如"format": "prettier --write ."。运行这个命令，它就会格式化项目里所有它能识别的文件。更常见的做法是把它的插件集成到 VS Code 这样的编辑器里，并开启“保存时格式化”选项，这样每按一次保存键，就是一次无形的格式整理，非常自然。

关于怎么用好它，有些经验之谈。首先，最好在项目一开始就引入它，而不是等代码已经堆积了成千上万行之后再上。对一个已有的大项目做全局格式化，虽然技术上就是一条命令的事，但这会产生一个巨大的、只包含空格和换行修改的提交，这可能会暂时搞乱git blame这样的历史追溯功能。如果一定要在中期引入，可以考虑分模块、分批次地进行格式化。其次，那个配置文件.prettierrc最好也提交到版本控制里，确保团队里每个人、以及持续集成服务器，用的都是同一套规则。最后，可以把它和 Git 的“预提交钩子”结合起来，用husky和lint-staged这样的工具，在每次提交前，自动只格式化那些被改动了的文件，这样既保证了入库代码的整洁，又不会产生上面提到的那种巨型提交。

市面上做代码风格管理的工具不止它一个，比如 ESLint 就非常有名。这里有个挺关键的区别。ESLint 主要是一个“检查”工具，它的核心是发现代码中潜在的问题，比如使用了未定义的变量，或者一些可能引发错误的不佳实践。虽然它也有一定的自动修复能力，但它的规则更多、更复杂，很多是关于代码质量的。而 Prettier 的定位非常纯粹，它只关心“格式”，也就是代码看起来的样子，对代码的逻辑对错毫不关心。它们俩并不冲突，反而是绝佳的搭档。一个常见的组合是：用 Prettier 管好所有格式问题，然后用 ESLint 专注于发现代码质量问题。在配置时，只需要通过eslint-config-prettier这个包，关掉 ESLint 中所有和格式相关的规则，让它们各司其职，就不会有冲突了。

说到底，Prettier 的价值在于它把“代码风格”这个主观的、容易引发讨论的话题，变成了一个客观的、自动化的工程问题。它用一点点的“固执”，换来了团队在代码外观上的一致性，从而释放了更多本应用于创造性工作的精力。它不教你如何写出更好的算法，但它能确保你写出的任何算法，看起来都足够清晰和专业。