新一代前端构建工具对比

精读

按照从底层到上层的封装粒度，以 esbuild、snowpack、vite、wmr 的顺序介绍。

esbuild

esbuild 使用 go 语言编写，由于相对 node 更为底层，且不提供 AST 操作能力，所以代码执行效率更高，根据其官方 benchmark 介绍提速有 10——100 倍：

esbuild 有两大功能，分别是 bundler 与 minifier，其中 bundler 用于代码编译，类似 babel-loader、ts-loader；minifier 用于代码压缩，类似 terser。

使用 esbuild 编译代码方法如下：

esbuild.build({

entryPoints: ["src/app.jsx"],

outdir: "dist",

define: { "process.env.NODE_ENV": '"production"' },

watch: true,

});

但由于 esbuild 无法操作 AST，所以一些需要操作 AST 的 babel 插件无法与之兼容，导致生产环境很少直接使用 esbuild 的 bundler 模块。

幸运的是 minifier 模块可以直接替换 terser 使用，可以用于生产环境：

esbuild.transform(code, {

minify: true,

});

由于 esbuild 牺牲了一些包大小换取了更高的执行效率，因此压缩后包体积会稍微大一些，不过也就是 177KB 与 165KB 的区别，几乎可以忽略。

esbuild 比较底层，所以可以与后续介绍的上层构建工具结合使用，当然根据工具设计理念，是否内置，内置到什么程度，以及是否允许通过插件替换就是另一回事了。

snowpack

snowpack 是一个相对轻量的 bundless 方案，之前也写过一篇精读 snowpack，其实 bundless 就是利用浏览器支持的 ESM import 特性，利用浏览器进行模块间依赖加载，而不需要在编译时进行。

跳过编译时依赖加载可以省很多事，比如不用考虑 tree shaking 问题，也不用为了最终产物加速而使用缓存，相当于这些工作交给最终执行的浏览器了，而浏览器作为最终运行时容器，比编译时工具更了解应该如何按需加载。

仅从编译时来看，修改单个文件的编译速度与项目整体大小有关，而若不考虑整体项目，仅编译单个文件（最多递归一下有限的依赖模块，解决比如 TS 类型变量判断问题）时间复杂度一定是 O(1) 的。

实际上我们很少单独使用 snowpack，因为其编译使用的 esbuild 还未达到 1.0 稳定版本，在生态兼容与产物稳定性上存在风险，所以编译打包时往往采用 rollup 或 webpack，但这种割裂也导致了开发与生产环境不一致，这往往代表着更大的风险，因此在 vite 框架可以看到这块的取舍。

snowpack 是开箱即用的：

// package.json

"scripts": {

"start": "snowpack dev",

"build": "snowpack build"

我们还可以增加 snowpack.config.js 配置文件开启 remote 模式：

// snowpack.config.js

module.exports = {

packageOptions: {

"source": "remote",

}

};