Javascript代码检查那点事
/ / 点击 /一时不做规范一时爽,一直不做规范一直爽。阿呸,代码规范这事,可小可大,如果一个项目长期没有规范检查,那么随着参与人数和代码量的增加,就会存在很多的潜在地雷,随时可能爆炸!本文将介绍如何安装和使用
EditorConfig
、eslint
、eslint staged
,从而实现Javascript
代码的增量检查。
一统代码风格 - EditorConfig
代码规范,从本地开始
在这里必须介绍一款神器:EditorConfig
,它可以帮助开发人员在不同编辑器和IDE中定义和维护一致的代码风格。该神器的精华全在一个叫做 .editorconfig
的文件中,我们来看一下一个典型的.editorconfig
文件。
1 | // 当打开一个文件时,EditorConfig插件会在打开文件的目录 |
浅显易懂有木有?且.editorconfig
的配置优先级将高于编辑器本身的配置,所以只要在项目根目录下创建该文件,那么就可以保证代码风格的一致性!
那么问题来了,只要手动创建该文件就运行了嘛?答案当然是不!像 webstorm
已经默认支持了 editorconfig
, 但是像 sublime
则需要安装额外的插件。
在 Sublime
中安装 Editorconfig
1 | // Mac |
那么问题又来了,虽然你本地做了代码风格统一,但你不能保证每一个参与者的编辑器都支持 EditorConfig
,难道每加入一个开发者你都要去喊他安装 EditorConfig
嘛?答案当然是可以的,不过最好还是做一层兜底!所以就需要用到 eslint
来做代码检查!
代码全量检查 - ESLint
什么是ESLint
ESLint是一个插件化的JS代码检测工具,可以用于检查常见的JS代码错误,也可以进行代码风格检查,通过ESLint配置,可以辅助编码规范的执行,有效控制项目代码的质量。
为什么要用ESLint
JS是非常灵活的弱类型语言,如果不进行约束,可能在某个特定的时候就爆出了
xxx is undefined
的错误而导致程序崩溃,所以需要辅助工具来帮助我们检查代码。
ESLint的优势与劣势
较早的代码检测插件如JSHint和JSCS,无法检测React JSX的语法,虽然衍生出了JSXHint等,但是并不是以插件的形式出现,而是重新包装了一个工具。
但是JSHint的速度要比ESLint更快。
ESLint的特点
- 默认规则包含了JSHint和JSLint的规则。
- 规则可配置性高:可设置警告、错误两个error等级。
- 包含代码风格检测的规则(可以丢掉JSCS了)
- 支持插件拓展、自定义规则。
开干!完成代码自动检查!
安装 eslint
和 pre-commit
1 | npm install --save-dev eslint |
在 package.json
中配置 eslint
检查和 pre-commit
1 | "scripts": { |
创建 eslint
检查规则:在项目根目录下创建 .eslintrc.js
文件,下面为一份配置 Demo
1 | // 项目说明:该项目是基于Vue2.0的项目 |
查看效果:如果是一个老项目,你可能会看到上千个报红!1
npm run lint
恭喜你,到此为止你每一次提交代码时都会自动完成一次全量检查!没错,是全量!对于老项目或者是比较大的项目,这是不合理的,所以需要优化为增量检查。
增量检查,GO!- Lint Staged
检测所有文件很慢且有的结果是无关紧要的,你更改关心的是本次改动的内容。这就是lint-staged的用处。
安装 lint-staged
和 husky
1 | npm install --save-dev lint-staged husky |
把之前全量检查在 package.json
中添加的内容全部删除,在 package.json
中添加如下内容
1 | // 只检查本次提交(add)的 |
完美,到此就完成了代码的增量检查!