【Q100】有了解过现在流行的 bundleless 构建工具吗？

[kangyana]

1. bundle-less

随着项目的规模发展，webpack 的构建速度越来越慢。

• 项目冷启动时必须递归打包整个项目的依赖树，
• Nodejs 语言本身(解释执行、单线程执行)的限制，导致构建性能遇到瓶颈。

因此，Bundleless 构建工具应运而生，诸如 Snowpack、Vite。

和 Webpack 这种传统的打包工具相比，Vite 主要有两大主要优势:

• 利用浏览器内置 ES Module 的支持。 (script 标签加上属性 type="module" 即可)，浏览器直接向 dev server 逐个请求各个模块，而不需要提前把所有文件打包。
• 借助 esbuild 超快的编译速度把第三方库进行 预构建。 一方面将零散的文件打到一起，减少网络请求，另一方面全面转换为 ESM 模块语法，以适配浏览器内置的 ESM 支持。

[kangyana]

2. bundle-less 做了什么？

• 拆包。 弱化传统意义上的打包概念，由单 bundle 拆分为数十或者上百个 bundle，这样可以更好地利用 HTTP2 的多路复用优势和提升缓存命中率。
• 对源代码不进行打包。 在开发阶段可以省略 bundle 的开销，如 Vite、Snowpack、WMR。
• 依赖产物的模块化分发。 对于庞大的外部依赖，一方面打包成本比较高，另一方面文件数量可能非常多，打包几乎是一个必选项，甚至需要多个 NPM 包合并打包。 因此，针对依赖的打包也是非常重要的优化点，一般可以通过预打包 + 模块化缓存来进行优化， 目前也有一些优化案例，如 Vite 中基于 Esbuild 的预打包器、基于 ESM 的 CDN 服务，如 Skypack、esm.sh、jspm 等。

3. 拆多少包更合适？

打的包太多或者太少都可能出现加载性能的问题。 比如过多的嵌套 import 导致网络瀑布流的产生、bundle 太少不能充分利用 HTTP2 下并发请求的优势。

针对这个问题，我们曾做过一系列的性能测试，最后得出的结论如下：

• 对于总产物资源大小相同的情况，资源加载分成的 chunk 数量在 10 - 25 之间进行并行加载性能最佳。
• 一次资源加载需要的依赖引用深度尽量等于 1 时加载性能最好。
• 由于不打包的情况下项目的请求数量和请求深度问题都不可控，因此不适合在生产构建中采用 no-bundle 方案。

4. no-bundle 服务

代表方案 Vite

在开发环境中，Vite 主要做了两件事情:

• 基于 esbuild 打包外部依赖。
• 创建 HTTP Server 以响应浏览器中 <script type="module"> 所发起的一系列模块请求。

而生产环境下直接使用 Rollup 进行打包。 Vite 整体的优势是在于开发阶段，服务启动快、热更新快，明显地优化了开发者体验。

劣势及解决方案

no-bundle 方案虽然省去了 bundle 的开销，但仍然需要进行单文件的编译(如 TS、JSX、Less、Sass)，编译的时长仍然可能会比较长(某些业务项目编译要 20 s 左右)。 Vite 在二次请求时会采用 Etag 标识返回协商缓存的内容，可以跳过编译消耗的时间，但服务重启后仍然需要进行全量的编译，体验不太好。 对此，一个比较好的解决方法是在服务退出时将 ModuleGraph 的内容缓存到本地，然后重启的时候激活缓存(hydrate)，那么二次启动时仍然会使用协商缓存，达到比较快的首屏加载效果。

海量请求的加载性能问题

请求数量达到一定量级(1000 +)的时候，no-bundle 服务都会遇到加载性能问题，对 Vite 而言，尽管二次请求会使用协商缓存，但实际上请求仍然会发送，在开发环境中(一般的业务项目会使用代理进行本地开发)表现仍然不容乐观，以之前接入 Vite 的某个业务项目为例:

	项目第一次构建	页面加载时间	热更新
webpack	80 s 构建	3~4 s	5 s
vite	10 s 构建	10 s	1 s
时间缩短	50%	-50%	80% 以上

经过一系列的尝试，最后发现 Service Worker 缓存可以很好地解决这一类问题，思路如下：

简单来说就是把 Vite 的编译结果缓存到 Service Worker，并对于 HMR 的模块及其依赖模块禁用缓存，保证模块的编译结果永远是最新的。 优化之后页面加载时间由 10s 降低到了 5 s 以内，可以追的上 webpack 的速度。

