乐闻世界logo
5月27日 22:03

Prettier 如何在团队协作中发挥作用？有哪些最佳实践？

核心答案

Prettier 的团队协作价值是用机器执行替代人工争论，分三个层次落地：

  1. 配置即合约：.prettierrc 提交到版本控制，团队共享格式规则
  2. 提交即格式化：Husky + lint-staged 在 pre-commit 自动处理，开发者无感知
  3. 合并即拦截：CI 中 prettier --check 失败则阻断 PR

核心原则：Prettier 管格式（缩进、换行、引号），ESLint 管质量，各司其职。

配置与编辑器

.prettierrc 是团队格式规范的单点真相：

json
{
  "semi": true,
  "singleQuote": true,
  "tabWidth": 2,
  "trailingComma": "es5",
  "printWidth": 80,
  "endOfLine": "lf"
}

endOfLine: "lf" 容易被忽略——Windows 默认 CRLF，混用会产生 Git diff 噪音。编辑器侧用 .vscode/settings.json 配合保存即格式化：

json
{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.formatOnSave": true
}

工作流集成

Pre-commit 自动格式化（只处理暂存文件）：

bash
npm install --save-dev husky lint-staged
npx husky add .husky/pre-commit "npx lint-staged"
json
{
  "lint-staged": {
    "*.{js,ts,tsx,json,css,md}": ["prettier --write"]
  }
}

CI 兜底检查（防止绕过 hooks 提交）：

yaml
- name: Check format
  run: npx prettier --check "src/**/*.{js,ts,tsx}"

与 ESLint 协作

两者冲突是落地最常见的障碍。用 eslint-config-prettier 关闭 ESLint 中与 Prettier 重叠的格式规则：

bash
npm install --save-dev eslint-config-prettier
js
// .eslintrc.js
module.exports = {
  extends: ["eslint:recommended", "prettier"]  // prettier 必须放最后
}

执行顺序：Prettier 先格式化，ESLint 再检查质量，反过来会互相覆盖。

踩坑要点

  • 版本锁定：Prettier 2 和 3 格式化结果不同，必须锁版本
  • 历史代码：单独 PR 执行 prettier --write，混入业务变更会导致 git blame 失效
  • Monorepo：根目录放配置，子包通过 "prettier": "../.prettierrc" 引用，防止配置漂移
  • 性能：.prettierignore 排除 dist/node_modules，Prettier 3 支持 --cache 增量处理

追问

  • Prettier "不妥协的格式化"在什么场景下反而降低效率？如何应对？
  • Prettier 3 的破坏性变更如何平滑升级？
  • 团队成员坚持用自己偏好的格式，配置如何平衡灵活性和一致性？
标签：Prettier