webpack 5模块联邦中共享依赖的Tree shaking相关技术疑问

完全不需要禁用共享库的Tree Shaking，也不存在“运行时合并两个远程包各自打包的库代码片段”这类操作——相关现象本质是对模块联邦的单例共享机制存在认知偏差。

很多人对singleton模式的误解是“运行时把多个包里打出来的同库裁剪片段做拼接合并”，实际完全不是这个工作流。

• 只要在Webpack 5的模块联邦配置里，把目标npm库正确加入shared清单，Host（本地仪表盘）和所有Remote（远程组件包）的打包流程从一开始就会把这个库标记为外部共享依赖：不会把该库的任何代码片段打进自身的主bundle，只会保留对该依赖的运行时引用占位
• 运行时的单例判定规则非常简单：只要加载过任意一个满足语义版本要求的该依赖实例，后续所有引用该库的模块都会直接复用这个已加载的实例，绝对不会加载第二份重复代码
• 观察到的“每个Remote包都打出不同的Tree Shaking后库片段”现象，本质是没有把这些库配置为联邦共享依赖，走的还是普通npm依赖的打包逻辑——这种状态下哪怕加了singleton: true也没用，因为Remote的产物里已经实打实把裁剪后的库代码硬编进去了，没有外部引用的占位，运行时根本没法替换成单例

整个配置流程不需要对共享npm库做任何禁用Tree Shaking的调整，核心是把共享依赖的消解流程走对：

• 第一步：在Host和所有Remote的Webpack配置里，把所有要跨包共享的npm库，统一对齐加到ModuleFederationPlugin的shared字段下，让Webpack从打包阶段就把这些库从普通依赖列表里剥离出来：

  // Host和所有Remote的shared配置，公共库清单必须保持一致
  shared: {
    // 示例：共享lodash-es
    'lodash-es': {
      singleton: true,
      requiredVersion: '^4.17.21', // 对齐所有依赖该库的包的版本范围
      strictVersion: true,
    },
    // 必须共享的React生态同理
    react: { singleton: true, requiredVersion: '^18.2.0' },
    'react-dom': { singleton: true, requiredVersion: '^18.2.0' },
  }
  

• 第二步：保持原有Tree Shaking配置不变即可：
  • 所有被共享的npm库本身要保持标准ESM导出格式，确保Webpack的Tree Shaking能识别可裁剪的导出
  • Host应用作为共享依赖的默认加载兜底，会按照自身实际用到的导出做Tree Shaking，只会把真正需要的库代码打进共享chunk
  • 所有Remote包因为已经把库标记为外部共享依赖，自身的Tree Shaking流程根本不会触碰这个库的代码，从根源上避免了“每个Remote打不同库片段”的问题
• 第三步：遇到版本兼容问题时的处理
  • 如果存在不兼容的版本冲突，不需要禁用Tree Shaking，只要把对应共享项的singleton关掉即可，Webpack会为不同版本的库加载独立实例，不会互相污染
  • 所有不同版本的库实例加载时，依旧会按实际用到的导出做Tree Shaking，不会加载全量代码

• 误区1：单例模式需要运行时合并多个Remote裁剪出的库代码片段
  实际单例模式从打包阶段就切断了“把库代码打进Remote产物”的路径，根本不存在“合并代码片段”的需求。所有库代码只会由第一个匹配版本的加载方按需裁剪后加载一次
• 误区2：开了单例共享就必须全量打包库，不能用Tree Shaking
  实际效果完全相反：只要共享配置正确，Tree Shaking的收益和开发普通单页应用时完全一致，还会去掉跨包的重复库代码，整体产物体积会更小
• 误区3：如果Remote用到了Host没有预置的库导出，就必须全量加载整个库
  模块联邦的共享机制支持动态按需拉取依赖：当Remote运行时需要某个Host没有预置的库导出时，Webpack会自动从匹配版本的共享chunk里拉取对应的代码段，不会全量加载整个库

提问来源于stack exchange，提问作者jn_dev