## 关于ESLint配置文件你可能需要知道这些如果你写过JavaScript代码大概率遇到过这样的情况代码在本地运行得好好的一提交到团队仓库别人就说格式不对、有潜在错误或者风格不一致。这种问题在多人协作中特别常见每个人都有自己的编码习惯时间一长项目代码就会变得五花八门。ESLint的配置文件就是为解决这类问题而生的。它不是魔法而是一套白纸黑字的规则手册告诉你的编辑器或者构建工具这个项目里代码应该写成什么样不应该写成什么样。它到底是什么简单来说ESLint配置文件就是一个普通的JavaScript、JSON或者YAML文件通常命名为.eslintrc.js、.eslintrc.json或者.eslintrc.yml。你也可以直接在package.json里加一个eslintConfig字段。文件里写的东西很直白就是一系列配置项定义了ESLint这个工具应该如何检查你的代码。你可以把它想象成项目的“代码宪法”。没有它每个人都可以随心所欲有了它就有了共同遵守的基本法。这个文件一般放在项目根目录这样ESLint就能找到它并按照里面的规则去扫描所有JavaScript文件。它能做什么配置文件的核心作用是激活并精细控制ESLint的检查能力。ESLint本身是个空壳它知道怎么解析代码、怎么遍历语法树、怎么报告错误但它不知道具体该检查什么。配置文件就是告诉它检查细节的指令集。首先它能定义代码风格。比如字符串用单引号还是双引号行尾要不要加分号缩进用几个空格。这些看似是小事但在合并代码时如果格式不统一会产生大量无意义的改动行干扰真正的代码审查。其次它能发现潜在的错误和不良实践。比如定义了变量却没使用或者使用了未来可能被废弃的语法。ESLint能识别出那些不会导致程序立刻崩溃但可能埋下隐患的代码模式。有时候它甚至能帮你发现一些简单的逻辑错误。最后也是很重要的一点它能保持团队的一致性。当项目里所有人都遵循同一套规则时代码读起来就像是一个人写的新人接手成本会低很多代码审查也能更聚焦于逻辑和设计而不是纠结于风格问题。怎么使用它使用配置文件的第一步是创建它。现在比较主流的方式是创建一个.eslintrc.js文件因为用JavaScript写配置更灵活可以加注释也能动态生成一些配置。文件的基本结构通常包含几个部分。一个是env用来指定代码运行的环境比如浏览器browser、Node.jsnode或者启用了ES6特性es6。设定了环境ESLint就知道哪些全局变量是合法的不会把window或require报成未定义变量。另一个核心是extends。很少有人会从零开始一条条写规则那样太费劲了。通常我们会直接继承一些现成的、公认比较好的规则集。最出名的是eslint:recommended这是ESLint官方维护的一套规则主要聚焦于避免代码错误。另一个流行的是airbnb规则集它非常严格和全面在社区里用得很广。通过继承你就能获得一个高质量的检查起点。然后就是rules字段这是你发挥个性的地方。你可以在继承的基础上对某条规则进行覆盖。每条规则都有三个等级off关闭、warn警告和error报错。你可以根据团队情况调整。比如团队里很多人还不习惯箭头函数你可以把要求使用箭头函数的规则先调成warn而对于可能导致严重问题的规则比如no-debugger就必须设为error。有时候项目里会用到React、Vue或者TypeScript这就需要用到parser和plugins。比如用TypeScript就需要把解析器换成typescript-eslint/parser并添加对应的插件typescript-eslint这样ESLint才能理解TS语法并应用相关规则。配置文件写好之后ESLint并不会自动运行。你需要通过命令行手动执行或者更常见的把它集成到编辑器和构建流程里。在VS Code里安装ESLint插件后它就能实时读取你的配置文件在写代码时直接标出问题。在package.json的脚本里加一条lint: eslint src/就能在提交代码前或CI/CD流程中自动检查。一些实践中的体会刚开始用ESLint很容易犯两个极端要么规则太少形同虚设要么规则太严令人寸步难行。比较好的做法是循序渐进。对于新项目可以从一个严格的规则集比如airbnb开始因为一开始就定下高标准后面反而没那么多阻力。对于庞大的老项目千万别想着一次性把所有规则都打开那会冒出成千上万个错误团队根本无法接受。应该采用“增量修复”的策略先继承一个基础规则集只把最危险的几条规则设为error其他的全设为off。然后在团队内达成共识每修复一个文件或一个模块就打开一两条相关的规则逐步把代码质量提升上来。配置文件本身也需要被管理。一个建议是把最核心、最通用的配置放在项目根目录的配置文件里。如果某个子目录有特殊需求比如测试目录__tests__里可以用console.log来调试就在那个子目录里再放一个.eslintrc.js文件它会覆盖和扩展根目录的规则。这样结构比较清晰。还有一点容易被忽略就是忽略文件.eslintignore。它和.gitignore类似用来告诉ESLint哪些文件或目录不用检查比如node_modules、构建输出的dist目录或者一些自动生成的代码。配好这个能节省不少不必要的检查时间。和同类工具的简单对比在JavaScript的代码检查领域ESLint并不是唯一的选择。早些时候JSHint和JSCS也比较流行。JSHint用起来更简单配置项少开箱即用适合不想花太多时间配置的小项目或个人项目。但它的缺点是不够灵活规则难以扩展无法根据项目需求进行深度定制。在需要高度定制化和集成现代框架语法如JSX的场景下就显得力不从心了。JSCS的设计理念很有意思它只关注代码风格不管代码对错。它曾经可以和专注检查错误的ESLint配合使用。但后来社区发现维护两套工具太麻烦最终JSCS团队决定停止开发并推荐大家直接使用ESLint因为ESLint通过插件和规则配置完全可以覆盖风格检查的需求。这个事件也确立了ESLint在社区事实上的标准地位。至于Prettier它经常被拿来和ESLint比较但严格来说它们不是同类工具。Prettier是一个固执己见的代码格式化工具它只关心代码的“样子”——空格、换行、引号这些并会直接修改你的源代码。而ESLint主要是一个检查Lint工具它告诉你哪里有问题但改不改、怎么改决定权在你。在实际项目中很多人会让它们俩分工合作用Prettier管格式用ESLint管代码质量和风格约定。两者通过eslint-config-prettier这样的配置关掉冲突的规则可以和谐共处。说到底ESLint配置文件的价值不在于它用了多高级的技术而在于它把团队里那些模糊的、口口相传的编码约定变成了清晰、可执行、可追溯的文本规则。它减少了很多无谓的争论让开发者能把更多精力放在解决真正的业务问题上。工具终究是为人服务的一个好的配置文件应该是团队共识的体现而不是某个人的独裁命令。