当前位置：首页 > news >正文

腾讯开源的 hel 提供了加载远程模块的能力，谈谈它的实现原理

news 2026/4/6 11:24:39

腾讯开源的 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);
}

1.引入 hel-micro 模块
2.通过 helMicro.preFetchLib 拉取远程模块
3.调用远程模块

整个使用过程非常的简单易懂，但这样无法使用 TS 类型检查。

于是又有了以下的写法：

需要先在项目入口调用：

await helMicro.preFetchLib('hel-tpl-remote-lib');

然后代码中就可以这样使用了：

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 运行流程

1.当调用 helMicro.preFetchLib 时，先拉取元数据，从元数据中获取到入口脚本的 url，然后拉取远程模块入口并执行，最后 helMicro.preFetchLib 将模块返回，代码中就可以直接使用了。
2.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('./你真正的模块代码');// 注意此处传递的是 defaultlibReady('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('./你真正的模块代码');// 注意此处传递的是 defaultlibReady('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 能越做越好吧~

最后

整理了一套《前端大厂面试宝典》，包含了HTML、CSS、JavaScript、HTTP、TCP协议、浏览器、VUE、React、数据结构和算法，一共201道面试题，并对每个问题作出了回答和解析。

有需要的小伙伴，可以点击文末卡片领取这份文档，无偿分享

部分文档展示：

文章篇幅有限，后面的内容就不一一展示了

有需要的小伙伴，可以点下方卡片免费领取