2021-10-14 巨石应用解决方案 nopack

多小凯

2021-10-14

bundless

1. 背景

最近一段时间陆续有同学吐槽，现有的开发环境打包 📦 太慢了，原话如下

同学 a: xxx 项目冷启动，刚刚计时是 3 分 45 秒左右，有空看看是否有优化空间哈。
视频是 xxx 项目 f-xxx-6196 分支（yarn dev 回车后开始计时）
同学 b: 本地运行太慢了，想砍人
同学 c: 我们项目启动很慢，咋整
同学 d: xxx 项目编译时间太长了，改个东西容易电脑卡，不排除我的电脑问题，体验很差

也确实，3 分 45 秒 🐢🐢🐢 的等待时间谁又受得了 😣！那么我们现在的脚手架的问题出在哪里 🤔?

现有脚手架是基于 webpack 打包，对于 babel，TypeScript 等编译做了缓存优化，甚至 hard-source 这样的持久缓存。但是由于业务需求的快速迭代，一切换分支导致大量 node_modules 依赖变化使得大部分缓存都未能命中 ❌

所以当现有的优化手段都命中 ✅ 的时候，时间才能勉强减少到 40 秒 🐢 左右。

webpack5 也尝试去解决慢的这个问题，比如新增了比较重量级的持久缓存 cache.type: filesystem 功能以及仍在实验中的懒编译 experiments.lazyCompilation 功能，不过从 esbuild 官方给大家的数据来看，webpack5 却是最慢的 😢!

关于 webpack 的 experiments.lazyCompilation 功能, 在内网的同学可以继续阅读 2019-09-10 凯多动态路由插件 分享, 其实两年前我已经实现了该功能来解决巨石应用的打包慢的问题，只是最后的提升很有限。

这可能是 webpack5 被黑得最惨的一次… 因为第一次打包有一部分时间是在生成与写入缓存，怎么不拿第二次缓存生效后的时间来遛一遛比一比了？在这种情况下，我们升级 webpack5 可能还是解决不了痛点，频繁的分支切换又会回到解放前 !

当项目逐渐膨胀时，似乎是已经到了 webpack 的瓶颈，近期特别火的 Vite 与 Snowpack 或许才是真正的解决方案 🤔?

2. vite 与 snowpack

最初我想到的是接入 Vite 或者 Snowpack 解决现有的问题，关于提到的这些工具的原理，有不少文章都讲得很好了，这里就不做过多的介绍。

Snowpack 刚出来不久就认真充满好奇的读了它的代码，发现里面有不少 hack 的实现，比如 define 是通过字符串的替换去实现（这明显就会误伤无辜），css 文件中的 import 也没处理，最近作者说会交给社区去维护，自己有些力不从心了。

Real-world testing is super important. I’m sure that sounds cliche，but its true. We had a few starter projects that we could test Snowpack against，but they were all small and simple. This created a huge experience gap between our internal projects and our actual users.

文章出自 6 More Things I Learned Building Snowpack to 20,000 Stars (Part 2)，而我们就是实际的业务，近 100 个大型项目，包含各类系统与 h5，几乎能踩完所有的坑。

To be honest，I’m not sure where Snowpack goes from here. I burnt out on it at the end of last year，and haven’t found the energy to return. Usage and downloads began to trend down and the community has gotten quieter.

At the same time，Vite (that Snowpack alternative that now powers SvelteKit) is taking off. To their credit，they do a lot of things really well. The good news is that two tools are very similar and easy to switch out. Even Astro is experimenting with moving from Snowpack to Vite in a future release.

虽如此 Snowpack 依然是个可敬的先行者 ❤️

所以综合体验下来还是 Vite 值得信赖，如果此时是新项目毫无疑问我推荐大家使用 Vite，但是我们这是老项目…

何为老项目? 就是前阵子升级了一个 ts-loader 的大版本，有俩项目测试环境白屏了 😨。在试图接入 Vite 时遇见了各种奇怪的编译错误 ❌ 以及未能正确找到目标 js 与 scss 文件路径 ❌ 等问题。

到这里我认为 Vite 是没有任何问题的，有些稀奇古怪，百花齐放的问题的代码就得你自己去改，当然实际继续挣扎下去可能会发现更多的奇葩问题，其解决沟通成本和时间成本是无法估计的。

3. nopack

最终我决定自己开发，并且业务项目可以随意切换新的 ES Module 开发模式与现有的 webpack 开发模式。

nopack 将以全局安装的形式存在，即对现有项目 **0 侵入**，对线上环境 **0 危险**， 0 修改 即可接入。

