Javascript monorepo的工作流程是什么？每次我更新公共组件库时，我都必须更新它依赖的其他地方。这正常吗？ 案例步骤： 我有packages/commonpackages/react-A这两个子项目在packages react-A具有依赖性common@1.0.0 我将common从v1.0.0升级到v2.0.0，并做了很多更改 react-A将显示错误，因为它的依赖关系也将更新 每次我升级我的common库进行重大更改时，我都必须修复其他依赖它的地方，这是正常的方式吗？

TL；DR-是的，更改许多人共享的公共依赖项的可见/API代码将迫使您在不同的项目中遵守这些更改。这是意料之中的

---

monorepo的工作流程是什么

monorepo是一个版本控制的代码存储库，包含许多项目。虽然这些项目可能是相关的，但它们通常在逻辑上是独立的，由不同的团队运行

工作流包括（但不限于）以下内容：

• 大规模提交-可能会或可能不会同时影响多个独立项目的提交
• 代码可见性-项目请参见其他项目的代码
• 共享提交历史-影响多个项目的提交应可见

还有更多的事情。因此，工作流是在单个历史树下管理多个项目你如何做到这一点是团队特有的

---

我认为有大量的在线资源和博客文章非常详细地描述了monorepo是什么，所以我不想深入讨论，因为我不认为这是问题的本质。无论你有一个monorepo还是一个包含几个子模块的项目，都由你来决定，因为monorepo更多的是一个概念，而不是一个实际的物理事物（我在这里对定义轻描淡写）

但我认为你的问题与monorepo工作流程关系不大，更多的是与通用软件设计有关

您有一个

公共

库。该库可能有也可能没有其他人将使用的API。该库的API可能会也可能不会随时间变化。如果您可以控制该API的更改方式，那么很明显，如果您更改API，与该库集成的每个人都必须遵守新的API

---

如果

common

的

v1

具有一组特定的方法签名，指示API的方式，并且

common的
v2
更改了这些签名，那么从
v1
迁移到
v2
的用户必须更改他们使用
common
的方式。从根本上说，这与您在内部重构代码或只是为自己的项目更改函数没有什么不同现在，如果您不喜欢这种方法，并且希望具有向后兼容性和稳定的API，那么有特定的软件工程方法来确保这种稳定性和灵活性，但最重要的是，这是您必须付出的努力，以便实现更改不会影响您的API，这将影响/不影响您的其他项目。
我很欣赏您的回答，您提供了富有哲理的想法并回答了我的问题，现在我对monorepo flow非常清楚！