Prettier 与 ESLint 怎么分工
两者职责不同：Prettier 管格式，ESLint 管逻辑与通用实践。冲突集中在缩进、引号、分号这类格式规则上，解决办法是用 eslint-config-prettier 把冲突规则整体关掉，让格式只由一方负责。执行顺序上，通常先格式化再检查。
基本信息
| 推荐做法 | 用 eslint-config-prettier 关闭冲突的格式规则 |
|---|---|
| 执行顺序 | 先格式化，再跑 ESLint 检查 |
| 冲突焦点 | 缩进、引号、分号、换行位置 |
| 备选方案 | 把 Prettier 作为 ESLint 规则内嵌运行 |
典型使用场景
- 新项目配置：一次装好两个工具，写清楚各自负责什么
- 提交前自动修复：钩子里先格式化，再跑检查修复
- CI 校验：两边都跑，但格式问题只在一处报错
- 老项目整治：先关掉冲突规则，再逐步调整其它检查
- 编辑器配置：保存时格式化，另存时检查，避免重复动作
内嵌运行的取舍
- 优点：一条命令同时完成格式化与检查
- 代价：每次检查都要调用 Prettier，耗时明显增加
- 适合：中小仓库与提交钩子
- 不适合：大型仓库的全量检查
安装与配置
安装与配置
npm i -D prettier eslint-config-prettier
# 把关闭冲突的那份配置放在末尾，覆盖前面的格式规则
# 冲突的 indent / quotes / semi 等规则由 Prettier 全权负责规则归属
| 规则类别 | 归属 |
|---|---|
| 缩进、引号、分号、换行 | Prettier |
| 未使用变量、相等比较 | ESLint |
| 导入顺序 | 交给专门的排序工具 |
| 类名与函数命名 | ESLint 的命名规则 |
两边都管的规则把权限交给一方即可，否则自动修复会来回覆盖，提交记录里全是格式抖动。
在评审中的用法：格式类差异不该写成评审意见，直接请对方跑一遍格式化命令即可。
老仓库可以按目录分批启用格式化，避免某一次提交里出现成千上万行纯格式差异。
忘记关闭冲突规则：格式化与检查互相改坏，提交来回拉扯。