平时做的项目中很多都采用webpack去构建，但由于js单线程的特点，使用默认配置只能单线程去启动应用。当项目体积过大时，启动1分钟左右是很正常的事。如果我们联想到传说中的“墨菲定律”，自然就会有个问题：可以尝试多线程构建项目吗？
想到这里，恭喜您已经击败了全国90%的选手！
在此安利一个webpack第三方npm插件，happypack（www.npmjs.com/package/hap…）
接下来是常规用法（引包+new+配置）：
1.引包：
在webpack的配置文件中引入happypack
const HappyPack = require('happypack');
2.没有那就new一个：
new HappyPack()
3.配置：
new HappyPack({
id: “babel”,
threadPool: happyThreadPool,
loaders: [
...,
loader: "babel-loader",
...
]
})
4.补充缺少参数：
（1）threadPool：
共享进程池，由HappyPack实例去管理。此处应采用HappyPack.ThreadPool(size: 16)赋值当前电脑的线程信息。其中size为当前电脑cpu的线程总数，调用node核心模块os可以获取到cpu信息：
const happyThreadPool = HappyPack.ThreadPool({
size: os.cpus().length
})
尝试打印输出
{
size: 16,
start: [Function: start],
isRunning: [Function: isRunning],
compile: [Function: compile],
stop: [Function: stop]
}
（2）loaders:[]
很多小伙伴看到这里有些疑问：一般loader属于模块，是要配置在modules里，但这里的loaders是有什么不同吗？
其实既然用了loaders，我们就把modules里需要并行处理的loader全部移到这里。因为构建的大部分时间全消耗了loader的过程，所以我们要用happypack去管理loader，将loader的任务分成不同线程去执行，这样就加快了构建速度。
然后我们需要改造一下原来在modules里的loader。
将
loaders: [...，loader: "babel-loader"，...]
改造成
use：'happypack/loader',
这就是告诉webpack通过happypack插件中的loader去处理某些文件。
如果有多个HappyPack实例，需要匹配HappyPack的id，如：
use：'happypack/loader?id=babel'
5.效果展示：
在此我在github上找了一个项目：github.com/bailicangdu…，便于演示加速效果。
加速配置前（15.57s）：
加速配置后（0.576s）：
至于这个测速插件，请大家自行参考：www.npmjs.com/package/spe…，我也会在后续的文章中记录。
