如何在模块联合架构中简化从 Angular 12 微前端到 Angular 16 的大规模迁移？

Question

我们公司将在几周后举办一次研讨会，讨论我们将如何解决这个问题。我对组织的中层来说相当陌生，正在进行研究以试图帮助找到最佳的解决方案。

问题在于： 我们正在使用带有 Angular 12 集成 MFE 的模块联合。我们希望避免大规模的协调工作，并让团队在自己的时间升级他们的 MFE（到 v16 或 v18），但我们还没有想出一个干净的方法让他们做到这一点。请注意，这是一个企业级开发，有 90+ MFE，多个域，每个域有多个团队，每个团队拥有 1+ MFE。

我并不期望得到一个完全解决这个问题的黄金答案，只是向比我在该领域更有经验和技术的人发出试探，以便学习和探索一些想法/可能的解决方案。

非常感谢任何意见。谢谢！

我已经构建了一个具有多个 Angular 12 MFE 的生产模拟环境，反映了我们现有的生产 MFE 层次结构。然后我用它来测试各种 Ang 16/18 升级流程。到目前为止，它们是相当手动和密集的，这显然不是理想的解决方案 - 我现在正在研究/测试更好的替代方案。

Answer 1

需要考虑的一些事项：

如果您要使用 webpack 模块联合 - 您将被 webpack 困住。 esbuild 被认为是 Angular 的现代构建器，并且可以通过本机联合解决方案支持。

当转向联合解决方案时，应该有一个具有通用功能和最重要部分的共享库 - 共享注入令牌。例如，如果身份验证仅在 shell 应用程序中完成一次（并在其他应用程序中重复使用），则可能有一个

UserService

提供程序，并且当远程应用程序

inject(UserService)

时将使用同一个实例。

在实施联合解决方案之前，您必须了解注入树的工作原理。常见的错误是例如在 shell 模块中提供

provideHttpClient({... HttpAuthInterceptor....})

或

HttpClientModule

+

...Interceptor

，然后在远程模块中提供

HttpClientModule

，突然来自远程模块的 http 查询在没有身份验证令牌的情况下被触发。

Monorepo 解决方案（NX 是最受欢迎的解决方案）有助于保持一切有序、同步依赖项版本，甚至提供一些用于联合代码的集成解决方案。这并不总是适用，因为它意味着将所有应用程序放入一个 VC 存储库中。

如果 monorepo 不是问题 - 建议调整库版本。可以设置每个库的精确加载方式（以防版本不匹配），但这是一个额外的包大小/头痛/错误的可能性。

联合解决方案为远程应用程序提供“AppModule”。这些模块可以替代 ShellModule 根。由您决定团队是否支持这些。有时您不希望应用程序作为单独的实例打开，因为它们始终应在 shell 内打开。这些在开发时也可能有点用，就好像它们不起作用一样 - 每个开发人员都必须运行 shell + app 才能在应用程序上工作有时，复杂性不值得付出努力。