跳到主要内容

Prettier

Prettier 最重要的价值，不是“把代码变漂亮”，而是把格式问题从团队协作里尽量拿掉。

写得再直白一点：

  • 缩进不要争
  • 引号不要争
  • 换行不要争
  • 尾随逗号不要争

这些事如果还靠人来盯，review 很快就会被格式噪音占满。

Prettier 更适合做什么​

它最适合处理这些格式层问题：

  • 缩进
  • 换行
  • 引号风格
  • 分号
  • 尾随逗号
  • 长对象、长参数、长 JSX 的排版

它不负责这些事：

  • 逻辑错误
  • 框架风险写法
  • 未使用变量
  • Promise 漏处理

这也是为什么 Prettier 和 ESLint 通常会一起出现，但分工完全不同。

配置文件一般放哪​

Prettier 官方文档列出了多种配置形式，例如：

  • package.json 里的 prettier 字段
  • .prettierrc
  • .prettierrc.json
  • prettier.config.js
  • prettier.config.ts

对团队项目来说，更常见也更清楚的做法一般是：

  • prettier.config.js
  • 或 .prettierrc.json

一个常见配置​

/** @type {import('prettier').Config} */
module.exports = {
  semi: true,
  singleQuote: true,
  trailingComma: 'all',
  printWidth: 100,
  tabWidth: 2,
  endOfLine: 'lf',
}

这份配置已经够覆盖大多数前端团队的日常使用。

每个常见选项大概在管什么​

semi​

是否保留分号。

singleQuote​

字符串用单引号还是双引号。

trailingComma​

对象、数组、参数列表的尾随逗号策略。

printWidth​

行宽参考值。它不是“超过就一定换行”的机械阈值，但会明显影响排版风格。

tabWidth​

缩进宽度。

endOfLine​

换行符策略，团队协作里很关键，尤其是跨平台开发时。

printWidth 别怎么配​

这项最容易吵。

如果配得太窄：

  • JSX 和对象结构会很容易被打散
  • 代码竖着长

如果配得太宽：

  • review 不好读
  • diff 横向拖得很长

大多数前端项目里，80 到 100 都是比较常见的区间。不是说哪一个绝对对，而是团队要统一。

.prettierignore 很重要​

如果 ignore 没配，Prettier 经常会误扫这些目录：

  • dist
  • build
  • coverage
  • node_modules
  • 自动生成代码
  • 某些三方拷贝资源

一个常见例子：

dist
build
coverage
node_modules
*.min.js
pnpm-lock.yaml

是否忽略锁文件，要看团队习惯。有些团队会保留锁文件格式一致性，有些团队会直接忽略。

overrides 在什么时候有用​

Prettier 官方文档也提到可以用 overrides 给不同文件类型配置不同策略。

例如：

/** @type {import('prettier').Config} */
module.exports = {
  semi: true,
  singleQuote: true,
  overrides: [
    {
      files: '*.md',
      options: {
        proseWrap: 'preserve',
      },
    },
    {
      files: '*.json',
      options: {
        tabWidth: 2,
      },
    },
  ],
}

这类写法常见于：

  • Markdown 不希望被强行改段
  • 某些配置文件需要更严格排版
  • 不同技术栈混在同一仓库里

和 .editorconfig 的关系​

Prettier 官方文档明确提到，如果项目里有 .editorconfig，Prettier 会读取其中能映射的配置。

所以比较常见的团队做法是：

  • .editorconfig 管最基础的缩进、换行
  • prettier 管更细的格式规则

这样 IDE、Prettier、不同语言文件之间更容易保持一致。

和 ESLint 怎么配才不打架​

最常见的组合是：

  • ESLint 负责查问题
  • Prettier 负责格式化
  • eslint-config-prettier 负责关掉冲突规则

这层如果没配好，常见症状会是：

  • 保存一次，ESLint 改一遍
  • 再保存一次，Prettier 又改回去
  • 最后每次提交都在处理格式抖动

编辑器里最常见的接法​

VS Code 一般会直接接保存时格式化：

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

如果项目同时用了 ESLint 自动修复和 Prettier，优先级要先想清楚。

比较稳的思路通常是：

  • Prettier 负责格式
  • ESLint fix 负责非格式规则修复

CLI 常见怎么跑​

prettier . --check
prettier . --write

通常会有两种入口：

  • 本地开发：--write
  • CI：--check

CI 不建议直接改文件，更适合让它负责拦住不符合规范的提交。

Markdown、JSON、YAML 为什么很适合交给 Prettier​

很多团队一开始只拿 Prettier 格式化 JS/TS，其实它对这些文件也很有价值：

  • Markdown
  • JSON
  • YAML
  • HTML
  • CSS
  • GraphQL

统一这些文件之后，仓库整体会顺很多。

老项目接 Prettier，通常怎么推进​

比较稳的方式一般是：

  1. 先只给新增文件生效
  2. 或先统一某个目录
  3. 再逐步扩展到全仓

如果老项目一上来全量 --write，diff 往往会特别大，review 成本也高。

更适合先记住的主线​

Prettier 最大的价值不是“好看”，而是：

  • 让格式问题自动化
  • 让 review 回到更重要的代码问题上
  • 让跨人协作时少掉很多无效摩擦

参考来源​