ESLint结合VSCode的简单实践

前言

在前端的协作开发中，保持团队的代码风格统一是很有必要的。即使是自己开发，保证代码风格统一也觉得赏心悦目，本文通过最简单的方式来实现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，即每当你保存代码的时候来触发。只需进行如下的配置

看一下最终效果

备注

1. 尽量不要再使用TSLint了，已经不再维护了。
2. 关于eslint中的plugin与config。我个人理解是，config只是提供了一些rules的集合，而插件提供更多的功能，但最终也会提供出一些rules的集合，甚至多种维度的集合。比如上文提到的eslint-plugin-prettier插件提供了prettier/standard，prettier/react等等多套规则的集合。也就是插件功能会更强大一些。因具体情况而选择。