|
导读：Federated Modules 是一个令人激动的功能，它可能会改变未来几年的前端打包方式，作者深入分析了 Module Federation 的原理及其应用场景，希望能对大家有所启发。
WHAT（Module Federation 是什么？）Module Federation [ˌfedəˈreɪʃn] 使 JavaScript 应用得以在客户端或服务器上动态运行另一个 bundle 的代码。
这其中的关键点是：
一些相关的概念：
一个应用可以是 Host，也可以是 Remote，也可以同时是 Host 和 Remote。
通过回答 Module Federation 如何运转？Host 如何消费 Remote？以及 Remote 如何优先使用 Host shared 的依赖？这三个问题，我们分析一下 Module Federation 的原理。 整体是通过 ModuleFederationPlugin（https://github.com/webpack/webpack/blob/dev-1/lib/container/ModuleFederationPlugin.js）这个插件串联起来的。
配置示例： new ModuleFederationPlugin({
name: 'app-1',
library: { type: 'var', name: 'app_1' },
filename: 'remoteEntry.js',
remotes: {
app_02: 'app_02',
app_03: 'app_03',
},
exposes: {
antd: './src/antd',
button: './src/button',
},
shared: ['react', 'react-dom'],
}),
配置属性：
name，必须，唯一 ID，作为输出的模块名，使用的时通过 ${name}/${expose} 的方式使用；
library，必须，其中这里的 name 为作为 umd 的 name； remotes，可选，表示作为 Host 时，去消费哪些 Remote； exposes，可选，表示作为 Remote 时，export 哪些属性被消费； shared，可选，优先用 Host 的依赖，如果 Host 没有，再用自己的；
产物：
所以比如下面如图示例的应用集群：
加载方式应该这样： <script src='C/remoteEntry.js'></script>
<script src='B/remoteEntry.js'></script>
<script src='A/main.js'></script
C/remoteEntry.js 和 B/remoteEntry 的顺序没有要求，只要在 A/main.js 之前就好了。
可以通过代码示例来进行理解。
B 源码： // src/react.js
export * from 'react';
// webpack.config.js
...
exposes: {
react: './src/react',
},
A 源码：
// 异步加载 B 的 react 模块
const React = await import('B/react');
B 构建产物：
// windows 变量
let B;
const moduleMap = {
'react': () => {
return Promise.all([e('a'), e('b'), e('c')]),
},
};
B = {
get(moduleId) {
return moduleMap(moduleId);
}
}
A 构建产物：
const modules = {
'B': () => {
return B;
}
};
// 异步获取模块 export 内容
function e(moduleId) {
// 1. 取 shared 的模块
// 2. 取 remote 的模块
const idToExternalAndNameMapping = {
'B/react': ['B', 'react'],
};
// 从 module B 里取 react
const data = idToExternalAndNameMapping[moduleId];
__webpack_require__(data[0]).get(data[1]);
// 3. 取当前项目的异步模块
}
// 初始化
e('B/react');
这其中的原理：
再看如下两个代码示例。
B 构建产物：
let B;
__webpack_require__.Overrides = {};
function e(moduleId) {
// 1. 取 shared 的模块
// 当前项目的 shared 模块列表
const fallbackMapping = {};
// 先从 Overrides 里取，再从当前项目里取
push_require_try(__webpack_require__.Overrides[moduleId] || fallbackMapping[moduleId]);
// 2. 取 remote 的模块
// 3. 取当前项目的异步模块
}
B = {
override(override) {
Object.assign(__webpack_require__.Overrides, override);
}
}
A 构建产物：
B.override(Object.assign({
'react': () => {
// A 的 react 内容
},
}, __webpack_require__.Overrides));
原理分析：
这样，B 里面在 require react 时，就会用 A 的 react 模块。
Module Federation 可以用在哪里？
如上图，这是去年画的一张微前端的图，其中最下面的 “公共依赖加载” 一直是没有非常优雅的方案。
方法一：让每个子应用都分开打包，主应用不管，这样不会有问题，但问题就是尺寸大，而且大了不是一点点。
方法二：主应用包含 antd 和 react，子应用如果版本一致不打包 react 和 antd，版本不一致就自己打一份，但有几个问题：
antd 和 react 是通过 umd 的方式同步载入的，主应用初始化会比较慢； 主应用升级了 antd 的时候，所有子应用可能需要一起升级，这个成本就很大了。
方法三：利用 Module Federation 的 shared 能力，子应用的依赖如果和主应用匹配，那么，能解决方法二里的第一个问题，但第二个问题依旧解不了。
方法四：利用 Module Federation 的 remotes 能力，再提一个应用专门提供库被消费，看起来前面的问题都能解。
有没有感觉技术又轮回到了 seajs + spmjs 的时代。
现状是，通过 npm 共享组件。
基于 Module Federation，除通过 npm 共享依赖，还可以有运行时的依赖、组件、页面甚至应用的直接共享。
这样一来，灵活性就非常大了，可以在应用的各个层面做共享。A 应用引用 B 整个应用，也可以应用 B 的的页面和组件，还可以提一个库应用，做 npm 依赖的运行时共享。
我们大部分场景不是微前端或应用集群，Module Federation 还可以帮助我们干什么？
现在项目组织和文件依赖通常是这样：
现状是：
期望的是：
为什么不是其他的编译速度优化方案？
举一个对比的例子，比如 external，我们之前还有做过自动的 external 方案，虽然他也可能显著提速，但有以下问题：
以空间换时间，依赖包全量引用导致 npm，用在生产上会牺牲部分产品体验，需权衡； 不是所有的依赖都有 umd 包，覆盖率不够； npm 可能有依赖，比如 antd 依赖 react 和 moment，那么 react 和 moment 也得 external 并且在html 里引用他们； 需要手动修改 html 里的引用，维护上有成本提升。
更多参考：
关注「Alibaba F2E」 把握阿里巴巴前端新动向
|
