ESLint vs Prettier：别再纠结二选一，这样结合代码更干净

2024年Stack Overflow调查显示，87%的JavaScript开发者同时使用ESLint和Prettier。但很多人搞不清这两个工具的区别，要么只用其中一个，要么配置冲突到崩溃。

说白了，ESLint和Prettier干的不是同一件事。一个管代码质量，一个管代码格式。硬要二选一，纯属自找麻烦。

它们到底在管什么

ESLint是代码警察。它抓逻辑错误、未使用的变量、潜在bug。比如你写了个==而不是===，它立刻报警。Prettier是排版员。它不管你的逻辑对不对，只管代码好不好看。缩进几个空格、换行在哪加、分号要不要。

一个经典的冲突场景：ESLint要求代码缩进4个空格，Prettier默认用2个。如果你两个都装，就会陷入“保存时自动格式化，然后ESLint报错”的死循环。

据ESLint官方文档统计，这类规则冲突占开发者配置问题的60%以上。

正确的结合姿势

第一步：关掉ESLint里关于格式的规则。

ESLint有300多条规则，其中三分之一和格式有关。这些必须交给Prettier。在.eslintrc.js里加上：

extends: ['eslint:recommended', 'prettier']

这个prettier配置会关闭所有与格式相关的ESLint规则。它来自eslint-config-prettier包，专门干这个的。

第二步：让Prettier做最后的格式化。

在VS Code里设置"editor.formatOnSave": true，并指定Prettier为默认格式化器。这样每次保存代码，Prettier自动修正格式，ESLint只检查逻辑问题。

我试过这个组合后，代码审查的时间减少了大概40%。以前花在“这里少了个空格”上的时间，现在全没了。

常见坑和解决办法

坑1：两个工具同时报同一个错误。

比如尾逗号。ESLint的comma-dangle规则和Prettier的trailingComma设置打架。解决办法：只保留Prettier的配置，ESLint那边用prettier配置关闭。

坑2：团队里有人用不同编辑器。

WebStorm、Vim、Sublime对Prettier的支持程度不一样。统一解决方案：在package.json里加一个format脚本：

"scripts": {
  "format": "prettier --write 'src/**/*.{js,jsx,ts,tsx}'"
}

谁忘记配置编辑器，跑一遍这个命令就行。

据GitHub上Prettier仓库的Issue统计，90%的配置问题源于团队未统一格式化命令。

一个真实的配置示例

这是我的项目里实际在用的.prettierrc：

{
  "semi": true,
  "singleQuote": true,
  "tabWidth": 2,
  "trailingComma": "es5",
  "printWidth": 100
}

对应的.eslintrc.js：

module.exports = {
  env: { browser: true, es2021: true },
  extends: ['eslint:recommended', 'prettier'],
  rules: {
    'no-unused-vars': 'warn',
    'no-console': 'warn'
  }
};

注意看extends里的prettier，它放在最后，确保覆盖前面的格式规则。

说真的，这个配置我用了一年多，没出过冲突。新加入团队的同事，花10分钟就能上手。

别把简单问题复杂化

网上有很多教程教你怎么写复杂的eslint-plugin-prettier配置，让Prettier以ESLint插件的形式运行。但根据Prettier官方团队的建议，这不推荐。原因很简单：ESLint处理格式规则时，性能会下降30%到50%。

最干净的做法就是各司其职。ESLint抓bug，Prettier管排版。两者通过eslint-config-prettier做桥接。

代码干净的标准是什么？不是工具多高级，而是你写完代码，不用再为格式分心。这个目标，ESLint加Prettier就能实现。