名称	nopack	Vite
定位	让存量 webpack 强绑定的项目开发体验由 🐢 变为 ⚡️	功能全面，下一代前端构建工具 ⚡️
开发环境	✅ ES Module + esbuild 编译	✅ ES Module + esbuild 编译
生产环境	❌ 不支持（⚠️ 生产环境无需变化）	✅ rollup 打包（💡 类似于 webpack 的生产打包）

3.1. 原理图

3.2. 时序图

3.3. Q: 如何做到项目 0 改动接入 ?

Vite 的大部分零件是偏向于 Rollup 体系。要想无缝兼容现在项目中配置的 _moduleAliases 与 sass 文件中各种 import 路径寻找，于是这部分我采用的 webpack 的零件，主要是 enhanced-resolve 与 sass-loader 的处理逻辑。
对于不规范的 npm 包, nopack 会对其进行硬编码矫正。主要考虑的问题是升级该包到最新版本可能会带来较多的 BREAK-CHANGE, 甚至最新版本可能都没修复, 业务回归测试任务较重可能就会放弃接入 nopack
通过 importmap 与 externals 等技术方案来兼容使用了内部微前端架构、qiankun 微前端架构、Module Federation 架构的项目
如果存在必需的 babel 插件, nopack 会简单的实现该插件同样的功能

3.4. Q: nopack 这个名字是啥意思 ?

只想做一个纯净的文件转译服务（理念类似于 esm.sh），竭尽全力的不打包 ❌📦 。想法还是天真了，因为有太多 CommonJs 的 npm 包, 而 CommonJs to ES Module 又是一个不成立的事情，require 是运行时的，import 是静态的，可能你想到了 import() 函数不也是运行时的吗 ? 不过 import() 返回的却是 Promise …
只想做转译的想法行不通 ❌

3.5. Q: 如何彻底消除 CommonJs 这些语法了 ?

那就只有预构建打包 📦 了，合成一个文件，require 的代码直接塞在对应的位置了，哪还会有 require 这些东西了

3.6. Q: nopack 不是坚决不打包吗 ?

为了这些不规范的 npm 包，只能忍气吞声了，起初 nopack 与 Vite 这里有些区别，nopack 会试图判断这个 npm 包是不是 ES Module 的包，比如 package.json 中有 module 或者 browser 字段，或者 import 的路径包含 es，esm 目录的文件如 packageA/es/a.js 这种或许也是 ES Module 就不进行预构建了。这样下来比如 a 项目 🔍 扫描到了 336 个 npm 包，最后只会对 199 个包进行预构建 📦 。

3.7. Q: 这样看来比 vite 更快 ?

快是快了，但是具有迷惑性行为的包也不少，比如某个包也声明了 module 字段，但我其实是 CommonJs 的代码。更有甚者一个包中大部分文件是 ES Module 的，有 1 - 2 文件个是 CommonJs 的 🤯! 没办法，你不是 nopack 吗，这些包我忍你了，我 hardcode 到一个数组中把你们加入黑名单。

3.8. Q: 最终接入的效果如何 ?

号称 3 分 45 秒的项目通过 esbuild 预构建大概只花 8s 左右，然后页面刷新时会对 src 下的 ts 与 jsx 通过 esbuid 进行转译，大概 4s 的时间，所以最终开始预构建到页面完全展示出来只花了 12s，esbuild 远比我想象中的更快 ⚡️。

3.9. Q: ES Module 开发的劣势?

刷新页面的等待时间会慢一点
- ES Module 模式强调即时转译，浏览器运行阶段代码从入口文件开始运行的时候，会不断有 import 语法发起新的文件请求，对于 jsx 与 ts 文件的请求还需要通过 esbuild 进行转译，对于 scss 请求需要 dart-sass 转译，直到所有的代码运行完成。
- webpack 模式强调打包，打包阶段会把入口文件开始依赖分析，最后打包出一个 main.js 交给浏览器运行，所以浏览器运行阶段就会快很多。
对性能有一定的要求
- 在其中一个项目接入时，使用 windows 开发的同学说快是快了，但是页面刷新的那一刻有点卡 🤔，排查时发现这个项目 network 中发了 3000 多个 js 的请求，Chrome 把 CPU 拉满了。所以 nopack 不得不又退步 😢，只能把 node_modules 的包进行全量的预构建来达到合并更多的文件，一下请求数降低到了 700，Chrome 即使拉满了 CPU 也是短暂就下来了。所以最终 nopack 又进行了妥协，采用了全量预构建的方式。事实证明文件请求减少页面刷新时白屏时间减少了，预构建也只增加了 2s 左右的时间，开发体验会更好一点。
esbuild 不会对 ts 类型进行检查
- 可以参考 fork-ts-checker-webpack-plugin 实现一个插件来配合 esbuild 检查