前言
在前端的协作开发中,保持团队的代码风格统一是很有必要的。即使是自己开发,保证代码风格统一也觉得赏心悦目,本文通过最简单的方式来实现ESLint与VSCode的结合。
首先说一下思路。在前端代码检查过程中,eslint与prettier几乎是黄金搭配。前者做代码质量检查,后者做风格检查。并且prettier可以自动修复,从而保证git提交之前团队的代码风格是统一的,质量也可以得到一定的保证。
质量检查 VS 风格检查
质量检查可以帮助你发现一些潜在的错误,比如你的JS对象可能存在相同的key,这可能是你不经意间犯得的错误,导致先声明的key被覆盖了,这可能会引起一些问题,而质量检查帮助你提前发现这个问题。
以下模仿不经意的一个书写错误
开启eslint对重复的key予以提示
显然,以上的情况可能发现潜在的错误,有时候那些难以追踪到问题的bug,往往是不经意的一个小错误引起的
另一方面,代码风格则是帮助一个团队统一格式,常见的如下:
- 代码缩进个数
- 语句结尾是否添加分号
- 使用单/双引号
- 方法体与语句的空行数
如上等等,显然不会对质量造成什么问题,但风格的统一容易在多人协作中更好的交叉工作。比如Vue.js的官方文档就单独有一篇文章来阐述其推荐的代码风格,比如v-for需要指定v-key这种,更多可以参考其文档
备注:缩进尽量使用空格而不是tab,比如在shell脚本中使用tab是无法完整执行整个脚本的,而空格则可在各种语言中作为缩进
现状与实践
虽然ESLint与Prettier是黄金搭配,但实际上,ESLint功能已经太强大了,他已经涵盖了prettier的功能。也就是他既对代码质量做检查,也对代码的风格做检查。ESLint把自身可以检查的内容,归为以下几类
- Possible Errors 即潜在的错误
- Best Practices 即最佳实践,也就是推荐使用
- Stylistic Issues 即风格问题。
- … 更多详见官方中文文档
更有甚者,他还有一款专门实现了一个prettier检查内容的插件eslint-plugin-prettier,理论上,我们只用使用ESLint以及该插件,就已经可以实现代码质量与风格的一次性的引入,但安装并使用此插件后,可能prettier的风格与ESLint的其他风格产生冲突,这一点可以参考这里。解决方式就是安装eslint-config-prettier,来排除掉不必要的或与prettier冲突的ESLint规则。
所以你的配置文件最终可能是这样的
// 安装依赖
npm install --save-dev eslint-plugin-prettier
npm install --save-dev --save-exact prettier
npm install --save-dev eslint-config-prettier
// 修改.eslintrc的配置文件如下
{
"parserOptions": {
"ecmaVersion": 6
},
"plugins": ["prettier"],
"extends": [
"eslint:recommended", // 官方推荐的的规则
"prettier" // 排除掉官方推荐中与prettier冲突的规则
],
"rules": {
"prettier/prettier": "error" // prettier的规则
}
}
结尾
文章最后,还需说明,prettier其实是一个code formatter,也就是他会格式化代码,这一点理论上eslint是不会做的。毕竟格式化代码可能会有一些意想不到的问题产生,而且比如你使用一个未定义的变量,虽然eslint报错了,但对此问题无法进行任何修改。
但我们已经不打算单独使用prettier了,而是将其作为eslint的插件。庆幸的是,格式化代码的任务可以由VSCODE来完成,实际上VSCODE本身也具备格式化代码的功能,他有一个钩子函数Action,即每当你保存代码的时候来触发。只需进行如下的配置
看一下最终效果
备注
- 尽量不要再使用TSLint了,已经不再维护了。
- 关于eslint中的plugin与config。我个人理解是,config只是提供了一些rules的集合,而插件提供更多的功能,但最终也会提供出一些rules的集合,甚至多种维度的集合。比如上文提到的eslint-plugin-prettier插件提供了prettier/standard,prettier/react等等多套规则的集合。也就是插件功能会更强大一些。因具体情况而选择。