Prettier 相关项目生态指南从 Linter 集成到工具链扩展的完整地图【免费下载链接】prettierPrettier is an opinionated code formatter.项目地址: https://gitcode.com/gh_mirrors/pr/prettier本文基于仓库中的 related-projects.md 官方文档整理而成。该文档是 Prettier 官方维护的相关项目索引系统梳理了围绕 Prettier 成长起来的整个工具生态包括与 ESLint、stylelint 等 Linter 的集成方案、Prettier 的 fork 分支以及覆盖并行格式化、Git 钩子、构建工具、CI/CD、浏览器与编辑器、其他语言移植等场景的周边工具。读完本文你将掌握 Prettier 生态的完整图谱能够根据自己的技术栈和团队工作流准确选出最合适的配套工具并理解官方推荐与特定场景下才建议使用的工具之间的取舍。为什么需要一份相关项目清单Prettier 是一个opinionated有主见的代码格式化器它不提供可逐条开关的格式规则而是把整个程序重新打印成一致的风格。因此在真实工程中Prettier 几乎总是与 Linter、Git 钩子、构建工具、CI 等周边设施配合使用。官方文档维护这份清单正是为了帮助用户在浩如烟海的社区项目中快速定位经过验证的方案。在深入各分类之前需要先理解一个核心分工原则。根据 comparison.md 的阐述Linter 的规则可以分成两类格式类规则如max-len、keyword-spacing、comma-stylePrettier 直接从源头消除了这一类规则的必要性——你不再需要为这些规则配置、维护或争论。代码质量规则如no-unused-vars、no-extra-bind、prefer-promise-reject-errorsPrettier 对此无能为力而这恰恰是 Linter 最有价值的部分。一句话概括用 Prettier 管格式用 Linter 抓 bug。所有相关项目都围绕这一分工展开。ESLint 集成四个方案各司其职文档将 ESLint 生态的集成工具分为四条路线它们解决的问题完全不同。eslint-config-prettier关闭与 Prettier 冲突的规则官方推荐eslint-config-prettier是一个 ESLint 共享配置作用是关闭所有与 Prettier 不必要或可能冲突的 ESLint 规则。它的哲学是各管一摊格式问题交给 PrettierESLint 只保留代码质量规则。在 integrating-with-linters.md 中这是官方明确推荐的集成方式因为它一次性解决了Linter 样式规则与 Prettier 打架的经典痛点。更有说服力的是Prettier 官方仓库自己就在使用这个方案仓库根目录的 eslint.config.js 中导入了eslintConfigPrettier并将其作为配置数组的一员同时在 package.json 中声明了eslint-config-prettier: 10.1.8开发依赖。也就是说你在自己的项目里配置eslint-config-prettier的方式与 Prettier 团队维护自身代码库的方式完全一致。从仓库的 package.json 还可以看到 Prettier 自身的 CI 流水线如何组合这些工具lint: run-p --continue-on-error \lint:*\, lint:eslint: eslint ., lint:prettier: prettier . --check --cache, fix: run-s --continue-on-error fix:eslint fix:prettier, fix:eslint: yarn lint:eslint --fix, fix:prettier: yarn lint:prettier --writelint:prettier使用prettier . --check --cache做纯检查fix:prettier追加--write做自动修复ESLint 检查与 Prettier 检查互不干扰。这正是格式化交给 Prettier、质量检查交给 ESLint分工的最佳实践样本。eslint-plugin-prettier把 Prettier 跑成 ESLint 规则eslint-plugin-prettier将 Prettier 作为一条 ESLint 规则运行把格式化差异作为一条条 ESLint issue 报告出来。它的历史价值在于当 Prettier 刚出现时项目无需搭建新基础设施直接复用已有的 ESLint 编辑器集成即可开始使用 Prettier。但 integrating-with-linters.md 明确指出这类插件如今一般不被推荐原因有三编辑器里会出现大量红色波浪线令人烦躁——Prettier 的设计初衷恰恰是让你忘记格式化的存在比直接运行 Prettier 更慢多了一层可能出问题的间接层。如今更优雅的做法是直接运行prettier . --check并且大多数编辑器都已原生支持 Prettier。prettier-eslint先格式化再eslint --fixprettier-eslint的处理流程是先把prettier的输出交给eslint --fix。当 Prettier 的输出在某个方面完全不可用时比如某些 ESLint 规则必须保留的写法被 Prettier 破坏了可以用它做二次修正。代价是明显比单独运行 Prettier 慢。这类运行 Prettier 后立刻再 lint 一遍的工具属于特定场景下才有价值的范畴。prettier-standard用 Standard 风格规则格式化prettier-standard组合使用prettierx见下文 Forks 一节和prettier-eslint目标是让格式化结果符合standard代码风格规则。适合希望同时享受 Prettier 的自动格式化能力和 Standard 风格约定的团队。stylelint 集成CSS 世界的同构方案CSS/SCSS/Less 等样式语言场景与 ESLint 场景高度同构因此存在一一对应的三个工具stylelint-config-prettier关闭所有与 Prettier 不必要或冲突的 stylelint 规则与eslint-config-prettier定位相同也是官方推荐的组合方式。stylelint-prettier把 Prettier 作为 stylelint 规则运行差异报告为 stylelint issue同样属于作为 Linter 规则运行 Prettier的模式优缺点与eslint-plugin-prettier一致。prettier-stylelint把prettier输出交给stylelint --fix是prettier-eslint在样式领域的对应物。这三个工具与 ESLint 四件套形成了清晰的映射关系选择逻辑可以完全复用上一节的判断标准优先stylelint-config-prettier这种关闭冲突规则的方案把格式职责彻底交给 Prettier。Forks更少主见的 Prettier 分支prettierx一个不那么有主见less opinionated的 Prettier fork。Prettier 的核心设计哲学就是强制的统一风格而 prettierx 通过开放更多配置选项满足那些希望保留更多个人/团队风格控制权、又不愿放弃自动格式化的用户。需要留意的是fork 意味着它不会与 Prettier 主线的更新自动保持同步选择它需要承担一定的跟进成本。Misc其余生态工具全景文档将剩下的工具归入 Misc 分类它们覆盖了 Prettier 使用体验的各个侧面可以按场景进一步归类提速方向并行与常驻服务parallel-prettier微软出品的替代 CLI通过并行格式化文件来加速大型项目。当仓库规模达到数万文件时单线程逐文件格式化会成为瓶颈这正是它的用武之地。prettier_d把 Prettier 作为常驻服务运行避免每次调用都支付 Node.js 启动开销。适合频繁、多次小批量调用 Prettier 的场景比如编辑器保存时触发。Git 工作流只格式化变更的文件pretty-quick只格式化有变更的文件是官方文档在 precommit.md 中与simple-git-hooks搭配推荐的 pre-commit 方案之一。该文档给出了完整的安装配置流程例如npm install --save-dev simple-git-hooks pretty-quick node --eval fs.writeFileSync(.simple-git-hooks.json,JSON.stringify({pre-commit:npx pretty-quick --staged},undefined,2)\n) npx simple-git-hooks配合--staged参数pretty-quick只处理git add过的暂存文件让提交前自动格式化成为可能。在 precommit.md 中它被描述为需要对变更/暂存文件做整文件格式化时的最佳选择与lint-staged适合同时跑多个质量工具、支持git add --patch部分暂存形成互补。构建与测试流程rollup-plugin-prettier允许在 Rollup 打包流程中使用 Prettier适合需要在产物输出前统一格式的发布管线。jest-runner-prettier把 Prettier 作为 Jest runner 运行将格式化检查纳入 Jest 测试体系方便已经重度依赖 Jest 的团队。spotless从 Gradle 或 Maven 中调用 Prettier让 Java 生态的项目也能在构建阶段享受 Prettier 格式化适合多语言仓库中 Java 与 JS/TS 共存、希望统一构建工具的团队。浏览器与编辑器内嵌prettier-chrome在浏览器中运行 Prettier 的扩展适合在线代码编辑、Playground 类产品。monaco-prettier把 Prettier 集成进 Monaco 编辑器VS Code 的编辑器内核。如果正在构建基于 Monaco 的在线 IDE这是把格式化能力嵌入产品的现成方案。仓库内 website/playground 这样的浏览器端格式化场景正是这类能力的用武之地。CI/CD 与代码审查reviewdog-action-prettier在 GitHub Actions CI/CD 工作流中运行 Prettier并通过 reviewdog 在 Pull Request 上直接标注格式问题。官方文档 ci.md 也展示了在 GitHub Actions 中通过 autofix.ci 自动应用prettier . --write修复的完整 workflow 配置两者可以按团队偏好选择自动修复或PR 评论提示两种模式。MegaLinter开源的 Linter 聚合器开箱即用地内置运行 Prettier适合希望用一个 CI 组件统一管理多种语言多种 Linter 的团队。其他语言的移植csharpierPrettier 的 C# 移植版本让 .NET 开发者获得与 Prettier 类似的格式化体验。PrettierSwift 版基于 Prettier 的 Swift 实现面向 Swift 生态。这两者说明 Prettier 的重新打印 AST设计思想已被多个语言社区借鉴但它们是独立项目能力与维护节奏以各自项目为准。选择指南何时用哪个综合 related-projects.md 与 integrating-with-linters.md可以给出如下决策框架场景推荐工具理由ESLint Prettier 共存eslint-config-prettier官方推荐关闭冲突规则各司其职stylelint Prettier 共存stylelint-config-prettier同上面向样式语言只想在编辑器里看到格式问题直接prettier --check 编辑器插件比 linter 插件更快、更安静Prettier 输出在某方面不可用prettier-eslint / prettier-stylelint用eslint --fix/stylelint --fix二次修正接受变慢大型仓库提速parallel-prettier / prettier_d并行或常驻进程消除瓶颈提交前只格式化变更文件pretty-quick配合 simple-git-hooks见 precommit.md 完整配置需要更少主见的格式化器prettierxfork 提供更多配置项需自行跟进更新需要特别强调官方给出的警示在网络上搜索Prettier 某个 Linter时还会遇到更多相关项目它们一般不被推荐但在特定情境下可能有用。判断的标准始终回到分工原则——Prettier 负责格式化Linter 负责代码质量任何试图让两者职责重叠的工具都要评估其额外成本速度、间接层、编辑器噪音。总结Prettier 的价值不仅在于格式化器本身更在于它催生的这套完整生态related-projects.md 就是官方为这份生态绘制的地图。从最常用的eslint-config-prettierPrettier 仓库自己在 eslint.config.js 中就用它来维持自身代码库的干净到面向特殊场景的并行化、Git 钩子、CI、编辑器内嵌乃至其他语言移植工具每个项目都对应一个具体的使用场景。理解这张地图就能在为团队搭建格式化流水线时既选对工具也避免踩进工具职责重叠的常见陷阱。【免费下载链接】prettierPrettier is an opinionated code formatter.项目地址: https://gitcode.com/gh_mirrors/pr/prettier创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考