JS `Module Federation` (Webpack) 深度：运行时共享模块 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

各位技术同仁，晚上好！

我是今天的主讲人，很高兴和大家一起探索 Webpack Module Federation 的深水区，特别是运行时共享模块这个话题。别担心，我会尽量用大白话，加上一些有趣的例子，让大家不仅能听懂，还能上手玩起来。

Module Federation：打破应用的藩篱

首先，咱们简单回顾一下 Module Federation。想象一下，以前咱们开发应用，各个团队就像住在不同的城堡里，代码重复利用率低，维护成本高。Module Federation 就像一座座桥梁，让这些城堡里的资源可以互相调用，实现代码共享和应用集成。

简单来说，Module Federation 允许一个 Webpack 构建的应用（Host）动态地使用另一个 Webpack 构建的应用（Remote）暴露出来的模块。这是一种运行时级别的代码共享机制。

运行时共享模块：动态的魔法

那什么是运行时共享模块呢？这才是今天的主角。

传统的静态依赖，在构建时就把所有依赖都打包进去了。Module Federation 的共享模块，则是在运行时决定使用哪个版本的依赖。这就厉害了，就像一个变形金刚，可以根据不同的场景和需求，动态地调整自己的形态。

共享模块的核心概念

在深入代码之前，我们需要理解几个关键概念：

shared 选项: 这是配置共享模块的灵魂所在。它告诉 Webpack，哪些模块可以被共享，以及如何处理版本冲突。
singleton: 这个选项表示，整个应用只需要一个版本的共享模块。如果多个 Remote 暴露了同一个 singleton 模块，Webpack 会选择一个版本，并确保所有地方都使用这个版本。这对于像 React、Vue 这样的框架非常重要，因为多个版本可能会导致各种奇怪的问题。
requiredVersion: 指定 Host 或者 Remote 需要的共享模块的版本范围。如果版本不满足要求，Webpack 会报错或者尝试寻找兼容的版本。
strictVersion: 强制使用 requiredVersion 指定的版本。如果找不到完全匹配的版本，Webpack 会报错。
eager: 立即加载共享模块。默认情况下，共享模块是按需加载的。eager: true 可以避免一些潜在的加载顺序问题，但可能会增加初始加载时间。

代码示例：一个简单的 React 共享场景

为了更好地理解，我们来构建一个简单的示例。假设我们有两个应用：Host App 和 Remote App。它们都使用 React。我们希望 Host App 可以使用 Remote App 暴露的 React，避免重复打包。

1. Remote App (Remote)

// webpack.config.js (Remote App)
const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin');

module.exports = {
  // ... 其他配置
  plugins: [
    new ModuleFederationPlugin({
      name: 'remoteApp',
      filename: 'remoteEntry.js',
      exposes: {
        './Button': './src/Button', // 暴露 Button 组件
      },
      shared: {
        react: {
          singleton: true,
          requiredVersion: '^17.0.0', //声明remoteApp需要React的版本
        },
        'react-dom': {
          singleton: true,
          requiredVersion: '^17.0.0',//声明remoteApp需要ReactDOM的版本
        },
      },
    }),
  ],
};

// src/Button.js
import React from 'react';

const Button = ({ text }) => {
  return <button>{text}</button>;
};

export default Button;

2. Host App (Host)

// webpack.config.js (Host App)
const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin');

module.exports = {
  // ... 其他配置
  plugins: [
    new ModuleFederationPlugin({
      name: 'hostApp',
      remotes: {
        remoteApp: 'remoteApp@http://localhost:3001/remoteEntry.js', // 声明Remote App的地址
      },
      shared: {
        react: {
          singleton: true,
          requiredVersion: '^17.0.0',//声明hostApp需要React的版本
        },
        'react-dom': {
          singleton: true,
          requiredVersion: '^17.0.0',//声明hostApp需要ReactDOM的版本
        },
      },
    }),
  ],
};

// src/App.js
import React, { Suspense } from 'react';
const RemoteButton = React.lazy(() => import('remoteApp/Button')); // 动态引入 Remote App 的 Button 组件

const App = () => {
  return (
    <div>
      <h1>Host App</h1>
      <Suspense fallback={<div>Loading...</div>}>
        <RemoteButton text="Click me from Remote!" />
      </Suspense>
    </div>
  );
};

export default App;

在这个例子中，Remote App 通过 exposes 选项暴露了 Button 组件。Host App 通过 remotes 选项声明了 Remote App 的地址，并通过 React.lazy 动态引入了 Button 组件。

