报告的生成,有时候我们为了pipeline最后生成附件报告,或者本地测试我们为了更直观的看到我们的错误及问题,像这样的:
这里我们只需要在我们的package.json里的“scripts”里设置:
"lint": "eslint --config .eslintrc.yml \"**/*.ts\" --format html > lint-report.html"
这样直接运行这个脚本,或者npm run lint都是可以。
Tslint,Nglint同理!
———————————————————————————————————————————
Lint 的含义
如果你写自己的项目怎么折腾都没关系,但是在公司中老板希望每个人写出的代码都要符合一个统一的规则,这样别人看源码就能够看得懂,因为源码是符合统一的编码规范制定的。
那么问题来了,总不能每个人写的代码老板都要一行行代码去检查吧,这是一件很蠢的事情。凡是重复性的工作,都应该被制作成工具来节约成本。这个工具应该做两件事情:
- 提供编码规范;
- 提供自动检验代码的程序,并打印检验结果:告诉你哪一个文件哪一行代码不符合哪一条编码规范,方便你去修改代码。
Eslint 的含义
Lint 是检验代码格式工具的一个统称,具体的工具有 Jslint
、 Eslint
等等 ...........
我们可以形象地将 Lint 看成是电商行业,而电商行业具体表现有淘宝(Eslint)、京东(Jslint)等,其实原则上都一样,不一样的lint工具而已,就像多种开发的idea.
安装依赖包
--save-dev
会把 eslint 安装到 package.json 文件中的 devDependencies 属性中,意思是只是开发阶段用到这个包,上线时就不需要这个包了。
$ npm install eslint --save-dev
设置 package.json 文件
打开 package.json 文件,修改 script 属性如下:
"scripts": {
"test": "react-scripts test --env=jsdom",
"lint": "eslint src",
"lint:create": "eslint --init"
}
- script 属性的意思是脚本,使用方法是在 cmd 窗口中输入
npm run 指令
的形式,如:npm run lint:create
; "lint:create": "eslint --init"
这个脚本是为了生成 .eslintrc.js 文件,在介绍 Lint 的时候说到 Lint 应该提供编码规范,规范写在哪里,就写在这个文件,所以我们需要创建它;"lint": "eslint src"
在介绍 Lint 的时候也说到 Lint 应该提供自动校验代码的程序,这个脚本是让 Lint 自动检验 src 目录下所有的 .js 文件。
设置 --fix 参数
打开 package.json 文件,修改 script 属性如下:
"scripts": {
"test": "react-scripts test --env=jsdom",
"lint": "eslint src --fix",
"lint:create": "eslint --init"
}
说明:这里给 "lint": "eslint src --fix",
加上 --fix
参数,是 Eslint 提供的自动修复基础错误的功能。
此时运行 npm run lint
会看到少了两条报错信息,并不是说编码规范变了,而是 Eslint 自动修复了基础错误,打开 index.js 文件,可看到字符串自动变成了双引号,并且代码末尾也加上了分号。可惜的是 --fix 只能修复基础的不影响代码逻辑的错误,像 no-unused-vars 这种错误只能手动修改。
配置文件讲解
按照上述操作,会生成默认 .eslintrc.js
配置文件(当然ymly也可以),内容如下:
// .eslintrc.js
module.exports = {
"env": {
"browser": true,
"commonjs": true,
"es6": true
},
"extends": "eslint:recommended",
"parserOptions": {
"ecmaFeatures": {
"experimentalObjectRestSpread": true,
"jsx": true
},
"sourceType": "module"
},
"plugins": [
"react"
],
"rules": {
"indent": [
"error",
"tab"
],
"linebreak-style": [
"error",
"windows"
],
"quotes": [
"error",
"double"
],
"semi": [
"error",
"always"
]
}
}
该文件导出一个对象,对象包含属性 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规则表。
修改 .eslintrc.js 文件中的 rules 属性:
"rules": {
"indent": [
"error",
"tab"
],
"linebreak-style": [
"error",
"windows"
],
"quotes": [
"error",
"single" // 改成字符串必须由单引号括起来而不是双引号,'string'不报错,"string"报错
],
"semi": [
"error",
"never" // 改成代码结尾不再加分号,加了分号报错,不加分号不报错
],
"no-unused-vars": 0 // 0 相当于 off,表示关闭规则,相当于不再校验这条规则:变量定义了必须使用
}
此时再使用 npm run lint
进行代码校验,没有报错就说明校验通过,代码符合统一编码规范。
D:\code\test\20170811>npm run lint
> [email protected] lint D:\code\test\20170811
> eslint src
D:\code\test\20170811>
可能存在的疑问
刚接触 ESlint ,并不清楚有哪些规则怎么办,要去 eslint规则表 一条条记忆吗?答案是 no。
个人认为 ESlint 的配置文件并不是一次性完成的,而是在项目过程中慢慢完善的。你可以放心大胆的先进行编码,然后使用 npm run lint
校验代码的编码规范,如果这时候报错,你也可以更直观的在我下边看如何生成报告(Report),更直观的可以在报错信息中知道是哪一条编码规范报错了,你可能并不认识它们,此时去 eslint规则表 查询相应规则的使用方法,如:no-unused-vars
,从而进一步确定项目中是否需要这条编码规范,如果需要,进行局部调整即可。
常用的几个规则
"quotes": [1, "single"], # 单引号
"quote-props":[2, "as-needed"], # 双引号自动变单引号
"semi": [2, "never"], # 一行结尾不要写分号
"comma-dangle": [1,"always-multiline"] # 对象或数组多行写法时,最后一个值加逗号
———————————————————————————————————————————
在Angular中,默认的lint工具是 TSLint,项目中的 tslint.json 文件包含了默认的配置。
选项
选项 | 说明 |
---|---|
--configuration=configuration |
选择使用的配置。(angular.json文件里面的configuration配置) 缩写: -c |
--exclude |
lint的时候排除的文件。 |
--files |
lint的时候包含的文件。 |
--fix=true/false |
自动解决一些lint发现的简单错误 (可能会重写一些代码)。 默认值: false |
--force=true/false |
即使有lint错误也完成。 默认值: false |
--format=format |
输出格式 (prose, json, stylish, verbose, pmd, msbuild, checkstyle, vso, fileslist)。 默认值: stylish |
--help=true/false/json/JSON |
在控制台显示帮助信息。 默认值: false |
--silent=true/false |
显示输出文字。 默认值: false |
--tsConfig=tsConfig |
TypeScript配置文件的名称。 默认值: false |
--tslintConfig=tslintConfig |
Tslint配置文件的名称。 默认值: false |
--typeCheck=true/false |
lint是否执行类型检查。 默认值: false |
举例
选项 | 举例 |
---|---|
--configuration |
ng lint --configuration=production |
--exclude |
ng lint --exclude .\src\app\pages\home\home.component.ts |
--files |
ng lint --files .\src\app\pages\**\*.ts |
--fix |
ng lint --fix=true |
--force |
ng lint --force=true |
--format |
ng lint --format=json |
--help |
ng lint --help=true |
--silent |
ng lint --silent=true |
--tsConfig |
ng lint --tsConfig=tsconfig.x.json |
--tslintConfig |
ng lint --tslintConfig=tslint-x.json |
--typeCheck |
ng lint --typeCheck=true |