企业官网建设流程全解析

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-style）：Prettier 直接从源头消除了这一类规则的必要性——你不再需要为这些规则配置、维护或争论。
• 代码质量规则（如no-unused-vars、no-extra-bind、prefer-promise-reject-errors）：Prettier 对此无能为力，而这恰恰是 Linter 最有价值的部分。

一句话概括：用 Prettier 管格式，用 Linter 抓 bug。所有相关项目都围绕这一分工展开。

ESLint 集成：四个方案各司其职

文档将 ESLint 生态的集成工具分为四条路线，它们解决的问题完全不同。

eslint-config-prettier：关闭与 Prettier 冲突的规则（官方推荐）

eslint-config-prettier是一个 ESLint 共享配置，作用是关闭所有与 Prettier 不必要或可能冲突的 ESLint 规则。它的哲学是"各管一摊"：格式问题交给 Prettier，ESLint 只保留代码质量规则。

在 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 --write"

lint: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 明确指出，这类插件如今一般不被推荐，原因有三：

1. 编辑器里会出现大量红色波浪线，令人烦躁——Prettier 的设计初衷恰恰是让你忘记格式化的存在；
2. 比直接运行 Prettier 更慢；
3. 多了一层可能出问题的间接层。

如今更优雅的做法是直接运行prettier . --check，并且大多数编辑器都已原生支持 Prettier。

prettier-eslint：先格式化再eslint --fix

prettier-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 的团队。

其他语言的移植

• csharpier：Prettier 的 C# 移植版本，让 .NET 开发者获得与 Prettier 类似的格式化体验。
• Prettier（Swift 版）：基于 Prettier 的 Swift 实现，面向 Swift 生态。

这两者说明 Prettier 的"重新打印 AST"设计思想已被多个语言社区借鉴，但它们是独立项目，能力与维护节奏以各自项目为准。

选择指南：何时用哪个？

综合 related-projects.md 与 integrating-with-linters.md，可以给出如下决策框架：

需要特别强调官方给出的警示：在网络上搜索"Prettier + 某个 Linter"时，还会遇到更多相关项目，它们一般不被推荐，但在特定情境下可能有用。判断的标准始终回到分工原则——Prettier 负责格式化，Linter 负责代码质量，任何试图让两者职责重叠的工具，都要评估其额外成本（速度、间接层、编辑器噪音）。

总结

Prettier 的价值不仅在于格式化器本身，更在于它催生的这套完整生态：related-projects.md 就是官方为这份生态绘制的地图。从最常用的eslint-config-prettier（Prettier 仓库自己在 eslint.config.js 中就用它来维持自身代码库的干净），到面向特殊场景的并行化、Git 钩子、CI、编辑器内嵌乃至其他语言移植工具，每个项目都对应一个具体的使用场景。理解这张地图，就能在为团队搭建格式化流水线时，既选对工具，也避免踩进"工具职责重叠"的常见陷阱。

【免费下载链接】prettierPrettier is an opinionated code formatter.项目地址: https://gitcode.com/gh_mirrors/pr/prettier