坏蛋Dan
知乎@坏蛋Dan
发布时间：2024.1.3

前言

这里排除独立包异步化等场景，如果可以，优先选择文件独立分包异步化。

另外这里的背景是基于uniapp编译成微信小程序。

vue是2.x版本，脚手架是vue-cli。

最近发现部门负责的小程序中存在一些全局文件只有在分包中有依赖，想去优化这块，于是衍生出两种开发场景。

  1. 依旧放到全局也就是主包中，这样只用维护一块，但是侵占主包空间。
  2. 放到各个分包中，但是需要维护多份。

方案

那么有没有办法可以将两个优点结合呢？

也就是文件依旧放到主包，但是打包后各分包依赖的文件不是主包的。

有的，并且方案不少。

  1. 基于配置文件，自定义一个配置文件，这个文件存放需要派发到分包中文件资源路径。
  • 优点：快速定位，不需要做过滤处理。
  • 缺点：开发体验差，需要开发者自行去添加/移除。
  1. 基于文件源码搜索，通过自定义loader对开发源码匹配处理（或者自己写一套预编译处理）。
  • 优点：开发体验较好，基本可以无感。
  • 缺点：需要对每个请求的文件进行源码匹配，性能较低耗时较高。

这里我个人经过考虑后选择方案2，因为这个是打包准备部署的阶段而并非开发阶段，所以这点耗时影响可以接受。

实现

既然选定了方案，接下来就是实现。

那么该从哪个点切入呢？

这里选择对请求的路径进行改动，将主包请求路径改动到分包自己种，比如@/components/xxx/xx.vue改动为@/subpkg/xxx/xx.vue，这样后续打包就不会去请求主包里的xx.vue文件，自然就不会参与打包也就不侵占主包空间。

不过这里还有另一个问题，那就是分包中的xxx/xx.vue是不存在的，如果直接改请求路径那么是找不到的，会导致报错。

我这里就直接用暴力的方案，在请求之前做copyDir处理，这里面有挺多可以优化的点。

那么这俩问题的解决理论有了，可以动手实现了。

先来处理第一个问题，文件请求路径改写。

尝试1：通过babel自定义plugin

我这里最先是考虑通过babel自定义plugin的方式来改写路径。

但是这里有两个问题：

  1. 开发者源码被改动
  2. 打包之后主包虽然没有对应文件了，但是分包中主包文件副本内容丢失

于是放弃。

尝试2：通过webpack自定义插件注册hooks监听生命周期

针对于尝试1中的第一个问题，我这里想着如果要不改动源码并且改动请求路径，那么就得在module生成之前改动, 我选择监听的生命周期是normalModuleFactory[1] 拿到normalModuleFactory实例之后再监听它的生命周期beforeResolve[2] ,这个时候是还没有处理request的，所以在这里改动最好。

那么结果呢？

打包结果：

  1. 主包不包含对应文件，符合预期。
  2. 分包中的副本内容丢失，不符合预期。
  3. 开发者源码没有被改动，符合预期。

由于第二个问题过于奇怪，在挣扎了一段时间后选择放弃。

尝试3：通过自定义loader实现，规则/.js$/

经过尝试2，我发现应该是选择的生命周期位置不够接近，所以干脆选择含有请求路径的文件被处理的时候来改写，这样应该就是最接近的时刻了。

那么自然是选择loader来处理。

并且得在babel-loader之前，因为得赶在源码被篡改之前动手改动。

代码就不放了，最终方案的代码差不多，到时直接看最终方案即可。

尝试之后依旧是失败了：

  1. 主包中有对应文件，不符合预期。
  2. 分包文件副本内容丢失，不符合预期。
  3. 开发者源码没有被改动，符合预期。

反思了下，想法是可以的，但是还是不够靠前，因为vue-loader会调用@vue/compiler-sfc将代码进行切割分别处理，babel拿到的已经不是第一手代码了。

那么自然就得在vue-loader之前。

尝试4：通过自定义loader实现，规则/.vue$/

这回咱们赶在vue-loader处理前改动源码。

先在vue.config.js中写规则

然后我们来实现这个loader

这里采用的是loader异步环境[3] ,这么做是为了确保copy文件/文件夹完成再改动请求路径。

这个方案最终的结果是：

  1. 主包中不再含有对应文件，符合预期
  2. 分包中文件副本内容没有丢失，符合预期
  3. 开发者源码没有被改动，符合预期

效果

那么这里就基本符合我个人预期了，放一下效果图：

这里基于主包30多个组件以及6个分包依赖

优化前：

可以看到这里主包已经爆掉了

编译时间

优化后：

可以看到主包降回2M以内。

编译时间：

缺点

经过上面的效果图对比，你应该发现了几处问题：

  1. 编译时间，这个主要是消耗在匹配逻辑和copy文件。
  2. 分包变大，可能会超出2M
  3. 总包体积变大，变大的极端为：(分包个数 - 1) * 文件大小。
  4. 如果主包也有依赖，那么就无效（分包不会有副本，分包请求路径不改动保持为主包文件路径）。

优点

虽然问题较多，但是实际上还是有价值使用的，比如：

  1. 临时主包爆了，找不到优化方案，可以尝试这个方案，之后再找替代方案。
  2. 非极端情况，大部分主包组件都不会被所有分包依赖，所以量不是很大的情况下这种方案的性价比是比较高的。

善后

这个方案其实还有一个问题，那就是copy的副本会一直保留在分包中，这样就很恶心了，达不到我们“开发者无感知”的要求。

不过这个也好解决，我们可以暴力点，收集copy to的路径，然后监听webpack的生命周期，在done的阶段将文件移除即可。

基于global这个全局变量来缓存copy to的路径

然后自定义webpack插件

这回就是“无感知”啦~

总结

这个方案被驳回了。。。。但确实有一定的可行性。

如果觉得有帮助请务必点个赞，这是对我这个方案的肯定。。。

参考

  1. ^normalModuleFactory https://webpack.js.org/api/compiler-hooks/#normalmodulefactory
  2. ^normalFactory-beforeResolve https://webpack.js.org/api/normalmodulefactory-hooks#beforeresolve
  3. ^async-loader https://webpack.js.org/api/loaders/#asynchronous-loaders

编辑于 2023-02-18 17:57・IP 属地广东