3.1配置体系与优先级

3.1 配置体系与优先级

配置文件的查找

Prettier 在运行时会自动查找配置文件。查找的起点是当前工作目录，然后向上级目录逐级搜索，直到找到第一个配置文件或到达文件系统根目录。

这跟 ESLint 的配置查找行为一致——你在项目子目录里运行 Prettier，它会向上找到项目根目录的 .prettierrc，而不是要求每个子目录都有自己的配置。

Prettier 支持的配置文件格式有六种：

还有一种特殊情况：如果配置文件以 .prettierrc 命名但没有后缀，Prettier 会尝试按 JSON 解析。如果解析失败（比如你意外地写成了 JavaScript 格式的 .prettierrc），会报错。这种情况下，建议用明确的 .prettierrc.json 来避免歧义。

优先级规则

当多个配置源同时存在时，Prettier 按以下优先级决定使用哪个：

命令行参数 > CLI 的 --config 指定的文件 > 项目配置文件 > 默认值

这意味着如果你在命令行传了 --single-quote，它会覆盖配置文件里的 singleQuote: false。如果你用 --config ./other-prettierrc.json 指定了另一个配置文件，它会覆盖项目目录下的 .prettierrc。

这种优先级设计是合理的：命令行参数是临时覆盖（调试用），--config 是显式指定（特殊场景用），项目配置是日常使用，默认值是兜底。

配置的继承与覆盖

，配置文件通常不是从零开始写的。它往往继承一个"共享配置"，然后在本地做少量覆盖。

共享配置是一个 npm 包，导出一个 Prettier 配置对象。比如某个组织可以发布自己的共享配置包：

// packages/prettier-config-acme/index.js
module.exports = {
  printWidth: 100,
  singleQuote: true,
  semi: false,
  trailingComma: "all",
  arrowParens: "always",
};
​

发布后，项目只需要在 package.json 中声明依赖，然后在 .prettierrc 中引用：

{
  "extends": "acme-prettier-config",
  "printWidth": 120
}
​

这样项目继承了 acme-prettier-config 中的所有配置，只覆盖了 printWidth 为 120。

extends 字段支持包名或文件路径。如果传的是包名（没有 / 或 . 开头），Prettier 会先查找 prettier-config- 前缀，找不到再用原始包名。所以 "extends": "acme" 等同于先尝试 prettier-config-acme，再尝试 acme。

配置文件的实践建议

用 .prettierrc.json 而不是 package.json 的 "prettier" 字段。虽然在 package.json 中写配置可以减少一个文件，但 package.json 的职责是描述包的元信息（名称、依赖、脚本等），混入 Prettier 配置会让文件变得杂乱。独立的 .prettierrc.json 更清晰，也更容易在编辑器中被识别。

配置项能少就少。Prettier 的默认值已经经过大量实践验证，大多数时候不需要改。如果你的配置文件有超过 5 个字段，值得审视每个字段——真的需要改吗？还是只是"感觉这样更好"？

配置要写注释解释原因。如果有非默认的配置项，加一行注释说明为什么改。半年后你或其他人回头看，能知道当时的决策背景。

{
  "singleQuote": true,
  "printWidth": 100
  // printWidth 从 80 改为 100 是因为项目大量使用链式调用
  // 80 字符限制导致频繁换行，可读性反而下降
}
​

注意 JSON 不支持注释。如果你的配置需要注释，可以改用 .prettierrc.js：

module.exports = {
  singleQuote: true,
  printWidth: 100,
  // printWidth 从 80 改为 100 是因为项目大量使用链式调用
};
​

或者用 .prettierrc.json5 格式（需要安装 json5 包），JSON5 支持 JSON 超集的注释和尾随逗号。

EditorConfig 的关系

EditorConfig 是一个独立的配置标准，用于定义编辑器的基本行为（缩进类型、缩进宽度、换行符类型等），通常用 .editorconfig 文件。它的格式跟 Prettier 的配置有重叠区域。

Prettier 会读取 .editorconfig 文件，但在有冲突时以 Prettier 自己的配置为准。具体来说，Prettier 会参考 EditorConfig 的 indent_style（对应 Prettier 的 useTabs）、indent_size（对应 tabWidth）、end_of_line（对应 endOfLine）等字段，只有在 Prettier 自身没有配置这些字段时才生效。

在实践中，如果你的项目同时有 .editorconfig 和 .prettierrc，建议保持两者的一致性——避免 EditorConfig 说"用 Tab 缩进"而 Prettier 配置说 useTabs: false。最简单的做法是以 Prettier 的配置为准，.editorconfig 只管 Prettier 不关心的编辑器行为（比如字符集编码、换行符等）。

overrides：按文件类型差异化配置

同一个项目里，不同文件可能需要不同的格式化规则。Prettier 提供了 overrides 配置项，按 glob 匹配文件并覆盖对应选项：

{
  "singleQuote": true,
  "overrides": [
    {
      "files": ["*.md", "**/*.md"],
      "options": {
        "proseWrap": "preserve"
      }
    },
    {
      "files": "*.component.html",
      "options": {
        "htmlWhitespaceSensitivity": "ignore"
      }
    }
  ]
}
​

files 支持单个 glob 或 glob 数组，匹配规则按照数组顺序，后面的覆盖前面的。options 里可以写任意 Prettier 配置项，也可以再次使用 extends 继承另一份共享配置。

实际项目中 overrides 最常见的用法：对 Markdown 保留原始换行（proseWrap: "preserve"，避免长行被强制折行）；对模板文件放宽空白敏感度（htmlWhitespaceSensitivity: "ignore"，减少无意义的属性换行）；对自动生成的代码（锁文件、构建产物）直接走 .prettierignore 排除，而不是用 overrides 硬调。

一个完整的解析过程

假设项目结构如下：

project/
├── package.json
├── .prettierrc
├── .editorconfig
├── src/
│   └── index.js
└── scripts/
    └── gen.js
​

命令行执行 npx prettier --write src/index.js 时，Prettier 依次做这几件事：从当前目录向上查找，找到项目根目录的 .prettierrc；检查命令行参数（本例没有 --config 和格式相关参数）；读取 .editorconfig 中与 Prettier 相关的字段（indent_style、indent_size、end_of_line）；最后把三部分合并成最终配置。如果 .prettierrc 里没写 tabWidth，而 .editorconfig 写了 indent_size = 4，最终生效的缩进就是 4。

一个容易踩的坑：.editorconfig 的优先级低于 .prettierrc。如果两边都配置了同一字段，以 .prettierrc 为准。也就是说，你不能指望用 .editorconfig 覆盖项目配置——它只填充 Prettier 没管的空白字段。

图 3-2：配置源优先级与共享配置继承

配置体系的设计理念是"约定优于配置，有需要再覆盖"。默认值能覆盖 90% 的场景，配置文件处理剩下的 10%，命令行参数处理极少数的临时调试需求。每一层都有明确的触发条件和使用场景，不会互相打架。

图 3-1：Prettier 配置查找优先级