(Vite 独有)开发/生产表现不一致

有不少人会吐槽 Vite 开发/生产环境的不一致性，因为开发环境使用 Esbuild + Dev Server 架构，而生产环境直接用 Rollup。 但由于生产环境的构建场景和开发阶段存在天然差异，开发和生产表现一致是不现实的。 所以问题的核心在于保证生产环境构建的稳定性。

而影响生产构建稳定性最主要的部分在于依赖的处理上，进一步说是对于 CommonJS 格式的依赖处理上面， 开发环境使用 esbuild 而生产环境下使用 @rollup/plugin-commonjs，就容易导致生产构建出现一些奇怪的问题， 如 @rollup/plugin-commonjs ignoreTryCatch行为 try-catch 代码块中的 require 语法转换， 这样对于某些依赖(如 jspdf-autotable)就会出现问题，而开发阶段使用 Esbuild 就不会出现。

解决这类问题有两种方案:

• 生产环境也使用 esbuild 来进行依赖的打包，确保 CommonJS 的处理规则和开发阶段一致。 该 feature 已经实现，将在 Vite 3.0 发布。
• 开发和生产阶段使用 ESM CDN 方案，用同一套依赖产物。

[kangyana]

5. 依赖产物的模块化分发

对于第三方依赖，我们可以将其进行预构建，然后将产物进行分发，这样所有的依赖可以被 external 掉了，可以很大程度上降低项目 bundle 的开销。

总体而言，这类方案有几大关键要素：

• 预构建产物。
• 模块化方案。
• 产物分发机制。

接下来我们可以对照现有的案例来分析。

现有方案概览

首先是 Vite 的依赖预构建方案，使用 esbuild 对第三方依赖进行打包， 基于浏览器原生 ESM 特性来加载第三方包的产物，同时将产物存储在本地，可以通过 Dev Server 访问产物资源。

其次包括开源社区的一些 ESM CDN 方案，如 Skypack、esm.sh。 前者服务并未开源，后者使用 esbuild 进行模块打包或者单文件转译。 这类方案也是依赖于浏览器原生 ESM 特性实现产物加载，通过第三方的 CDN 来进行产物分发，如通过 https://esm.sh/react@18.0.2 即可访问到对应的 react 包产物。

问题分析

当然，现有的依赖 Bundleless 方案并不能很好地运用到业务项目中，尤其是生产环境，因为以下的几个关键问题没有得到根本的解决：

• 产物语法和 Polyfill 安全问题。
• 产物线上加载性能问题。
• 模块化加载方案的兼容性问题。
• 产物本地化调试问题。

产物语法和 Polyfill 安全问题

无论是 Vite 预构建还是社区开源的 Skypack 和 esm.sh 等 ESM CDN 方案，都不支持 ES3/ES5 语法降级，也没有基于 browserlist 的 polyfill 方案， 这样一来就很无法兼容旧版本浏览器，如大部分需要支持 Android 4.4 / iOS 9 机型的业务就无法使用这些方案。

产物的性能问题

Vite 会把项目中所有的依赖(包括 lodash/add 这种 subpath)各自打包为一个 bundle 文件，在大型项目中依赖产物的数量仍然很大(100 +)。 根据之前 Bundleless 性能测试的结果，巨大的文件请求数量显然会带来页面加载的性能问题。

而对于开源的 ESM CDN 方案，一般有两种构建模式，分别的 bundle 模式和非 bundle 模式。 在非 bundle 模式下会存在严重的网络瀑布流问题，而 bundle 模式下会把所有的间接依赖都打包进去，容易造成某些公共依赖重复打包的问题，使产物性能变差。 同时，这些 ESM CDN 方案都不支持产物的 Tree Shaking，对于任何包都只能全量引入依赖产物，无法做到按需加载。

模块化方案的兼容性问题

如果在生产环境也使用 ESM 格式的产物，那么很可能会产生兼容性问题，目前浏览器对于原生 ESM 的兼容性如下图：

对于需要兼容 IE11 或者低版本移动端机型的项目，现有的 ESM CDN 方案就无法使用了。

产物本地化调试问题

Vite 的预构建产物可以在本地使用，通过 Dev Server 分发，但也有一定的弊端：

