总有刁民想害朕！ESLint为你阻击垃圾代码

前言

刁民，还不退下？啊……来人啊快救驾！

你所在的团队里有没有“老鼠屎”？就是专门写各种看起来溜得飞起但实际上晦涩难懂的代码？又或是缩进换行乱成一团？

你写代码是不是特粗心？经常落下些语法错误，debug起来想死？

如果你有以上问题，ESLint帮到你！[手动滑稽]

ESLint的用途是？

从上面两个应用场景，你大概已经猜到ESLint是用来干什么的了：

• 审查代码是否符合编码规范和统一的代码风格；
• 审查代码是否存在语法错误；

语法错误好说，编码规范和代码风格如何审查呢？ESLint定义好了一大堆规则作为可配置项;同时，一些大公司会开源出来他们使用的配置（比如说airbnb），你可以在某套现成配置的基础上进行修改，修改成适合你们团队使用的编码规范和代码风格。

本文主要讲什么？

本文着重介绍如何在webpack里整合进ESLint，而并不介绍ESLint本身，因此，对于没有使用过ESLint的小伙伴，请先去自己入门一下啦。

webpack如何整合ESLint？

这次我们需要使用到eslint-loader，先放出配置的代码：

/* 这是webpack配置文件的内容，省略无关部分 */
{
  module: {
    preLoaders: [{
      test: /\.js$/, // 只针对js文件
      loader: 'eslint', // 指定启用eslint-loader
      include: dirVars.srcRootDir, // 指定审查范围仅为自己团队写的业务代码
      exclude: [/bootstrap/], // 剔除掉不需要利用eslint审查的文件
    }],
  },
  eslint: {
    configFile: path.resolve(dirVars.staticRootDir, './.eslintrc'), // 指定eslint的配置文件在哪里
    failOnWarning: true, // eslint报warning了就终止webpack编译
    failOnError: true, // eslint报error了就终止webpack编译
    cache: true, // 开启eslint的cache，cache存在node_modules/.cache目录里
  }
}

接下来解释一下这份eslint-loader的配置。

为嘛把eslint-loader放在preLoaders而不是loaders里？

理论上来说放loaders里也无伤大雅，但放preLoaders里有以下好处：

• 放在preLoader是先于loader的，因此当ESLint审查到问题报了warning/error的时候就会停掉，可以稍微省那么一点点时间吧大概[手动滑稽]。
• 如果你使用了babel，或类似的loader，那么，通过webpack编译前后的代码相差就很大了，这会造成两个问题（以babel为例）：
  • babel把你的代码转成什么样你自己是无法控制的，这往往导致无法通过ESLint的审查。
  • 我们实际上并不关心编译后生成的代码，我们只需要管好我们自己手写的代码即可，反正谁也不会没事去读读编译后的代码吧？

如何传参给eslint-loader？

从eslint-loader官方文档可以看出，eslint-loader的配置还是比较多也比较复杂的，因此采用了独立的一个配置项eslint（跟module同级哈）。

总结

只要你能在自己团队里成功推行ESLint，那么最起码，你可以放心不用再看到那些奇奇怪怪的代码了，因为，它们都编译不通过呐哈哈哈哈哈……

后话

通过webpack整合ESLint，我们可以保证编译生成的代码都是没有语法错误且符合编码规范的；但在开发过程中，等到编译的时候才察觉到问题可能也是太慢了点儿。

因此我建议可以把ESLint整合进编辑器或IDE里，像我本人在用Sublime Text 3的，就可以使用一个名为SublimeLinter的插件，一写了有问题的代码，就马上会标识出来，如下图所示：