即刻起，加速您的前端构建

本文由云+社区发表

作者：志航

构建

影响前端发布速度的有两个方面，一个是构建，一个就是压缩，把这两个东西优化起来，可以减少很多发布的时间。

thread-loader

会将您的 loader 放置在一个 worker 池里面运行，以达到多线程构建。

把这个 loader 放置在其他 loader 之前（如下图 example 的位置）， 放置在这个 loader 之后的 loader 就会在一个单独的 worker 池(worker pool)中运行。

install

$ npm install --save-dev thread-loader

用法 和 exmaple

// webpack.config.js
module.exports = {
  module: {
    rules: [
      {
        test: /\.js$/,
        include: path.resolve("src"),
        use: [
          "thread-loader",
          // 你的高开销的loader放置在此 (e.g babel-loader)
        ]
      }
    ]
  }

每个 worker 都是一个单独的有 600ms 限制的 node.js 进程。同时跨进程的数据交换也会被限制。请在高开销的loader中使用，否则效果不佳

更多配置请查看：

happypack

，通过多进程模型，来加速代码构建。从 github 的 starts 数量来看，happypack 使用的人数比较多，比较受欢迎。

原理

相关的技术原理这里不再累赘，可以查看淘宝fed的相关文章

用法和example

var happypack = require('happypack');
var happythreadpool = happypack.threadpool({ size: os.cpus().length });

// ... 省略其余配置
module: {
  loaders: [
      {
        test: /\.less$/,
        loader: extracttextplugin.extract(
            'style',
            path.resolve(__dirname, './node_modules', 'happypack/loader') + '?id=less'
        )
      }
    ]
  },
  plugins: [
      new happypack({
        id: 'less',
        loaders: ['css!less'],
        threadpool: happythreadpool,
        cache: true,
        verbose: true
      })
  ]

构建方法总结

从实际使用的情况来看，thread-loader 和 happypack 对于小型项目来说打包速度几乎没有影响，是因为它本身的额外开销，例如i/o，建议只在大型项目中使用，可以先测试再投入生产环境。

压缩

不推荐使用 webpack-parallel-uglify-plugin

项目基本处于没人维护的阶段，issue 没人处理，pr没人合并。

推荐使用 terser-webpack-plugin

是一个使用 压缩js的webpack 插件。

压缩是发布前处理最耗时间的一个步骤，如果是你是在webpack 4 中，只要几行代码，即可加速你的构建发布速度。

用法和 example

const terserplugin = require('terser-webpack-plugin');

module.exports = {
  optimization: {
    minimizer: [new terserplugin(
      parallel: true   // 多线程
    )],
  },
};

更多用法请查看上面链接。

总结

随着 webpack 4 的优化，构建速度其实得到了极大的提升，也收到了parcel 等零配置web应用打包工具的启发，其实 webpack 的配置日趋简洁，何不尝试配置一下呢？

此文已由腾讯云+社区在各渠道发布

获取更多新鲜技术干货，可以关注我们