• 如果要调试产物，则需要开发者手动清除浏览器缓存。
• 产物仅存在本地，团队成员之间无法共享产物。

而现有的 ESM CDN 产物本地化方面也显得捉襟见肘：

• 本地开发只能使用第三方 CDN，调试产物会比较困难。
• 项目线上部署时也只能使用第三方 CDN 的资源，无法做到私有化部署。

[kangyana]

6. 依赖产物的模块化分发 的解决方案

   面对如上的核心问题，我们可以逐个展开思考，各个击破，解决思路分别如下:

• 对于产物语法和 Polyfill 安全问题。 在预构建阶段，可通过 babel/swc 编译出特定 target (视项目情况而定)下的安全产物。
• 对于产物线上加载性能问题。 我们需要完成一套项目依赖分析工具，对项目的模块依赖图进行分析，将项目使用到的依赖进行合并(combo)打包，使最后依赖的产物 chunk 数量保持在性能最佳的范围之内。
• 对于模块化加载方案的兼容性问题。 我们可以在无需兼容旧版本浏览器的项目使用原生 ESM 特性，否则降级为 SystemJS 加载方案。
• 对于产物本地化调试和部署问题。 我们一方面需要维护一份第三方 CDN 服务，类似 Skypack、esm.sh，另一方面需要支持将 CDN 产物下载至本地，并通过特定的模块化加载方案来加载这些本地的产物。

根据如上的业界方案问题分析与解决思路，我们自研了一套依赖 Bundleless 的方案，整体架构如下:

基于 Import Map

在现有的社区方案中，一般用路径重写的方式来管理 CDN 依赖的路径，比如：

import React from 'react'
// 改写为
import React from '/-/v70/react@v17.0.1'

这么做导致一些问题：

• 多实例问题。 在产物代码中将路径写死，这样对于 peerDependencies 不太友好， 比如某个组件库的 React 引用路径被改写为/v1/react@16.14，而项目依赖的 React 版本为 17.0.2，那么就会产生 React 多实例问题。
• 缓存命中率比较低。 如果 A 依赖 B，B 的代码发生变化，那么 A 里面对应的 import 代码也发生变化，A 的缓存也会失效。

我们希望用一个集中的空间来管理依赖关系，并避免多实例的问题，而 Import Map 就可以解决这些问题。接入原理如下：

<script type="importmap">
{
"imports": {
    // 保证单实例
    "react": "https://tosv.byted.org/obj/eden-internal/ulkl_lm_zlp/ljhwZthlaukjlkulzlp/npm_cdn/dev/react/17.0.2/0636c3a4.js",
    "react-dom": "https://tosv.byted.org/obj/eden-internal/ulkl_lm_zlp/ljhwZthlaukjlkulzlp/npm_cdn/dev/lodash/4.17.21/8ba9d138.js"
  }
}
</script>
<script type="module">
import React from 'react';
import ReactDOM from 'react-dom'
</script>

模块合并

首先基于 esbuild 将项目进行预打包(性能考虑)，需要开启 metafile 配置，在 onEnd 钩子或者 build API 的返回值中可以获取构建元信息，即 meta 对象，由 inputs 字段可以解析出模块依赖图。

// meta 对象
{  
  "inputs": {
    // 当前模块路径
    "../node_modules/.pnpm/object-assign@4.1.1/node_modules/object-assign/index.js": {
      // 模块大小
      "bytes": 2108,
      // 依赖模块数组
      "imports": []
    },
    "../node_modules/.pnpm/react@17.0.2/node_modules/react/cjs/react.development.js": {
      "bytes": 72141,
      "imports": [
        {
          "path": "../node_modules/.pnpm/object-assign@4.1.1/node_modules/object-assign/index.js",
          "kind": "require-call"
        }
      ]
    },
  }
}

根据当前的模块依赖图信息，我们可以将项目中用到的依赖进行分组，通过特定的依赖分组算法产出一些依赖组的信息。

多包(combo)模式打包

Combo 模式打包即把多个依赖包打包到一起，主要会产生如下的问题：

• 多包出现导出名称冲突。
• Subpath 问题大量出现的问题。

解决方案：

不同包的导出名冲突问题

首先需要解决命名导出的问题，整体由两部分构成。 在构建时阶段注入一些带有包名前缀的 specifier，运行时根据包名取出这些 specifier，从根本上解决导出名冲突问题。

