ESLint配置文件

13. 一月 2017 JavaScript, React 0

上一篇文章介绍了ESLint的基本使用情况,这里在介绍一下ESLint配置文件中的一些细节问题。

如果我们使用ESLint的话可以:

eslint app.js 只是单独lint一个文件,所以一般在项目中不会这么用,如何配合构建工具用,上一篇文章已经介绍了。这里不多说

这样我们在控制台会看到很多errors和warning。

如果你在项目开发中期才上的ESLint的话,你会发现这些警告和错误大多数都是分号、空格、tab的问题,如果你手动改文件的话,我相信你会疯!

还好可以通过自动fix解决一写问题,从而减少工作量。

通过执行自动修复,可以把规则中可自动修复的规则(这里面的规则中后面括号中是fixable的)给修复掉。

但是本人不是特别推荐开发人员过度依赖自动fix,如果corder还是按照自己的习惯写,使用fix来解决代码问题的话,这样你使用ESLint并没有达到规范自己写代码的风格,而只是规范了代码的风格。

但是我们也不能每个文件单独fix,所以可以使用构建工具来配合

 

在我们执行 eslint --init 的时候会需要我们回答一些问题,从而生成基本的规则文件,ESLint支持全部的规则看这里

首先我们限制用内置的eslint:recommended配置,他包含了一系列规则,能报告一些常见的问题:

eslint 有一些推荐的规则,用来捕获一些比较通用的问题和错误,在配置文件中做上面这个配置"extends": "eslint:recommended",就说明这些推荐的规则全部开启。但是你也可以自己选用对自己项目适用的规则。

这样eslint一个文件的时候如果你有console的话,他会报错,所以我们可以禁用 no-console 规则

说明:配置规则写在rules对象里面,key表示规则名称,value表示规则的配置


同时必须要考虑的一个事情就是:JavaScript 有很多种运行环境,比如常见的有浏览器和 Node.js,另外还有很多软件系统使用 JavaScript 作为其脚本引擎,比如 PostgreSQL 就支持使用 JavaScript 来编写存储引擎,而这些运行环境可能并不存在console这个对象。另外在浏览器环境下会有window对象,而 Node.js 下没有;在 Node.js 下会有process对象,而浏览器环境下没有。

所以在配置文件中我们可以通过"env"指定程序的目标环境:

如果你要在项目中的package.json 文件中指定配置的话,可以写在 eslintConfig

 

每个环境带有自己一系列的预定义的全局变量,可以通过globals来指定在代码运行时我们允许的额外的全局变量。对全局变量进行约束:

 

eslint允许使用第三方的变量,我们可以配置在这里。

eslint允许我们选择性的使用js语言的某些特性。可以通过ecmaFeatures来配置。

规则

每条规则有 3 个等级:offwarnerroroff表示禁用这条规则,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

然后将原来的.eslintrc.js文件改成这样:


特别需要注意的一点是:

NPM上一些ESlint配置,这些配置的模块名一般以eslint-config-为前缀,想要使用的话必须全局安装。由于我们的eslint命令是全局安装的,所有用到的eslint-config-*模块也必须全局安装,否则将无法正确载入。这是一个已知的 Bug

代码自动修复

ESLint 规则列表页面,我们发现有些规则的旁边会带有一个橙色扳手图标,表示在执行eslint命令时指定--fix参数可以自动修复该问题。


尽管我们在编码时怀着严格遵守规则的美好愿景,而凡事总有例外。定立 ESLint 规则的初衷是为了避免自己犯错,但是我们也要避免不顾实际情况而将其搞得太过于形式化,本末倒置。如果说某一条规则在某个文件中不适用,可以使用注释的方式进行临时禁用。详细使用方法可以参考文档:Disabling Rules with Inline Comments – 使用行内注释禁用规则

总结

在GitHub上面 airbnb 的编码规范受到很多人的青睐,通读了其规则之后我也很认可,但是还是在某些地方有自己的看法,所以每个团队都会根据自己的的实际情况定制不同的东西,我们并不能随便照搬过来。

如果直接使用eslint-config-airbnb 这种规则而没有使用eslint:recommended 这样保守的,直接lint文件的话,你会发现满屏的error。

东西不在于多好,对于自己最好的才是游有用的!


参考阅读:

http://morning.work/page/maintainable-nodejs/getting-started-with-eslint.html

http://eslint.cn/  官方

最后附上一些常用的配置

eslint:recommended 的配置:

 

Airbnb 的配置:

 


发表评论

电子邮件地址不会被公开。