如何管理 Prettier 版本？升级策略有哪些？

核心答案

Prettier 版本管理的核心原则就一条：项目内锁定精确版本，全员统一。升级时按 semver 级别分策略处理，主版本升级必须走迁移流程。

锁定版本的正确姿势：

json
{
  "devDependencies": {
    "prettier": "3.8.0"
  }
}

用 --save-exact 安装，避免 ^ 导致团队成员版本不一致。Prettier 每个 patch 都可能改变格式化输出，这不是理论风险，是实际踩过的坑。

版本升级策略

Patch/Minor 升级——低风险，可直接升级：

bash
npm install --save-dev --save-exact prettier@3.8.2
npx prettier --check "src/**/*.{js,ts,tsx}"

跑一遍 --check，无差异就提交。建议用 Dependabot 或 Renovate 自动处理。

Major 升级（如 2.x → 3.x）——高风险，必须走迁移流程：

1. 创建升级分支
2. 阅读 Changelog 中 Breaking Changes
3. 检查插件兼容性（插件 API 在 3.0 有 Breaking Change）
4. 全量 --check 后逐文件修复
5. CI 绿了再合

Prettier 3.x 迁移要点

从 2.x 升级到 3.x 是最常见的主版本升级场景，注意这几个坑：

• 插件 API 变更：embed 方法签名不兼容，自定义插件必须重写
• CSS 解析器拆分：--parser css 不再兜底解析 SCSS/LESS，需明确指定 scss 或 less
• ESLint 集成：搭配 eslint-config-prettier 关闭冲突规则：

js
// .eslintrc.js
module.exports = {
  extends: ["prettier"]  // 必须放最后
}

• 异步 API：3.x 的 prettier.format() 变成异步，脚本中需 await

回滚与团队协同

升级出问题，回滚要快：

bash
npm install --save-dev --save-exact prettier@2.8.8
git checkout HEAD -- package-lock.json
npm ci

团队升级的核心不是技术，是同步：锁定版本 + npm ci 保证环境一致，Husky + lint-staged 保证提交前格式化，CI 中 --check 兜底。三者缺一，迟早出格式冲突。

追问

• Prettier 和 ESLint 冲突怎么解决？——eslint-config-prettier 关闭 ESLint 格式规则，Prettier 只管风格，ESLint 只管逻辑。
• 为什么不用 npx prettier？——npx 每次拉最新版，团队成员格式化结果不一致，是线上事故的常见原因。
• 如何在 monorepo 中统一版本？——根 package.json 锁版本，子包用 workspace 协议引用，CI 在根目录统一 npm ci。