为什么要用eslint
每个开发都有自己的编码习惯或风格，很难说谁的代码写的好看，谁的代码写的不好看。对于一个团队项目，如果每个开发都按自己的风格来写代码，项目代码整体来看一定是趋于混乱的。
使用文档或者口头进行约束，再定期进行代码review，也是一种方法，但难以落实，初期可能还行之有效，慢慢的就开始懈怠，也不进行review了，每个开发又开始按自己喜欢的风格进行开发了。最好的方法还是使用工具进行规范。
使用单引号还是双引号，要不要加分号，缩进用2个空格还是4个空格，都没有问题，最重要的是整个项目风格的统一。
开始使用eslint
不仅仅是格式
1. 编辑器安装elint插件
以VsCode为例，在商店搜索eslint安装，然后重启VsCode。如果你使用的是其他编辑器，嗯？换了吧，用VsCode，香！
eslint插件
2. 安装eslint依赖
可以全局安装，也可以安装到当前项目
- 全局安装
npm i eslint -g - 当前项目安装（推荐）
npm i eslint --save-dev
3. 生成配置
如果eslint是全局安装，在项目根目录执行eslint --init，否则在当前根目录执行./node_modules/eslint/bin/eslint.js --init
执行这个命令后，根据选项生成配置，下图是我选择的，可以参考
生成配置
4. 验证和修改配置
执行完第3步后会在根目录生成.eslintrc.js文件，打开代码，可以看到有些代码被画了红色波浪线，这是不符合规范的代码，鼠标放上去可以查看具体信息，有些校验我们不需要，通过修改配置可以去掉。把校验规则复制到.eslintrc.js文件的rules下，值为0，就去掉了这个校验。
格式问题按Ctrl+s保存会自动根据eslint格式化，其他问题需要手动处理。
校验
修改配置
修改配置后效果
配置全局校验格式化命令
如果你已经开发了一部分代码，后期才引入eslint，可以配置格式化命令，对整个工程进行eslint校验并格式化。
在package.json的scripts里添加配置"lint": "eslint --fix --ext .js src"
执行npm run lint命令会对src目录下的.js后缀的文件进行eslint校验，加了--fix会直接进行格式化，其他问题需要手动处理。
配置命令
webpack alias别名校验问题
一般我们会在webpack里配置别名，比如配置@指向src目录，方便引用，但是eslint不认识，需要额外的处理。当然也可以直接在.eslintrs.js里配置去掉这个校验，但这种一刀切的方式是不推荐的。
// 配置别名
alias: {
"@": path.resolve(__dirname, "src"),
},
别名校验问题
我们使用eslint-import-resolver-alias插件来解决上面这个问题
- 安装插件
npm i eslint-import-resolver-alias --save-dev - 在.eslintrc.js里添加配置
module.exports = {
settings: {
"import/resolver": {
alias: {
map: [
['@', path.resolve(__dirname, "src")],
]
}
}
},
...
}
git提交代码时校验
1. 安装husky npm i husky --save-dev
install完成后，husky会自动配置 git hooks
2. 在package.json里添加配置
{
...
"husky": {
"hooks": {
"pre-commit": "npm run lint"
}
}
}
这样在git commit的时候会先执行eslint校验，npm run lint是前面我们配置在scripts里的命令，对src下的js进行校验并格式化。但这样每次提交都全量校验，没有必要。
下面我们来配置增量校验
3. 安装lint-staged npm i lint-staged --save-dev
从插件的名字就可以看出，这个插件是实现对staged（已加入git暂存区的文件）进行校验
4. 修改package.json
{
...
"husky": {
"hooks": {
"pre-commit": "lint-staged"
}
},
"lint-staged": {
"src/*.js": [
"eslint --fix --ext .js",
"git add"
]
}
}
这样就实现了git提交代码时对修改的文件进行eslint校验。
小提示：commit时加--no-verify可以跳过校验哦
网友评论