Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

webpack多页应用架构系列(九):总有刁民想害朕!ESLint为你阻击垃圾代码 #21

Open
Array-Huang opened this issue Nov 16, 2019 · 0 comments

Comments

@Array-Huang
Copy link
Owner

前言

刁民,还不退下?啊……来人啊快救驾!

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

你写代码是不是特粗心?经常落下些语法错误,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的插件,一写了有问题的代码,就马上会标识出来,如下图所示:

image

示例代码

诸位看本系列文章,搭配我在Github上的脚手架项目食用更佳哦(笑):Array-Huang/webpack-seedhttps://github.com/Array-Huang/webpack-seed)。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant