Module Federation 是 webpack5 中振奋人心的新特性，也是号称能改变 JavaScript 架构游戏规则的功能。接下来让我们慢慢揭开 Module Federation 的神秘面纱
模块共享的方案对比
场景：目前拥有项目 A 和项目 B，我们发现它们存在一定的共性，比如公共 UI 组件、utils 等。那我们如何同享这些公共信息呢？
简单粗暴-CV大法
直接将项目 A 的组件，copy 到项目 B 中，这样的方式有时候是比较快的，但也存在维护性极低的问题，后续两个项目都各自维护一套
抽象成 npm
我们可以将一些公共的模块抽象成 npm，每个项目都去安装该 npm 包，从而达到共享的目的
但是 npm 包的方式存在以下问题：
- 编译与构建：一些公共的工具库，框架以及 UI 库存在重复构建，造成性能低下
- 版本更新：需要各个项目都去升级。“发布 -> 通知 -> 更新” 的方式是比较低效率的
CDN + webpack externals
跟 npm 类似，只不过将其上传到 CDN，通过结合 webpack externals 进行加载，除了上面提到的问题，还有 externals 没有按需加载
git submodule
子模块允许你将一个 Git 仓库作为另一个 Git 仓库的子目录。 它能让你将另一个仓库克隆到自己的项目中，同时还保持提交的独立
其还是会存在重复构建的问题，而且还会一定的上手成本
相关的命令：
- git submodule add <子模块repository> : 添加子模块
- git submodule update --recursive --remote ：拉取所有子模块的更新
Module Federation 是什么？
官方文档解释其动机如下：
多个独立的构建可以组成一个应用程序，这些独立的构建之间不应该存在依赖关系，因此可以单独开发和部署它们。这通常被称作微前端，但不仅仅限于此
Module federation 使 JavaScript 应用得以从另一个 JavaScript 应用中动态地加载代码，这就解决了我们上面提到的模块共享的问题
它不仅仅是微前端，而且场景粒度可以更加细，一般微前端更多的是应用级别，但它更偏向模块级别的共享
Module Federation 配置
在实战之前，我们了解一下 Module Federation 的配置项
首先是两个基础角色的约定：
- Host。消费模块的一方
- Remote。提供模块的一方
每个应用都既可以作为 host，也可以作为 remote
Module Federation 配置项如下：
- name: 必须且唯一
- filename: 若没有提供 filename，那么构建生成的文件名与容器名称同名
- remotes: 可选，作为引用方最关键的配置项，用于声明需要引用的远程资源包的名称与模块名称，作为 Host 时，去消费哪些 Remote
- exposes: 可选，表示作为 Remote 时，export 哪些属性被消费
- library: 可选,定义了 remote 应用如何将输出内容暴露给 host 应用。配置项的值是一个对象，如 { type: 'xxx', name: 'xxx'}
- shared，可选,指示 remote 应用的输出内容和 host 应用可以共用哪些依赖。 shared 要想生效，则 host 应用和 remote 应用的 shared 配置的依赖要一致
- Singleton: 是否开启单例模式。默认值为 false，开启后remote 应用组件和 host 应用共享的依赖只加载一次，而且是两者中版本比较高的
- requiredVersion：指定共享依赖的版本，默认值为当前应用的依赖版本
- eager：共享依赖在打包过程中是否被分离为 async chunk。设置为 true， 共享依赖会打包到 main、remoteEntry，不会被分离，因此当设置为true时共享依赖是没有意义的
实战演示
这里我们用 Github 中 Module Federation Examples进行演示。这里包含了基础的用法、高级用法以及和一些框架的结合实践
注：该仓库使用 lerna 维护。所以你需要安装 lerna
npm install lerna -g
通过 lerna bootstrap 安装依赖
简单示例
来看 basic-host-remote 目录下有两个独立的 project，分别为 app1 和 app2。其中 app2 中实现了一个 Button 组件，现在 app1 要用这个 Button 组件
import React from 'react';
const Button = () => <button>App 2 Button</button>;
export default Button;
app2 暴露组件
此时，app2 的角色就是 Remote，核心 webpack 配置：
const { ModuleFederationPlugin } = require('webpack').container;
// ...
plugins: [
new ModuleFederationPlugin({
name: 'app2',
library: { type: 'var', name: 'app2' },
filename: 'remoteEntry.js', // 生成的文件名
exposes: {
'./Button': './src/Button', // Export Button 组件
},
// 共享 react 和 react-dom
shared: { react: { singleton: true }, 'react-dom': { singleton: true } },
}),
],
// ...
app1 消费组件
此时，app1 的角色是 Host，webpack 核心配置：
const { ModuleFederationPlugin } = require('webpack').container;
// ...
//http://localhost:3002/remoteEntry.js
plugins: [
new ModuleFederationPlugin({
name: 'app1',
remotes: {
// http://localhost:3002/remoteEntry.js
// 上面配置生成的模块文件
app2: `app2@${getRemoteEntryUrl(3002)}`,
},
// 共享模块
shared: { react: { singleton: true }, 'react-dom': { singleton: true } },
}),
],
// ...
模块使用：
const RemoteButton = React.lazy(() => import('app2/Button'));
const App = () => (
<div>
<h1>Basic Host-Remote</h1>
<h2>App 1</h2>
<React.Suspense fallback="Loading Button">
<RemoteButton />
</React.Suspense>
</div>
);
export default App;
效果
而且可以看到 react 和 react-dom 也是加载了一次：
高级示例-动态加载远程模块
假如初始化的时候，不加载远程的模块，在一定的交互之后再去加载远程模块，该怎么实现呢？
本示例在 advanced-api/dynamic-remotes 中可以找到
示例中有三个 project，app1/app2/app3。app1 是 Host，消费 app2 和 app3 提供的组件，而且点击相应按钮的时候才去加载对应的远程模块。另外 app2 和 app3 都用到了 moment.js
app2 和 app3 暴露模块
两个 project 的配置是相似的，都是暴露了 Widget 组件，而且都同享了 react 和 react-dom，以及 moment.js。这里可以留意的是，假如不声明 requiredVersion，就会使用它能找到的当前大版本中最高的 version
const deps = require('./package.json').dependencies;
// ...
new ModuleFederationPlugin({
name: 'app3',
library: { type: 'var', name: 'app3' },
filename: 'remoteEntry.js',
exposes: {
'./Widget': './src/Widget',
},
// adds react as shared module
// version is inferred from package.json
// there is no version check for the required version
// so it will always use the higher version found
shared: {
react: {
requiredVersion: deps.react,
import: 'react', // the "react" package will be used a provided and fallback module
shareKey: 'react', // under this name the shared module will be placed in the share scope
shareScope: 'default', // share scope with this name will be used
singleton: true, // only a single version of the shared module is allowed
},
'react-dom': {
requiredVersion: deps['react-dom'],
singleton: true, // only a single version of the shared module is allowed
},
// adds moment as shared module
// version is inferred from package.json
// it will use the highest moment version that is>=2.24and 小于 3
moment: deps.moment,
},
})
app1 消费模块
app1 作为 Host，这里都是常规配置，不再赘述
主要来看它负责动态加载的代码，在点击相应的按钮的时候，会触发 useFederatedComponent 方法，入参中 remoteUrl 为远程地址，scope 为对应应用名称，module 为指定的模块。其中 useDynamicScript 负责加载的远程 JavaScript 脚本，加载完成之后，通过 loadComponent 方法动态加载组件
export const useFederatedComponent = (remoteUrl, scope, module) => {
const key = `${remoteUrl}-${scope}-${module}`;
const [Component, setComponent] = React.useState(null);
const { ready, errorLoading } = useDynamicScript(remoteUrl);
React.useEffect(() => {
if (Component) setComponent(null);
// Only recalculate when key changes
}, [key]);
React.useEffect(() => {
if (ready && !Component) {
const Comp = React.lazy(loadComponent(scope, module));
componentCache.set(key, Comp);
setComponent(Comp);
}
// key includes all dependencies (scope/module)
}, [Component, ready, key]);
return { errorLoading, Component };
};
再来重点看下 loadComponent，其中 __webpack_init_sharing__ ，进行了初始化共享作用域，用提供的已知此构建和所有远程的模块填充它。然后获得远程容器 container，支持 get 和 init 方法。 init 是一个兼容 async 的方法，调用时，只含有一个参数：共享作用域对象(shared scope object)——__webpack_share_scopes__.default。最后调用容器的 get 方法，获取到对应的模块
function loadComponent(scope, module) {
return async () => {
// Initializes the share scope. This fills it with known provided modules from this build and all remotes
// 初始化共享作用域（shared scope）用提供的已知此构建和所有远程的模块填充它
await __webpack_init_sharing__('default');
const container = window[scope]; // or get the container somewhere else
// 初始化容器 它可能提供共享模块
await container.init(__webpack_share_scopes__.default);
const factory = await window[scope].get(module);
const Module = factory();
return Module;
};
}
效果演示
- 点击不同的按钮，加载不同的组件
- moment.js 在首次加载后不用再重新加载
你可以通过动态加载的方式，提供一个共享模块的不同版本，从而实现 A/B 测试
Module Federation 的问题
谈了这么多 Module Federation 的优点，我们来看看它有哪些缺点
1、 对环境要求略高，需要使用 webpack5，旧项目改造成本大
2、 拆分粒度需要权衡,虽然能做到依赖共享，但是被共享的 lib 不能做 tree-shaking，也就是说如果共享了一个 lodash，那么整个 lodash 库都会被打包到 shared-chunk 中
3、 Webpack 为了支持加载 remote 模块对 runtime 做了大量改造，在运行时要做的事情也因此陡然增加，可能会对我们页面的运行时性能造成负面影响
4、 运行时共享也是一把双刃剑，如何去做版本控制以及控制共享模块的影响是需要去考虑的问题
对于问题1，未来应该会慢慢变好。问题2 感觉还好，场景应该不会特别多，而且相比于共享模块，不重复编译的优点来讲，相对可以接受。问题3，感受不大。
问题4，算是比较头疼的一件事，比如几个项目，都需要版本 react/react-dom/antd 的版本一致，假如版本更新的话，怎么办？
我们可以使用 Module Federation 的能力，将一些核心的依赖例如 react、react-dom、antd，使用一个 remote 服务维护，然后每个项目分别引用这个服务导出的 library。我们只需要维护这个 remote 服务上依赖的版本，就能保证每个项目核心依赖的版本是一致的，而且升级的时候，也不用每个项目自己升级，大大提升了效率
总结
使用 Module Federation，我们可以在一个应用中动态加载并执行另一个应用的代码，且与技术栈无关，并且能够共享模块，从而减小编译时间以及降低包体积
但在使用 Module Federation 的时候也需要权衡模块拆分的粒度以及做好版本的控制
