JavaScript 格式化工具

Prettier 并不只是这个工具格式化输出的灵感来源——它就是 Prettier 这个包本身,被下载并在你的浏览器里执行,而不是通过服务器上的 Node 运行,所以结果和用同样的配置在本地运行 `npx prettier` 得到的结果逐字节一致。这个区别很重要,因为 JavaScript 格式化真的很难近似实现:要做对,需要完整地解析这门语言,而不是靠模式匹配来猜测,一个只能近似 Prettier 行为的格式化工具,恰恰会在真正重要的边界情况上——一个装饰器内部、一个复杂的泛型类型,或者一个不常见的 JSX 表达式——和项目实际的 Prettier 配置产生分歧。

JavaScript 包含好几种会让简单的"数大括号数分号"方案彻底失效的结构。模板字面量可以在反引号之间包含任意文本,包括看起来完全像代码的字符——`` `function() { return "not real code"; }` `` 是一个单独的字符串值,不是三条语句,一个不追踪模板字面量边界的格式化工具会误解它。正则表达式字面量更糟:`/{}/` 包含看起来像大括号的字符,但它们其实是正则表达式模式本身的一部分,不是结构语法。自动分号插入带来第三层难度,因为 JavaScript 在很多场合允许省略分号,靠一套规则推断一条语句在哪里结束,而一个基于逐行处理的简单格式化工具根本没办法正确复现这套规则。像 Prettier 那样真正把代码解析成语法树,才能避开这三种失败模式——一个在生产代码上哪怕只搞错其中一种情况的简易格式化工具,都是一种隐患,而不是便利。

Prettier 只格式化代码——它统一空白、换行、引号风格这类呈现层面的选择——明确不检查代码是否正确、是否类型安全,或者是否存在 bug。一个有类型错误、引用了未定义变量,或者有逻辑错误的文件,只要语法上合法,依然会被毫无怨言地格式化,因为格式化和类型检查是由不同工具处理的不同关注点。TypeScript 自己的编译器,或者像 ESLint 这样的代码检查工具,才是检查正确性的地方;这个工具的职责止步于让代码风格保持一致、易于阅读。

用制表符还是空格、单引号还是双引号、要不要分号——这些选择都不会实质影响代码的运行方式,而围绕它们的争论过去在代码审查中消耗了大量和正确性毫无关系的时间。Prettier 真正的价值主张,是把这场争论彻底从台面上移走:一套小巧、自成一派的格式化规则,自动、一致地应用在每个地方,意味着这场争论只需要在配置里解决一次,而不用在此后的每一个 PR 里反复重演。

这里暴露出来的每一个选项——缩进宽度、分号、引号风格——都对应一个真实的 Prettier 配置项,所以把来自一个已知 `.prettierrc` 配置的项目的代码粘贴进来,并匹配上同样的设置,就能复现出那个项目自己的工具链会产出的确切结果,而不需要为了看一段代码片段会被怎样格式化,而在本地安装任何东西。