5月28日 07:24

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。新配置方式如下:

安装依赖:

bash
npm install --save-dev eslint prettier eslint-config-prettier

配置 eslint.config.js:

javascript
import 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,在提交代码时自动运行检查:

bash
npm 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

可以用以下命令快速排查冲突规则:

bash
npx eslint-config-prettier path/to/.eslintrc.js

执行顺序总结

实际运行时的正确顺序:

  1. Prettier 先格式化代码(处理风格)
  2. ESLint 再检查代码质量(处理逻辑)
  3. 两者通过 eslint-config-prettier 隔离职责,互不干扰

掌握 Prettier 和 ESLint 的职责边界、正确配置方式以及常见冲突排查,是前端工程化基础设施的基本要求。

标签:Prettier