Prettier 与 ESLint 有什么区别?如何协作使用?
Prettier 与 ESLint 有什么区别?如何协作使用?
前端项目中,Prettier 和 ESLint 是最常搭配使用的两个工具,但它们的职责完全不同。理解各自的定位,才能正确配置和协作使用。
Prettier 和 ESLint 各自负责什么
Prettier 是代码格式化工具,只关心代码长什么样:
- 统一缩进、引号、分号、换行等风格
- 解析代码生成 AST 后重新输出,确保格式完全一致
- 配置项很少(约20个),设计理念是"别吵了,就用这个"
- 支持 JS/TS/CSS/HTML/JSON/Markdown 等多种语言
ESLint 是代码质量检查工具,关心代码有没有问题:
- 检测未使用变量、潜在错误、不安全的写法
- 执行团队约定的编码规范(如禁用 var、要求 ===)
- 拥有数千条可配置规则和丰富的插件生态
- 仅针对 JavaScript/TypeScript
核心区别一句话: Prettier 管"好不好看",ESLint 管"对不对"。
为什么不能只用一个
ESLint 虽然也有格式化规则(如缩进、引号),但能力有限且配置复杂。Prettier 的格式化效果更一致、覆盖语言更多,且几乎不需要团队争论配置。
反过来,Prettier 完全不做代码质量检查,漏掉未使用变量、错误逻辑等问题会埋下隐患。
两者结合是当前前端工程的标准做法。
协作配置(ESLint Flat Config)
从 ESLint v9 开始,官方推荐使用 Flat Config(eslint.config.js)替代旧版 .eslintrc。新配置方式如下:
安装依赖:
bashnpm install --save-dev eslint prettier eslint-config-prettier
配置 eslint.config.js:
javascriptimport js from "@eslint/js"; import prettierConfig from "eslint-config-prettier"; export default [ js.configs.recommended, prettierConfig, // 必须放在最后,关闭与 Prettier 冲突的规则 { rules: { "no-unused-vars": "warn", "prefer-const": "error", }, }, ];
配置 .prettierrc:
json{ "semi": true, "singleQuote": true, "tabWidth": 2, "trailingComma": "es5" }
关键点: eslint-config-prettier 必须放在配置数组最后,它会关闭所有与 Prettier 冲突的 ESLint 格式化规则,让 Prettier 独占格式化职责。
旧版配置方式(.eslintrc)
如果项目仍在使用旧版配置,这样设置:
javascript// .eslintrc.js module.exports = { extends: [ "eslint:recommended", "prettier", // 放在最后 ], };
eslint-plugin-prettier 还需要吗
eslint-plugin-prettier 的作用是把 Prettier 的格式化结果作为 ESLint 规则来报告。Prettier 官方现在不再推荐这种方式,原因是:
- 它让 ESLint 承担了格式化职责,导致运行变慢
- 格式化问题被混在 ESLint 报错中,难以区分
- 推荐做法是让两者各自独立运行
编辑器集成
在 VS Code 中配置自动格式化,保存时同时生效:
json// .vscode/settings.json { "editor.defaultFormatter": "esbenp.prettier-vscode", "editor.formatOnSave": true, "editor.codeActionsOnSave": { "source.fixAll.eslint": "explicit" } }
保存时先由 Prettier 格式化,再由 ESLint 修复代码质量问题,顺序正确无冲突。
Git 提交时自动检查
配合 Husky 和 lint-staged,在提交代码时自动运行检查:
bashnpm install --save-dev husky lint-staged npx husky init
json// package.json { "lint-staged": { "*.{js,ts}": ["eslint --fix", "prettier --write"], "*.{css,html,md,json}": ["prettier --write"] } }
bash# .husky/pre-commit npx lint-staged
这样只有暂存的文件会被检查,既保证代码质量又不影响提交效率。
常见冲突与排查
| 问题 | 原因 | 解决方式 |
|---|---|---|
| ESLint 报缩进/引号错误 | 格式化规则与 Prettier 冲突 | 确认 eslint-config-prettier 在 extends 最后 |
| Prettier 格式化后 ESLint 仍报错 | 质量规则报错,非格式问题 | 检查具体规则,质量规则应保留 |
| 保存时格式化不生效 | 编辑器未配置或扩展未安装 | 检查 VS Code 扩展和 settings.json |
可以用以下命令快速排查冲突规则:
bashnpx eslint-config-prettier path/to/.eslintrc.js
执行顺序总结
实际运行时的正确顺序:
- Prettier 先格式化代码(处理风格)
- ESLint 再检查代码质量(处理逻辑)
- 两者通过
eslint-config-prettier隔离职责,互不干扰
掌握 Prettier 和 ESLint 的职责边界、正确配置方式以及常见冲突排查,是前端工程化基础设施的基本要求。