案例步骤：
- 我在
packages中有packages/commonpackages/react-A这两个子项目 react-A具有依赖项common@1.0.0- 我将
common从v1.0.0升级到v2.0.0，并做了很多更改 react-A将显示错误，因为它的依赖关系也将更新
每次我升级common库进行重大更改时，我都必须修复其他有它依赖性的地方，这是正常的方式吗
TL；DR-是的，更改许多项目共享的共同依赖项的可见/API代码将迫使您在不同的项目中遵守这些更改。这是意料之中的事。
单回购工作流程是什么？
monoreo是一个版本控制的代码存储库，它包含许多项目。虽然这些项目可能是相关的，但它们通常在逻辑上是独立的，由不同的团队运行。
工作流程包括(但不限于(以下内容：
- 大规模提交-可能会也可能不会同时影响多个独立项目的提交
- 代码可见性-项目查看其他项目的代码
- 共享提交历史记录-影响多个项目的提交应可见
以及更多内容。因此，工作流程是在一个历史树下管理多个项目如何这是团队特有的。。。
我认为有很多很棒的在线资源和博客文章非常详细地描述了什么是单回购，所以我不会深入讨论，因为我不认为这是问题的本质。你是有一个单回购，还是只有一个项目，其中有几个子模块，由你来决定，因为单回购更多的是一个概念，而不是一个实际的物理事物(我在这里对这个定义不太重视(。
但我认为你的问题与monorepo工作流的关系不大，更多地与通用软件设计有关。
您有一个common库。该库可能有也可能没有其他人将使用的API。该库的API可能会随时间变化，也可能不会随时间变化。如果您可以控制API的更改方式，那么很明显，如果您更改API，与该库集成的每个都必须符合新的API。
如果common的v1具有一组指定API如何的特定方法签名，并且common的v2更改这些签名，则从v1迁移到v2的用户必须更改他们使用common的方式。从根本上讲，这与您在内部重构代码或只是为自己的项目更改函数没有什么不同现在，如果这种方法对您没有吸引力，并且您希望具有向后兼容性和稳定的API，那么有特定的软件工程方法来确保这种稳定性和灵活性，但最重要的是，这是您必须付出的努力，这样实现更改就不会影响您的API，而这将影响/不影响您的其他项目。
还有像Lerna这样的好工具，可以更容易地管理相关项目中依赖项的更新。
Material Web Components存储库是如何做到这一点的一个有用示例(https://github.com/material-components/material-web)，Lerna提供了让monorepo中的每个包都保持自己的版本号或一致地对它们进行版本设置的选项。
到目前为止，我更喜欢第一种选择，因为根据SemVer标准，对一个包的破坏性更改不一定会在另一个包中创建破坏性更改，因为依赖关系中的破坏性变化可能已经由依赖包内部处理。