webpack多页应用架构

教练我要写ES6！webpack怎么整合Babel？

前言

一直以来，我对ES6都不甚感兴趣，一是因为在生产环境中使用ES5已是处处碰壁，其次则是只当这ES6是语法糖不曾重视。只是最近学习react生态，用起babel来转换jsx之余，也不免碰到诸多用上ES6的教程、案例，因此便稍作学习。这一学习，便觉得这语法糖实在是甜，忍不住尝鲜，于是记录部分自觉对自己有用的方法在此。

这是我数月前的一篇文章《ES6部分方法点评（一）》中的一段，如今再看我自己的代码，触目皆是ES6的语法。在当前的浏览器市场下，想在生产环境用上ES6，Babel是必不可少的。

由于我本身只用了ES6的语法而未使用ES6的其它特性，因此本文只介绍如何利用webpack整合Babel来编译ES6的语法，而实际上若要使用ES6的其它属性甚至是ES7（ES2016），其实只需要引入Babel其它的preset/plugin即可，在用法上并无多大变化。

用到哪些npm包？

首先要说到的是babel-loader，这是webpack整合Babel的关键，我们需要配置好babel-loader来加载那些使用了ES6语法的js文件；换句话说，那些本来就是ES5语法的文件，其实是不需要用babel-loader来加载的，用了也只会浪费我们编译的时间。

然后就是babel相关的npm包，其中包括：

• babel-core，babel的核心，没啥好说的。
• babel-preset-es2015-loose，babel的preset（相当于是一整套plugin）。babel是有许多preset的，看自己需要来选用，比如说我只管ES6（ES2016）语法的就可以用babel-preset-es2015或babel-preset-es2015-loose。这俩preset其实用法一样，差别就在于：

  许多Babel的插件有两种模式：

尽可能符合ECMAScript6语义的normal模式和提供更简单ES5代码的loose模式。

优点：生成的代码可能更快，对老的引擎有更好的兼容性，代码通常更简洁，更加的“ES5化”。

缺点：你是在冒险——随后从转译的ES6到原生的ES6时你会遇到问题。

我自己的考虑是，肯定要更好的兼容性和更好的性能啦这还用想的吗？（敲黑板）

• babel-plugin-transform-runtime和babel-runtime，这属于优化项，不用也没啥问题，下文会细说。

如何配置babel-loader

babel-loader的配置并不复杂，与其它loader并无二致：

    {      test: /\.js$/,      exclude: /node_modules|vendor|bootstrap/,      loader: 'babel-loader?presets[]=es2015-loose&cacheDirectory&plugins[]=transform-runtime',    },

下面来详细解释此配置：

• test: /\.js$/表明我只用babel-loader来加载js文件，如果你只是小部分js文件应用了ES6，那么也可以给这些文件换个.es6的后缀名并把此处改为test: /\.es6$/。
• exclude: /node_modules|vendor|bootstrap/，上文已经说到了，不需要用babel来加载的文件还是剔除掉，否则会大量增加编译的时间，一般我们只用babel编译我们自己写的应用代码。
• loader: 'babel-loader?presets[]=es2015-loose&cacheDirectory&plugins[]=transform-runtime'，这一行是指定使用babel-loader并传入所需参数，这些参数其实也是可以通过babel配置文件.babelrc，不过我还是推荐在这里以参数的方式传入。下面来介绍这些参数：

preset参数：babel-preset-es2015-loose

上文已经解释过preset是什么以及为啥要使用babel-preset-es2015-loose了，这里不再累述。

cacheDirectory参数

cacheDirectory参数默认为false，若你设置为一个文件目录路径（表示把cache存到哪），或是保留为空（表示操作系统默认的缓存目录），则相当于开启cache。这里的cache指的是babel在编译过程中某些可以缓存的步骤，具体是什么我也不太清楚，反正是只要开启了cache就可以加快webpack整体编译速度。我测试了一下，未开启cache的时候我的脚手架项目(Array-Huang/webpack-seed)需要15秒半来编译；而开启cache后的第一次编译时间并没有减少，第二次编译则变为14秒了，足足减少了1秒半了棒棒哒。

plugins参数

虽说一个preset已经包括N个plugin了，但总有一些漏网之鱼是要专门加载的。这里我只用到了transform-runtime，这个plugin的效果是：不用这plugin的话，babel会为每一个转换后的文件（在webpack这就是每一个chunk了）都添加一些辅助的方法（仅在需要的情况下）；而如果用了这个plugin，babel会把这些辅助的方法都集中到一个文件里统一加载统一管理，算是一个减少冗余，增强性能的优化项吧，用不用也看自己需要了；如果不用的话，前面也不需要安装babel-plugin-transform-runtime和babel-runtime了。

总有刁民想害朕！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的插件，一写了有问题的代码，就马上会标识出来，如下图所示：