1、背景
对于webpack来说,默认的配置都是单线程的,并没有充分利用电脑cpu的资源,可以充分利用cpu实现多线程打包和压缩项目,以达到节省编译时间的目的。
2、介绍&&使用
1⃣️、webpack-parallel-uglify-plugin
Webpack
默认提供的 UglifyJS
插件,由于采用单线程压缩,速度颇慢 ;推荐采用 webpack-parallel-uglify-plugin 插件,她可以并行运行 UglifyJS 插件,更加充分而合理的使用 CPU
资源,这可以大大减少的构建时间;当然,该插件应用于生产环境而非开发环境。
实现:
import ParallelUglifyPlugin from 'webpack-parallel-uglify-plugin';
module.exports = {
plugins: [
new ParallelUglifyPlugin({
// 可选的正则表达式或正则表达式数组以匹配文件。只有匹配的文件才会压缩。
// 默认为/.js$/,任何以.js结尾的文件。
test,
include, // 可选的正则表达式或正则表达式数组,包含在压缩中。只有匹配的文件才会压缩。
exclude, // 可选的正则表达式或要从压缩中排除的正则表达式数组。匹配文件不会压缩
cacheDir, // 用作缓存的可选绝对路径。如果未提供,则不使用缓存。
workerCount, // 可选,int。运行uglify的线程数量。默认为cpus的数量 - 1或固定数量(以较小者为准)
sourceMap, // 可选布尔值。这会减慢编译速度。默认为false。
uglifyJS: {
// 这些直接传递给uglify-js
// 不能与uglifyES一起使用。
// 如果没有提供uglifyJS或uglifyES,则默认为{}。
// 如果需要确保es5支持,则应使用此选项。
},
uglifyES: {
// 这些直接传递给uglify-es。
// 不能与uglifyJS一起使用。
// uglify-es是uglify的一个版本,它理解更新的es6语法。如果是,您应该使用此选项
}
}),
],
};
2⃣️、Happypack
Webpack
中为了方便各种资源和类型的加载,设计了以 loader
加载器的形式读取资源,但是受限于 nodejs
的编程模型影响,所有的 loader
虽然以 async
的形式来并发调用,但是还是运行在单个 node 的进程,以及在同一个事件循环中,这就直接导致了些问题:当同时读取多个loader文件资源时,比如`babel-loader`需要 transform 各种jsx,es6的资源文件。在这种同步计算同时需要大量耗费 cpu 运算的过程中,node的单进程模型就无优势了,而 Happypack 就是针对解决此类问题而生的存在。
Happypack
的处理思路是:将原有的 webpack
对 loader
的执行过程,从单一进程的形式扩展多进程模式,从而加速代码构建;原本的流程保持不变,这样可以在不修改原有配置的基础上,来完成对编译过程的优化。
具体配置如下:
var os = require('os')
var HappyPack = require('happypack')
var happyThreadPool = HappyPack.ThreadPool({ size: os.cpus().length })
module: {
loaders: [
{
test: /\.js[x]?$/,
include: [resolve('src')],
exclude: /node_modules/,
loader: 'happypack/loader?id=js'
}
]
},
plugins: [
new HappyPack({
// 通常情况下,不需要指定此项,除非定义了多个HappyPack插件,在这种情况下,需要使用不同的ID来区分
id: 'js',
// 包含将转换文件的加载程序的名称(或绝对路径)以及要传递给它的可选查询字符串。(Array)
loaders: ['babel-loader'],
// 用于检索工作线程的预定义线程池
threadPool: happyThreadPool,
// 启用此选项可将状态消息从HappyPack记录到STDOUT
verbose: true
})
]
问题:(未解决)
目前没发现为什么会报这个错误?。