解决Callstack/Repack项目中微前端导航冲突问题

在Callstack/Repack项目中实现微前端架构时，开发者经常会遇到一个典型问题：当子应用包含React Navigation导航组件时，主应用加载子应用后会出现Invariant violation: I tried to register two views with the same name RNCSafeAreaProvider错误。这个问题本质上是由于React Native导航相关的原生模块在微前端环境中被重复注册导致的。

问题根源分析

在微前端架构中，当主应用和子应用都使用了React Navigation这类包含原生模块的库时，如果没有妥善处理依赖共享，就会出现以下情况：

1. 主应用和子应用各自打包了完整的React Navigation及其依赖
2. 运行时两个实例的原生模块尝试向系统注册相同的组件名称
3. 系统检测到重复注册而抛出错误

解决方案

要解决这个问题，关键在于确保所有包含原生模块的依赖在主应用中正确共享：

1. 主应用Webpack配置：必须在ModuleFederationPlugin中显式共享所有子应用可能用到的包含原生模块的依赖

new ModuleFederationPlugin({
  shared: {
    'react-native': { singleton: true },
    'react': { singleton: true },
    'react-native-safe-area-context': { singleton: true },
    // 其他包含原生模块的依赖
  }
})

2. 强制引入机制：即使主应用不直接使用某些子应用依赖，也需要在主应用的入口文件(index.js)中显式引入这些库，防止打包时被优化移除

// 主应用index.js中
import 'react-native-safe-area-context';
import 'react-native-reanimated';
// 其他子应用需要的原生模块

3. 版本一致性：确保主应用和子应用使用的相关依赖版本完全一致，避免因版本差异导致兼容性问题

最佳实践建议

1. 依赖管理策略：建议建立一个共享依赖清单，包含所有可能用到的包含原生模块的库
2. 文档规范：团队内部应明确微前端架构下依赖管理的规范，特别是对于导航等核心功能
3. 性能优化：虽然需要共享多个依赖，但应仅共享确实包含原生模块的库，纯JS库可以保持独立打包

通过这种集中管理原生模块依赖的方式，可以有效避免微前端环境下的组件冲突问题，同时保持应用的稳定性和性能。