关键在于 shared 选项。两个应用都声明了 react 和 react-dom 为共享模块，并且都设置了 singleton: true。这意味着，如果 Host App 和 Remote App 使用的 React 版本兼容，Webpack 会选择一个版本，并确保两个应用都使用这个版本。

运行时版本选择：Webpack 的幕后操作

那么，Webpack 是如何进行运行时版本选择的呢？

构建时分析: Webpack 在构建时会分析 shared 选项，并生成一些额外的代码，用于在运行时处理共享模块。
模块请求拦截: 当 Host App 尝试加载 react 时，Webpack 会拦截这个请求。
版本匹配: Webpack 会检查 Host App 和 Remote App 声明的 react 版本范围，并尝试找到一个兼容的版本。
模块提供: 如果找到兼容的版本，Webpack 会从已经加载的模块中提供 react。如果没有找到，Webpack 可能会从 Remote App 加载 react。
模块共享: 一旦 react 被加载，Webpack 会将其存储在一个全局的共享模块仓库中，供所有需要 react 的模块使用。

版本冲突：当幸福的家庭出现裂痕

如果 Host App 和 Remote App 声明的共享模块版本不兼容，会发生什么呢？

例如，Host App 需要 react@^16.0.0，而 Remote App 需要 react@^17.0.0。在这种情况下，Webpack 会发出警告，并尝试寻找一个共同的版本。如果没有找到，可能会导致运行时错误。

为了解决版本冲突，我们可以尝试以下方法：

升级或降级依赖: 尽量让 Host App 和 Remote App 使用相同的依赖版本。
使用版本范围: 使用更宽松的版本范围，例如 react: { requiredVersion: '*' }。但这可能会导致一些兼容性问题，需要谨慎使用。
排除共享模块: 如果实在无法解决版本冲突，可以考虑将共享模块从 shared 选项中移除，让 Host App 和 Remote App 各自打包自己的依赖。

高级用法：更灵活的共享策略

除了基本的共享配置，Module Federation 还提供了一些高级用法，可以实现更灵活的共享策略。

自定义共享逻辑: 我们可以通过 shareKey 选项来指定共享模块的 Key。这在某些特殊情况下非常有用，例如，当我们需要共享一个模块的多个实例时。
提供模块别名: 我们可以通过 alias 选项来为共享模块指定别名。这可以方便地在代码中使用共享模块。
使用 Promise 加载共享模块: 我们可以使用 import() 动态加载共享模块。这可以实现更细粒度的代码拆分和按需加载。

实际案例：微前端架构中的应用

Module Federation 在微前端架构中有着广泛的应用。它可以帮助我们将一个大型应用拆分成多个独立的微应用，每个微应用都可以独立开发、构建和部署。

例如，我们可以将一个电商网站拆分成以下几个微应用：

商品列表微应用: 负责展示商品列表。
购物车微应用: 负责管理购物车。
用户中心微应用: 负责管理用户账户信息。

每个微应用都可以独立开发和部署，并通过 Module Federation 共享公共组件和依赖。这样可以提高开发效率，降低维护成本，并实现更灵活的应用架构。

表格总结：共享模块配置选项

选项	类型	描述
`singleton`	`boolean`	是否只允许一个版本的共享模块。
`requiredVersion`	`string`	声明需要的共享模块的版本范围。
`strictVersion`	`boolean`	是否强制使用 `requiredVersion` 指定的版本。
`eager`	`boolean`	是否立即加载共享模块。
`shareKey`	`string`	指定共享模块的 Key。
`alias`	`string`	为共享模块指定别名。
`import`	`string`	指定共享模块的导入路径。
`packageName`	`string`	指定共享模块的包名。
`version`	`string`	指定共享模块的版本。

踩坑经验：Module Federation 的注意事项

版本管理: 务必重视共享模块的版本管理，避免版本冲突导致运行时错误。
加载顺序: 注意共享模块的加载顺序，避免循环依赖和死锁。
性能优化: 合理使用代码拆分和按需加载，优化应用的性能。
错误处理: 处理共享模块加载失败的情况，提供友好的用户体验。
测试: 对 Module Federation 的配置进行充分的测试，确保应用的稳定性和可靠性。

总结：Module Federation 的价值

Module Federation 是一种强大的代码共享和应用集成机制。它可以帮助我们构建更灵活、可维护和可扩展的应用架构。

掌握运行时共享模块的概念和用法，可以让我们更好地利用 Module Federation 的优势，解决实际开发中的问题。

希望今天的讲座能帮助大家更深入地理解 Module Federation，并在实际项目中灵活运用。

最后，感谢大家的聆听！如果有什么问题，欢迎随时提问。咱们一起进步，共同成长！

发表回复 取消回复

发表回复取消回复