库版本不兼容的问题是什么，monorepo-style如何解决？

Question

我开始对 monorepo 方法特别是 Nx.js 感兴趣。几乎所有的文章都说 monorepo 解决了库版本不兼容的问题，我不太明白是怎么做到的。我有几个问题：

1. 如果我理解正确的话，monorepo 的想法（就共享代码而言）所有共享代码总是相同的版本并且所有更改都发生在一个原子提交中（作为 monorepo 状态的广告）。所以让我们想象一下 monorepo 有 100 个项目，它们都依赖于同一个 repo 中的libA。如果我在libA 中更改了 smth，那么我必须检查所有相关项目中的更改。此外，我必须等待所有代码所有者审查我的更改。那么什么是高手呢？
2. 让我们想象一下，我有以下项目的 monorepo：appA、libC、libD，还有一些第三方库，我们称它为third-party-lib。 appA 依赖于 libC 和 libD。有时appA需要third-party-lib-v3，但libC依赖于third-party-lib-v1。 https://monorepo.tools/#code-generation 指出：“所有内容的一个版本 无需担心由于项目依赖于第三方库的冲突版本而导致的不兼容性。”。但事实并非如此。在 Javascript 的世界中，它会在不同的 node_modules 中产生 2 个不同版本的 third-party-lib。再问一下，什么是专业人士？

   我的问题可能非常天真，因为我从来没有遇到过图书馆问题，而且我刚刚开始学习 monorepo 主题，所以如果有人帮助我处理它，我会很高兴。

Answer 1

在非 monorepo 环境中使用共享代码后，我可以说在没有像 NX 这样的 monorepo 的情况下管理内部包需要纪律并且可能更耗时。

在您使用 1 个库的 100 个项目的示例中，所有 100 个项目都应该使用新版本的代码进行测试和部署。区别在于什么时候.

在单独的回购协议中，您将发布包的新版本，以及随之而来的所有代码审查和单元测试。接下来，您将更新所有 100 个应用程序中的包版本，可能一个一个地更新。您将测试它们，获得代码审查，然后部署它们。

现在，如果您发现其中一个应用程序中的新更改存在问题怎么办？你会回滚到以前的版本吗？如果它在应用程序中，那么您可以在那个应用程序中修复它，但如果它在库中，您会回滚所有应用程序中的版本号吗？如果您的图书馆需要进行其他更改怎么办？

您可能会发现自己的应用程序正在使用不同版本的库，并且您无法推出新版本，因为您无法让某些应用程序使用以前的版本。在许多共享库中乘以它，你就有了管理上的噩梦。

在单一回购中，痛苦是一样的，但它需要更少的管理工作。借助 NX，您可以了解您的更改会影响哪些应用程序，并且可以在部署更改之前测试所有这些应用程序，并一次部署所有这些应用程序。您不会阻止其他更改进入您的库，因为这些更改只有在所有使用它们的地方都经过测试后才会提交。

第三方库也是一样。当您更新库的版本时，您会在提交更改之前在所有使用它的应用程序中测试它。如果它在一个应用程序中不起作用，您可以选择。

• 修复阻止该应用程序工作的问题或
• 不要将包更新到新版本

这意味着您没有“遗留”的应用程序并且被迫使所有内容保持最新。这确实意味着有时更新可能会花费太多时间以至于难以确定优先级，但这对于多回购开发来说是一样的。

最后，我想补充一点，当开始使用 NX 时，您可能会发现自己创建了大型的、经常更改的库，这些库被所有应用程序使用，或者可能会在应用程序本身中放入大量代码。这会导致痛苦，因为更改经常导致整个 monorepo 的部署。我发现最好创建特定于应用程序的文件夹，其中包含仅由该应用程序使用的库，并且仅在具有商业意义时才创建共享库。例子是：

• 调用 API 并返回不应真正更改的业务域对象的服务（对这些 API 和响应的更改通常会导致 API 的 V2，并且可以创建一个新的 NX 库来为该 V2 API 提供服务，留下 V1不变）。
• 每个组件的核心、稳定的原子 UI 库（同样，尽量不要更改组件本身，但如果需要更改，请创建一个 V2）

有关这方面的更多信息，请参见此处NX applications and libraries