1. 构建时注水 在构建之前需要探测 NPM 包所有的导出，包含以下的情况：

• ESM
  • Named/Default export，通过 es-module-lexer 扫描。
  • export * from 'xxx'，通过 esbuild 预打包，开启 metafile 模式，在 metafile 中获取所有的 export 名。
• CJS
  • 尝试通过直接 require 拿到所有的导出名。
  • 若 require 失败，降级到 AST 解析，分析所有的导出名。

在拿到所有导出名的基础之上，构建虚拟模块，交由 bundler 进行打包，格式如下：

export { 包名_导出字段名 } from '包名';

也就是在 NPM 包每个导出名前面加上 包名_，完成注水过程，以防止重名。

2. 运行时脱水 (Hydrate) 如上 包名_导出字段名 的这种导出在业务中是直接使用的，我们需要在模块系统中进行运行时拦截(脱水过程)，把真正的导出字段名取出。

如以下的导入：

// 在以 esm 的方式对依赖进行 external 后，webpack 产物中的引入代码
import * as __WEBPACK_EXTERNAL_MODULE_react_router_ from 'react-reouter'

我们将会改写成以下的代码：

// 1. 换成临时变量
import * as __WEBPACK_EXTERNAL_MODULE_react_router_$0 from "react-router";
// 2. 对原来的变量重新赋值，通过 __EDEN_COMBO_HYDRATE__ 工具函数将导出名去掉包名前缀
// 如 react_router_Router => Router
var __WEBPACK_EXTERNAL_MODULE_react_router_ = __EDEN_COMBO_HYDRATE__(
  __WEBPACK_EXTERNAL_MODULE_react_router_$0,
  "react_router"
);

大量 subpath 问题

做实际落地项目的过程中发现第三方包中使用大量的 subpath，如下图的依赖分组结果所示：

这种情况下 import map 的体积会很大，因为每个 subpath 都会对应一个远程地址。 解决方案是进行 subpath 合并打包，如 @babel/runtime/helper/esm/assertThisInitialized、@babel/runtime/helpers/esm/inheritsLoose，原始产物中的引入代码如下:

import * as __WEBPACK_EXTERNAL_MODULE_babel_runtime_helers_esm_inheritsLoose from '@babel/runtime/helpers/esm/inheritsLoose';
import * as __WEBPACK_EXTERNAL_MODULE_babel_runtime_helers_esm_assertThisInitialized from '@babel/runtime/helpers/esm/assertThisInitialized';

这样对于 @babel/runtime 只留下一个 importmap 的 key-value 对，有效减少 import map 的体积。

产物 Tree Shaking

在 esbuild 预打包阶段扫描源文件所用到的 specifier，然后构建对应的虚拟模块交给打包器进行打包：

export { cloneDeep } from 'lodash-es'
export { Spin } from '@douyinfe/semi-ui'

这样可以做到一定程度的 Tree Shaking。

Polyfill 安全

根据不同的 runtimeTarget 要求(Eden 默认自带以下前三种 runtimeTarget，包括 Modern、PCLegacy、MobileLegacy)和产物模块格式，注入不同的 Polyfill 内容：

• 现代浏览器：注入 import map 的 polyfill 即可
• PC 端老旧浏览器：PC 端默认 browserlist 下所有第三方包所需的 Polyfill + Systemjs 产物
• 移动端老旧浏览器：移动端默认 browserlist 下所有第三方包所需的 Polyfill + Systemjs 产物
• 自定义 runtimeTarget 或模块格式：指定 browserlist 下所有第三方包所需的 Polyfill，如果是 Systemjs 格式，则加入 Systemjs 的 Polyfill

Polyfill 内容在所有第三方包编译完成后进行累计去重，然后统一打包成一个 Chunk，通过 script 标签注入到页面中：

产物本地化

依赖产物本地化有两个好处:

• 可以在本地调试依赖的产物代码。
• 可以将依赖产物代码同业务代码一同部署(私有化部署)。

具体的做法如下： 在使用编译服务将依赖包打包完成并上传 CDN 后，构建插件会重新请求 CDN 的资源，并将资源写入到本地磁盘中。

然后，构建插件通过在本地 Dev Server 加入中间件来对本地临时目录启用静态资源服务。 与此同时，插入到 HTML 中的 import map 的远程 CDN 产物被改写为本地静态资源服务的地址。 因此，最后项目中访问到的第三方包资源即为临时目录中的产物代码。