什么是 ESlint
编码规范
每个程序员都有自己的编码习惯,最常见的莫过于:
- 有的人写代码一行代码结尾必须加分号
;
,有的人觉得不加分号;
更好看 - 有的人写代码一行代码不会超过
80
个字符,认为这样看起来简洁明了,有的人喜欢把所有逻辑都写在一行代码上,觉得别人看不懂的代码很厉害 - 有的人使用变量必然会先定义
var a = 10;
,而粗心的人写变量可能没有定义过就直接使用b = 10;
Lint 的含义
如果你写自己的项目怎么折腾都没关系,但是在公司中老板希望每个人写出的代码都要符合一个统一的规则,这样别人看源码就能够看得懂,因为源码是符合统一的编码规范制定的。
那么问题来了,总不能每个人写的代码老板都要一行行代码去检查吧,这是一件很蠢的事情。凡是重复性的工作,都应该被制作成工具来节约成本。这个工具应该做两件事情:
- 提供编码规范;
- 提供自动检验代码的程序,并打印检验结果:告诉你哪一个文件哪一行代码不符合哪一条编码规范,方便你去修改代码。
Lint 因此而诞生。
Eslint 的含义
Lint 是检验代码格式工具的一个统称,具体的工具有 Jslint 、 Eslint 等等 ………..
我们可以形象地将 Lint 看成是电商行业,而电商行业具体表现有淘宝(Eslint)、京东(Jslint)等。
使用 Eslint
安装依赖包
--save-dev
会把 eslint
安装到 package.json
文件中的 devDependencies
属性中,意思是只是开发阶段用到这个包,上线时就不需要这个包了。
1 | npm install eslint --save-dev |
设置 package.json 文件
打开 package.json 文件,修改 script 属性如下:
1 | "scripts": { |
script
属性的意思是脚本,使用方法是在cmd
窗口中输入npm run
指令 的形式,如:npm run lint:create
"lint:create": "eslint --init"
这个脚本是为了生成.eslintrc.js
文件,在介绍Lint
的时候说到Lint
应该提供编码规范,规范写在哪里,就写在这个文件,所以我们需要创建它"lint": "eslint src"
在介绍Lint
的时候也说到Lint
应该提供自动校验代码的程序,这个脚本是让Lint
自动检验src
目录下所有的.js
文件。
创建 .eslint.js 文件
1 | npm run lint: create |
创建完成后根目录下应该会出现 .eslintrc.js
文件
设置 –fix 参数
打开 package.json 文件,修改 script 属性如下:
1 | "scripts": { |
说明:这里给 "lint": "eslint src --fix"
, 加上 --fix
参数,是 Eslint
提供的自动修复基础错误的功能。
可惜的是 --fix
只能修复基础的不影响代码逻辑的错误。
配置文件讲解
按照上述操作,会生成默认 .eslintrc.js 配置文件,内容如下:
1 | // .eslintrc.js |
该文件导出一个对象,对象包含属性 env
、extends
、parserOptions
、plugins
、rules
五个属性,作为刚学习 Eslint
的新手,我们总是想要竭尽所能的详细了解每一个属性是什么,干嘛用的,以获取小小的安全感。
env、parserOptions、plugins
这三个放在一起将是因为你只需要知道它们是干嘛的:我的程序里要用到 ES6 、React 、JSX 语法,这几个属性就是让 Eslint 能够检验到这些语法的。其余的你不需要知道更多的哪怕一丢丢的东东了。
作者在学习之初在这块浪费了很多时间,官方文档看了很多遍,大多不能理解什么意思,后来想它既然提供这么一个自动生成配置文件的工具,并且是命令行交互的方式,我只需要告诉它我要用 ES6 、React 、JSX 语法,它会自动进行相关配置满足我的要求即可。
extends
前面一直说检验代码遵循编码规范,那到底是什么规范呢。
值为 "eslint:recommended"
的 extends
属性启用一系列核心规则,这些规则是经过前人验证的最佳实践,所谓最佳实践,就是大家伙都觉得应该遵循的编码规范,想知道最佳实践具体有哪些编码规范,可以在 eslint 规则表 中查看被标记为 √ 的规则项。
如果觉得官方提供的默认规则不好用,可以自定义规则配置文件,然后发布成 Npm
包,eslint-config-airbnb
就是别人自定义的编码规范,使用 npm
安装后,在我们自己的 .eslintrc.js
中进行配置 "extends": "airbnb",eslint-config
这个前缀可以省略不写,这样我们就使用了 eslint-config-airbnb
中的规则,而不是官方的规则 "extends":"eslint:recommended"
了。关于如何创建自定义规则配置并共享可以参考: 如何自定义规则配置
关于 "airbnb"
编码规范说两句,在接触到大多数开源项目中,大多数的作者都会使用 "airbnb"
编码规范而不是 官方的 "extends": "eslint:recommended"
编码规范。
如果我们觉得 eslint-config-airbnb
规则配置中个别规则并不符合当前项目的要求,可以直接在 .eslintrc.js
配置 rules
属性,优先级高于共享规则 airbnb
。
rules
配置文件也生成了,我们怎么知道我们的系统会遵循什么规则呢?
假设 npm run lint
校验出了三处错误,我们的项目中字符串要使用单引号而不是双引号,代码结尾就是要不加分号才好看,变量就是定义了可能不会使用,我们可以通过设置 rules 来定义我们自己的编码规范,即规则。
ESLint
附带有大量的规则,修改规则应遵循如下要求:
- “off” 或 0 - 关闭规则
- “warn” 或 1 - 开启规则,使用警告级别的错误:warn (不会导致程序退出)
- “error” 或 2 - 开启规则,使用错误级别的错误:error (当被触发的时候,程序会退出)
有的规则没有属性,只需控制是开启还是关闭,像这样:"eqeqeq": "off"
,有的规则有自己的属性,使用起来像这样:"quotes": ["error", "double"]
,具体有没有自带属性,可查看 eslint 规则表。
可能存在的疑问
刚接触 ESlint
,并不清楚有哪些规则怎么办,要去 eslint规则表
一条条记忆吗?答案是 no。
个人认为 ESlint
的配置文件并不是一次性完成的,而是在项目过程中慢慢完善的。你可以放心大胆的先进行编码,然后使用 npm run lint
校验代码的编码规范,如果这时候报错,可以在报错信息中知道是哪一条编码规范报错了,你可能并不认识它们,此时去 eslint规则表
查询相应规则的使用方法,如:no-unused-vars
,从而进一步确定项目中是否需要这条编码规范,如果需要,进行局部调整即可。
全局变量配置
如使用 window 对象,默认情况下会报 no-undef 的错误,需要在 .eslintrc 中进行相应配置。
1 | { |
单行跳过 lint 校验
在实际编码时,可能会出现以下的代码。
1 | const apple = "apple"; |
在最上面定义了两个变量,在底部的配置文件中只可能用到其中一个变量,另一个用不到的在 eslint
校验时就会报错 no-unused-vars
的错误,意思是变量定义了但是没有被用到。
其中一种解决方案是在 .eslintrc
文件中配置 rules no-unused-vars: 0
,意思是项目中不检验变量定义未使用这条规则。强烈不建议这样做,这个规则十分有用,可以规避编写代码时遗漏的变量。
另一种解决方案就是使用行内注释跳过对 apple
和 balana
两个变量跳过 eslint
校验,只影响这两个变量,不影响外部。
1 | const apple = "apple"; // eslint-disable-line |
此时使用 eslint 校验时就不会再报错了。
常见规则含义解释
object-shorthand
设置该规则,表示对象属性要简写。
1 | var foo = {x: x}; // 会报错 |
prefer-arrow-callback
要求回调函数使用箭头函数
1 | // 回调函数,函数的参数是个函数,这个参数函数就是回调函数 |
no-param-reassign
禁止对函数的参数重新赋值
1 | function bar ({ data = {} }) { |
no-trailing-spaces
禁止行尾空格
no-shadow
禁止变量声明与外层作用域的变量同名
1 | function sum (num) { |
常用的几个规则
1 | "quotes": [1, "single"], # 单引号 |