Prettier 与 Linter 的分工边界格式化交给 PrettierBug 检测交给 Linter【免费下载链接】prettierPrettier is an opinionated code formatter.项目地址: https://gitcode.com/gh_mirrors/pr/prettierPrettier 是有主见opinionated的代码格式化器它从不试图替代 ESLint、TSLint、stylelint 等 linter两者分属完全不同的职责。本文基于仓库中 comparison.md即网站版本化文档 website/versioned_docs/version-stable/comparison.md展开先拆解 linter 规则的两大类别再从 Prettier 源码层面解释从头重印整个程序为何能让格式化规则彻底失业最后给出--check落地 CI 以及与 ESLint/stylelint 集成的最佳实践。读完你将明确团队中 Prettier 与 linter 各自该管什么、如何配置才不会互相冲突。Linter 规则的两大类别文档开篇就给出了一个非常清晰的框架linter 的规则可以分成两类而 Prettier 只与其中一类发生关系。格式化规则Formatting rules这类规则关心的是代码长得怎么样例如max-len限制单行最大长度no-mixed-spaces-and-tabs禁止混用空格与制表符缩进keyword-spacing统一关键字如if、return两侧的空格comma-style统一逗号的书写位置行尾还是行首。Prettier 让这一整类规则全部变得不再必要。因为 Prettier 会把整个程序从头重新打印一遍reprint the entire program from scratch并以完全一致的方式输出程序员根本不可能再在这种地方犯错——空格放错位置、换行不一致、逗号风格不统一这类问题在 Prettier 的模型里压根不会产生。这里的关键在于 Prettier 的定位Prettier is not a rule-based tool: it has no individual formatting rules that you can enable or disable. It reprints your whole program from scratch instead.Prettier 不是基于规则的工具它没有一条条可以单独开启或关闭的格式化规则。这也正是它与其他所有样式检查器在架构层面最根本的分野。代码质量规则Code-quality rules这类规则关心的是代码有没有问题例如no-unused-vars发现声明了却从未使用的变量no-extra-bind检测多余的bind调用no-implicit-globals防止在全局作用域意外创建隐式全局变量prefer-promise-reject-errors要求Promise.reject必须传Error对象。Prettier 对这类规则毫无帮助也无意帮助。文档明确指出这类规则恰恰是 linter 提供的最重要的能力——因为它们很可能真的帮你抓到代码里的 Bug。格式化类规则抓不到逻辑错误而代码质量规则能。所以结论可以浓缩成一句话用 Prettier 管格式化用 linter 抓 Bug从头重印不是口号看 Prettier 源码里的真实管线要理解为什么 Prettier 能让格式化规则集体失业最好的方式是从源码看它到底是怎么工作的。Prettier 的格式化主流程位于 src/main/core.js 的coreFormat函数其核心三步恰好就是从头重印的实现证据解析parseText(originalText, opts)将源码解析成抽象语法树AST转 DocprintAstToDoc(ast, opts)遍历 AST把它转换成一种称为 Doc 的中间表示。Doc 由 src/document/builders/ 目录下的group、indent、line、if-break等构建器拼装而成它描述的是这段代码在不同宽度下应该怎么断行、怎么缩进打印printDocToStringWithoutNormalizeOptions(doc, opts)由 src/document/printer/printer.js 负责把 Doc 最终渲染成字符串输出。注意第三步的输入不再是你写的原始文本而是由 AST 生成的 Doc。换句话说你的输入只是被解析后当作语义来源最终输出的样式完全由 Prettier 的打印器决定——这就是文档所说reprints your whole program from scratch的落地实现。由此可以引申出几个推论只要 AST 相同写法千奇百怪的代码都会被重印成同一种样子因此max-len、keyword-spacing、comma-style这类规则永远无案可查Prettier 没有规则开关的概念因为它根本没有逐条生效的规则表——整个打印策略是一体的这也决定了你无法只保留某一种格式化行为而关闭另一种正因为是整体重印Prettier 能保证输出再次格式化后保持不变幂等性。CLI 的--debug-check正是利用这一性质做自检它会把结果再格式化一遍并与第一次输出比较若不一致即报错见 src/cli/format.js。代码质量检测Linter 不可替代的职责既然 Prettier 对代码质量规则什么都不做那么 lint 仍然是你工程体系里的刚需。no-unused-vars能抓住删除重构后遗留的死变量no-extra-bind能提示不必要的性能开销prefer-promise-reject-errors能阻止吞掉错误堆栈的坏习惯——这些都是格式化工具永远无法提供的能力。文档对此的措辞非常坚定代码质量规则是 linter 提供的最重要的规则因为它们likely to catch real bugs。所以不要试图用 Prettier 的配置文件去模拟这些检查Prettier 的选项空间里也根本没有它们的位置——这恰好与 option-philosophy.md 中Prettier 选项已被冻结、不再接受新增选项请求的原则一致。格式化争议应该被消除而不是被转移到选哪个选项上而 Bug 检测则始终是 ESLint 这类工具的专属战场。落地实践CI 中如何用--check守好格式化这条线分工清楚了剩下的问题就是怎么执行。在 CI 里你不应该让 Prettier改代码而应该让它检查代码并让构建失败——这正是prettier --check的用途配合prettier --write在本地一键修复。以仓库中的 CLI 实现为例src/cli/format.js 的listDifferent函数会调用prettier.check(input, options)而 API 层的实现极简见 src/index.jsasync function check(text, options) { return (await format(text, options)) text; }即格式化后与原文本是否完全相等。由此可总结出--check的完整行为特征依据 src/cli/format.js场景CLI 输出进程退出码所有文件都已符合 Prettier 风格All matched files use Prettier code style!0存在未格式化的文件逐行列出文件名并提示Code style issues found in X files. Run Prettier with --write to fix.1存在解析错误 / 无法识别的文件输出错误信息2基于此一个典型的 CI 检查命令是npx prettier --check .而本地修复则运行npx prettier --write .配合.prettierignore见 ignore.md排除不需要格式化的目录以及 configuration.md 中的配置文件如.prettierrc或prettier.config.jsPrettier 就能在你打开 PR 之前把格式问题全部拦截在本地。更完整的 CLI 参数说明可参考 cli.md。与 Linter 的三种集成姿势文档在 integrating-with-linters.md 中系统梳理了让 Prettier 与 linter 共存的三种方案按推荐程度排序1. 官方推荐eslint-config-prettier关闭冲突规则linter 里绝大多数风格类规则在使用 Prettier 后不仅多余更糟糕的是它们可能与 Prettier 冲突——Prettier 刚把代码重印成自己的风格linter 的样式规则可能又判它违规形成互相打架的死循环。eslint-config-prettier的作用就是一次性关闭所有与 Prettier 冲突或已无必要的规则。这是官方推荐路线配置一次即可长期省心。2. 不推荐但存在eslint-plugin-prettier / stylelint-prettier把 Prettier 当 lint 规则跑这类插件让你在 linter 内部以 lint 规则的形式运行 Prettier。在 Prettier 诞生初期这种方案可以复用已有的 linter 编辑器集成、不用搭新基础设施确实有用但如今可以直接运行prettier --check .且大多数编辑器已原生支持 Prettier这类插件的价值已经大打折扣。文档明确指出它们的缺点编辑器里会出现大量红色波浪线非常烦人——Prettier 的本意是让你忘记格式化的存在而不是成天提醒你比直接运行 Prettier 慢多了一层间接层多了一个可能出错的地方。3. 兜底方案prettier-eslint / prettier-stylelint先格式化再 lint这类工具先跑prettier紧接着对输出再跑eslint --fix。如果你对 Prettier 输出的某些方面实在无法接受可以用eslint --fix再修一轮。缺点是这类工具比单纯运行 Prettier慢得多应视为特殊情况下的兜底而非常规路线。总结一条清晰的分工边界回到 comparison.md 的核心结论Prettier 负责格式化linter 负责抓 Bug。格式化规则max-len、no-mixed-spaces-and-tabs、keyword-spacing、comma-style等交给 Prettier从源码管线看它会解析成 AST、生成 Doc 并整体重印输出让你无从犯错代码质量规则no-unused-vars、no-extra-bind、no-implicit-globals、prefer-promise-reject-errors等交给 linter因为它们能抓到真实 Bug落地时用prettier --check进 CI、prettier --write修本地用eslint-config-prettier关闭冲突的风格规则避免两套工具互相打架。这条边界背后是 Prettier 选项越少越好、格式化战争越少越好的 option-philosophy.md 设计哲学以及为团队终结无休止的风格争论的初心见 why-prettier.md。理解了它你就理解了 Prettier 在整套工程质量体系中的准确位置——它不抢 linter 的饭碗它只是让 linter 更专注地去做真正重要的事。【免费下载链接】prettierPrettier is an opinionated code formatter.项目地址: https://gitcode.com/gh_mirrors/pr/prettier创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考