其实很早的时候就想尝试 ESLint 了,但是很多次都是玩了一下就觉得这东西巨复杂,一执行检查就是满屏的
error
,简直是不堪入目,遂放弃。直到某天终于下定决心深入看了文档,才发现其实挺简单的,只是当时没有看到合适入门教程而已。我相信很多人也有着跟我一样的经历,所以希望将自己的踩坑心得记录下来,让后来者更轻易地掌握 ESLint 的使用,因为它确实是个好东西。
JavaScript 是一门神奇的动态语言,它在带给我们编程的灵活性的同时也悄悄埋下了一些地雷。除了基本的语法错误能在程序一启动的时候被检测到之外,很多隐含的错误都是在运行的时候才突然地蹦出来。除非你的程序有着 100%的测试覆盖率,否则说不定哪天就会因为一个xxx is undefined
而导致程序崩溃,而为了避免这样的错误可能你只需要在提交代码的时候用工具静态分析一下,仅此而已。
ESLint 是一个插件化的 javascript 代码检测工具,它可以用于检查常见的 JavaScript 代码错误,也可以进行代码风格检查,这样我们就可以根据自己的喜好指定一套 ESLint 配置,然后应用到所编写的项目上,从而实现辅助编码规范的执行,有效控制项目代码的质量。
手把手入门
在开始使用 ESLint 之前,我们需要通过 NPM 来安装它:
1 |
$ npm install -g eslint |
我从 Gist 上找到了自己几年前写的一个小函数,将其保存为文件merge.js
:
1 2 3 4 5 6 7 8 9 10 |
function merge () { var ret = {}; for (var i in arguments) { var m = arguments[i]; for (var j in m) ret[j] = m[j]; } return ret; } console.log(merge({a: 123}, {b: 456})); |
然后执行node merge.js
确保它是可以正确运行的(输出结果为{ a: 123, b: 456 }
)。
接着我们执行以下命令来使用 ESLint 检查:
1 |
$ eslint merge.js |
可以看到,没有任何输出结果。这是因为我们没有指定任何的配置,除非这个文件是有语法错误,否则应该是不会有任何提示的。现在我们先使用内置的eslint:recommended
配置,它包含了一系列核心规则,能报告一些常见的问题。
首先新建 ESLint 配置文件.eslintrc.js
:
1 2 3 |
module.exports = { extends: 'eslint:recommended', }; |
重新执行eslint merge.js
可以看到输出了 2 个错误:
1 2 3 4 5 |
/example/merge.js 10:1 error Unexpected console statement no-console 10:1 error 'console' is not defined no-undef ✖ 2 problem (2 error, 0 warnings) |
这两条提示信息还是足够我们搞清楚是怎么回事的:
- Unexpected console statement no-console – 不能使用
console
- ‘console’ is not defined no-undef –
console
变量未定义,不能使用未定义的变量
针对第 1 条提示,我们可以禁用no-console
规则。将配置文件.eslintrc.js
改为这样:
1 2 3 4 5 6 |
module.exports = { extends: 'eslint:recommended', rules: { 'no-console': 'off', }, }; |
说明:配置规则写在rules
对象里面,key
表示规则名称,value
表示规则的配置,具体说明见下文。
重新执行检查还是提示no-undef
:
1 2 3 4 |
/example/merge.js 10:1 error 'console' is not defined no-undef ✖ 1 problem (1 error, 0 warnings) |
这是因为 JavaScript 有很多种运行环境,比如常见的有浏览器和 Node.js,另外还有很多软件系统使用 JavaScript 作为其脚本引擎,比如 PostgreSQL 就支持使用 JavaScript 来编写存储引擎,而这些运行环境可能并不存在console
这个对象。另外在浏览器环境下会有window
对象,而 Node.js 下没有;在 Node.js 下会有process
对象,而浏览器环境下没有。
所以在配置文件中我们还需要指定程序的目标环境:
1 2 3 4 5 6 7 8 9 |
module.exports = { extends: 'eslint:recommended', env: { node: true, }, rules: { 'no-console': 'off', }, }; |
再重新执行检查时,已经没有任何提示输出了,说明merge.js
已经完全通过了检查。
配置文件
ESLint 还可以在项目的package.json
文件中指定配置,直接将上文中的module.exports
的值写到eslintConfig
里面即可:
1 2 3 4 5 6 7 8 9 10 11 12 13 |
{ "name": "my-package", "version": "0.0.1", "eslintConfig": { "extends": "eslint:recommended", "env": { "node": true }, "rules": { "no-console": "off" } } } |
另外还可以在执行eslint
命令时通过命令行参数来指定,详细文档可以参考这里:Configuring ESLint – 配置
规则
每条规则有 3 个等级:off
、warn
和error
。off
表示禁用这条规则,warn
表示仅给出警告,并不会导致检查不通过,而error
则会导致检查不通过。
有些规则还带有可选的参数,比如comma-dangle
可以写成[ "error", "always-multiline" ]
;no-multi-spaces
可以写成[ "error", { exceptions: { "ImportDeclaration": true }}]
。
规则的详细说明文档可以参考这里:Rules – 规则
使用共享的配置文件
上文我们以eslint:recommended
为基础配置,然后在此之上修改no-console
这条规则。而在大多数时候,我们可能会根据自己个人或团队的习惯,定制更多的规则,比如限定缩进是 2 个空格和使用单引号的字符串等。而如果每一个项目都要这样写到.eslintrc.js
文件上,管理起来会比较麻烦。
我们可以将定义好规则的.eslintrc.js
文件存储到一个公共的位置,比如public-eslintrc.js
:
1 2 3 4 5 6 7 8 9 10 11 |
module.exports = { extends: 'eslint:recommended', env: { node: true, }, rules: { 'no-console': 'off', 'indent': [ 'error', 2 ], 'quotes': [ 'error', 'single' ], }, }; |
然后将原来的.eslintrc.js
文件改成这样:
1 2 3 |
module.exports = { extends: './public-eslintrc.js', }; |
为了验证这样的修改是否生效,将merge.js
中的var ret = {};
这一行前面多加一个空格,再执行 ESLint 检查:
1 2 3 4 |
/example/merge.js 2:4 error Expected indentation of 2 space characters but found 3 indent ✖ 1 problem (1 error, 0 warnings) |
这时候提示的是缩进只能为 2 个空格,而文件的第 2 行却发现了 3 个空格,说明公共配置文件public-eslintrc.js
已经生效了。
我们还可以使用已经发布到 NPM 上的 ESLint 配置,这些配置的模块名一般以eslint-config-
为前缀,比如我在学习 ESLint 时自己编写的一个配置名为eslint-config-lei
。要使用这个配置,先执行以下命令安装它:
1 |
$ npm install -g eslint-config-lei |
注意:用于我们的eslint
命令是全局安装的,所有用到的eslint-config-*
模块也必须全局安装,否则将无法正确载入。这是一个已知的 Bug,参考这里:Error: Cannot read config package for shareable config using global eslint #4822
然后将.eslintrc.js
文件改成这样:
1 2 3 |
module.exports = { extends: 'lei', }; |
再执行 ESLint 检查,可以看到输出如下的提示: