腾讯开源的 hel，提供了一种运行时引入远程模块的能力，模块部署在 CDN，远程模块发布后，不需要重新构建发布，就能生效。
个人觉得它的实现原理非常的不错，因此分享给大家。
远程模块可以作为微模块（模块级别的微前端），是页面级别的微前端的一种补充，因为页面级别的微前端，如 qiankun、无界等，它们的粒度太粗了，有时候需要更细粒度的微前端，例如：组件、函数级别的。这种场景，就可以使用远程模块，来实现微模块的效果。
远程模块使用示例
import helMicro from 'hel-micro'; export async function callRemoteMethod() { const lib = await helMicro.preFetchLib('hel-tpl-remote-lib'); return lib.num.random(22); }
- 引入
hel-micro模块 - 通过
helMicro.preFetchLib拉取远程模块 - 调用远程模块
整个使用过程非常的简单易懂，但这样无法使用 TS 类型检查。
于是又有了以下的写法：
需要先在项目入口调用：
await helMicro.preFetchLib('hel-tpl-remote-lib'); 然后代码中就可以这样使用了： ts 复制代码 import remoteLib from 'hel-tpl-remote-lib'; function callRemoteMethod() { return remoteLib.num.random(19); } TS 类型则是由 hel-tpl-remote-lib 这个 npm 仓库提供。
hel 核心原理
概念约定
- 远程模块
发布 CDN，在浏览器运行时，调用helMicro.preFetchLib真正拉取代码 - 代理模块
用于开发时的类型提示，上传到 npm。开发时安装并使用该 npm 包，可以获得 TS 类型提示 - 元数据
元数据是一份 json 配置清单，是在远程模块构建完成后，从构架产物中提取生成的。它记录了远程模块的名称、入口脚本路径等信息
hel 运行流程
- 当调用
helMicro.preFetchLib时，先拉取元数据，从元数据中获取到入口脚本的 url，然后拉取远程模块入口并执行，最后helMicro.preFetchLib将模块返回，代码中就可以直接使用了。 import代理模块，实际上是从远程模块的缓存中读取模块。因此，必须要等待helMicro.preFetchLib拉取完成后，import的代理模块才能够获取到远程模块
hel 的默认拉取元数据的方式，是根据远程模块名称，到 unpkg CDN 对应的 npm 包下，获取元数据 meta_data.json 文件。这个拉取元数据的过程也可以开发者自定义。
整个流程非常简单，但难度在于，如何构建打包出代理模块和远程模块
模块构建
代理模块
代理模块负责以下内容：
- 在运行时读取远程模块的缓存
- 用于提供 TS 类型支持
运行时读取远程模块的缓存
hel 提供了 exposeLib 函数，用于读取远程模块的缓存
打包代理模块时，参考以下代码作为构建入口：
import type { LibProperties } from './你真正的模块代码'; import { exposeLib } from 'hel-lib-proxy'; // 读取远程模块缓存，远程模块名为：hel-tpl-remote-lib export const lib = exposeLib<LibProperties>('hel-tpl-remote-lib'); // export 类型 export type Lib = LibProperties; // export 远程模块的缓存代码 export default lib;
该入口文件主要做了以下事情：
- export 导出 TS 类型
- 使用
exposeLib，将远程模块的缓存，暴露出来
以上述代码作为入口打包，实际上并没有将模块真实代码打包到产物中。因此代理模块，是一个非常小的模块，没有任何的模块逻辑。
在项目中使用远程模块 hel-tpl-remote-lib，最后打包只会打包代理模块这一小部分代码，不会将真正的代码打包到项目的产物中，因此还能提升项目的构建速度。
真正的代码，是运行时，在 preFetchLib 拉取远程模块时加载并运行的。
提供 TS 支持
只需要在 package.json 中声明 typing 字段：
{ "main": "hel_proxy/entry.js", "typings": "typings/index.d.ts", }
typing的值为构建时生成的 TS 类型声明文件的路径。main则用于声明代理模块的入口，指向的是打包后的产物。
发布
代理模块直接发布到 npm 即可，按 npm 包的用法正常引入和使用即可
远程模块
远程模块的职责如下：
- 提供远程模块的真实运行代码
- 通知 hel 的
preFetchLib函数，远程模块加载完成 - 提供
index.html，用于提取元数据，例如提取出远程模块的入口（加载时，需要首先拉取哪些代码）
要做到以上的内容，远程的模块，也需要用一个入口文件再包一层，伪代码如下：
import { libReady } from '@tencent/hel-lib-proxy'; async function main() { // 这里是 import 真正的模块代码了 const lib = await import('./你真正的模块代码'); // 注意此处传递的是 default libReady('hel-tpl-remote-lib', lib.default); } main().catch(console.error);
加载入口时立即调用 main 函数：
- import 真正的模块代码
- 调用
libReady并传入远程模块的值，该函数会通知preFetchLib，远程模块已经加载完成
如果一个远程模块，依赖另外一个远程模块，怎么办？
假如：hel-tpl-remote-lib 依赖 other-lib，other-lib 为另一个远程模块。即
// hel-tpl-remote-lib 的模块代码 import xxx from "other-lib"
那就 import other-lib 前，先执行 preFetchLib，拉取 other-lib。这样 other-lib 的代理模块，就能正确获取到内容。
import { LIB_NAME } from '../src/configs/subApp'; import { libReady } from '@tencent/hel-lib-proxy'; async function main() { // 如有其他远程包依赖并且需要在内部使用静态导入的语法，可使用 preFetchLib 来加载这些包体 const { preFetchLib } = await import('@tencent/hel-micro'); await preFetchLib('other-lib'); // 必须要用动态 import，因为如果当前包，还依赖其他的 hel 微前端依赖，需要 preFetchLib 之后，再进行引入。 const lib = await import('./你真正的模块代码'); // 注意此处传递的是 default libReady('hel-tpl-remote-lib', lib.default); }
如果存在嵌套的远程模块，就必须要用动态 import 引入真正的模块代码
await import('./你真正的模块代码')
元数据提取
hel 通过分析 index.html，来提取元数据，最重要的是要提取出模块的入口脚本，因为打包产物可能会有多个文件，要确定哪个才是入口。
假如有以下 HTML：
<!doctype html> <html lang="en"> <script> 这是一串内联 script </script> <script src="https://unpkg.com/hel-tpl-remote-lib@2.0.0/hel_dist/static/js/main.5ab2b93c.chunk.js" ></script> </html>
那么会提取到两个入口脚本：
- 内联脚本：内联脚本会被提取出来，存放到单独的文件，该文件的路径会被记录到元数据
main.5ab2b93c.chunk.js
上述 index.html 会得到以下元数据（节选）：
{ bodyAssetList: [ { "tag": "script", "attrs": { "src": "https://unpkg.com/hel-tpl-remote-lib@2.0.0/hel_dist/hel_userChunk_1.js" } }, { "tag": "script", "attrs": { "src": "https://unpkg.com/hel-tpl-remote-lib@2.0.0/hel_dist/static/js/main.5ab2b93c.chunk.js" } } ] }
注意这里的资源路径是完整的 url 了。
preFetchLib 函数会读取元数据，然后拉取这些入口脚本。
发布
开源版本的 hel，远程模块和元数据，同样会发布到 npm。这样就可以从 unpkg 这个 CDN，直接拉取到元数据和远程模块
从元数据的入口脚本可以看出，入口脚本的路径，已经是指向了 unpkg
小结
以上内容，就是一个完整的 hel 的原理：
- 在页面初始化前，先
preFetchLib拉取远程模块，然后直接可以拿到远程模块的对象 - 然后代理模块也能够从缓存中，获取到远程模块的内容
难点则在于如何打包远程模块和代理模块，需要遵守特定的规范：
- 远程模块，则需要处理嵌套的远程模块，然后通知
preFetchLib函数，加载完成 - 代理模块，需要导出 TS 类型，并读取远程模块的缓存并导出
- 元数据，需要根据
index.html提取出入口脚本
但你觉得这就完了吗？其实没有。
元数据的妙用
hel 提供了自定义拉取元数据的能力，这意味着，我们有了控制的返回元数据的能力，元数据中有远程模块的入口，因此能控制拉取的远程模块。
下面是一个例子：
元数据通过版本管理平台的接口拉取。
通过在版本管理平台上配置，可以返回的元数据的对应的远程模块版本，从而做到控制远程模块的版本号，能做到回滚，灰度等能力。
上述版本管理平台，其实在腾讯内部已经实现，但目前仍未开源，但从 github 上已经看到是计划中了
有了自定义拉取元数据的能力，这个过程就会有非常大的自由度，由此可以衍生出一个非常大的微模块生态。理论上可以做到但不限于以下的效果：
- 控制全局的远程模块的版本
- 快速回滚能力
- 灰度能力、AB test 能力，根据地域分布、用户等条件分发不同的元数据
- 按项目维度，进行版本控制，不同的项目，返回不同的元数据，从而使用不同的远程模块版本
- ……
总结
不过截止目前（2022.12.13），开源 hel 目前提供的部署方式，只是部署到 unpkg CDN 上，对于公司项目来说，不太适合，需要提供更多的最佳实践；它的开源生态，也有待完善。
但不得不承认的是，hel 的整个思路，的确是较为优秀，值得学习和研究， 能够作为一种优秀的远程模块/微模块方案。
最后也希望 hel 能越做越好吧~
如果这篇文章对您有所帮助，可以点赞加收藏👍，您的鼓励是我创作路上的最大的动力。也可以关注我的公众号订阅后续的文章：Candy 的修仙秘籍（点击可跳转）
