无需登录 数据私有 本地保存

模块联邦在线演示 - 微前端共享模块

8
0
0
0

模块联邦在线演示

Webpack 5 Module Federation — 微前端共享模块可视化演示

微前端架构可视化
Header Team Remote :3001

暴露 Header 组件

Header Logo react
Footer Team Remote :3002

暴露 Footer 组件

Footer Copyright react
Main Host App Host :3000

消费所有远程模块,提供布局

Header↗ Footer↗ react react-dom lodash
Shared Scope(共享作用域) 单例模式
react@18.2.0 react-dom@18.2.0 lodash@4.17.21
应用配置
Webpack 配置
const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin');

module.exports = {
  // ... 其他webpack配置
  plugins: [
    new ModuleFederationPlugin({
      name: 'headerTeam',
      filename: 'remoteEntry.js',
      exposes: {
        './Header': './src/components/Header',
        './Logo': './src/components/Logo',
      },
      shared: {
        react: { singleton: true, requiredVersion: '^18.2.0' },
        react-dom: { singleton: true },
      },
    }),
  ],
};
运行日志
[00:00] 🔧 模块联邦运行时已就绪
[00:00] ✓ Shared Scope 初始化完成
[00:00] 📦 等待模块加载...
模块加载流程演示
步骤 1:Host 发起请求

Host应用通过动态import加载远程模块入口文件 remoteEntry.js

步骤 2:下载远程 Chunk

Remote应用返回包含模块代码的JS chunk,注册到全局共享作用域

步骤 3:解析 & 渲染

检查shared依赖版本,单例模式下复用已有实例,渲染组件到页面

准备就绪
常见问题 & 知识点

模块联邦是 Webpack 5 引入的一项革命性特性,允许多个独立构建的应用在运行时共享模块。它是微前端架构的核心实现方案之一。与传统的npm包共享不同,模块联邦实现了运行时动态加载,一个应用(Remote)可以暴露特定模块,另一个应用(Host)可以在运行时消费这些模块,无需重新构建。这大大提升了大型项目的开发效率和部署灵活性。

Remote(远程应用):提供模块的应用,通过 exposes 配置项暴露组件或模块给其他应用使用。Remote应用可以独立开发、构建和部署。

Host(宿主应用):消费远程模块的应用,通过 remotes 配置项声明需要加载的远程应用及其模块。Host应用在运行时动态加载Remote暴露的模块。一个应用可以同时是Host和Remote。

Shared Scope 是模块联邦中用于协调共享依赖的运行时机制。当多个应用使用同一个依赖(如react)时,shared配置确保它们使用同一个实例。

Singleton模式:当设置 singleton: true 时,共享作用域中只允许存在一个该依赖的实例。如果多个应用提供了不同版本,运行时会发出警告并使用最高兼容版本。这对react这类要求单例的库至关重要,可以避免"多个React实例"导致的错误。

模块联邦是实现微前端架构的关键技术之一。微前端是一种架构模式,将前端应用拆分为多个独立的小型应用,每个应用可以独立开发、测试和部署。模块联邦提供了微前端所需的核心能力:
✅ 运行时模块共享
✅ 独立构建和部署
✅ 依赖共享避免重复加载
✅ 团队自治
与iframe、Web Components等方案相比,模块联邦提供了更好的性能和开发体验。

remoteEntry.js 是模块联邦中Remote应用的入口清单文件。它包含了:
📋 该Remote应用暴露的所有模块列表
🗺️ 模块到chunk的映射关系
🔗 共享依赖的版本信息
当Host应用加载Remote模块时,首先加载这个文件来了解Remote应用的结构,然后按需加载具体的模块chunk。

模块联邦通过 shared 配置提供了多种策略:
🔹 requiredVersion:指定需要的版本范围(如^18.2.0)
🔹 singleton:强制单例,避免多实例
🔹 strictVersion:严格版本匹配
🔹 eager:是否立即加载共享依赖
当版本不匹配时,运行时会在控制台发出警告,开发者可以根据实际情况调整版本策略。最佳实践是团队间协调使用相同的主版本号。