我不知道这是否适合您的用例，因为您可能出于某种原因需要坚持使用monorepo，但是我们有一个类似的情况，我们的前端需要从不同的自定义包中提取不同的屏幕。（这可以像创建一个对应的package.json一样简单），将其发布到自己的私有Git仓库，然后通过npm将其安装到容器包中，就像安装任何其他模块一样（如果您使用私有存储库，则需要创建Git令牌或设置SSH访问）。
这样做的另一个好处是，你可以使用Git release标签来标记提交版本（我们编写了自己的实用程序，使用Git钩子自动管理这个过程，使之更容易），然后你可以使用与常规npm包相同的semver范围来控制你安装的版本。
例如，容器package.json中的一个依赖项可能如下所示："my-package": "git+ssh://git@github.<company>.com:<org or user>/<repo>#semver:^1.0.0，在GitHub端，你可以用标签v1.0.0来标记你的提交。

然而，我们并不总是准备好将每个屏幕的最新版本投入生产。
如果这种情况经常发生，那么monorepo可能不是构建项目代码的最佳方式？monorepo是适应相反情况的理想选择，在这种情况下，您希望在合并之前确保所有内容都集成在一起。
这通常是最快的开发方式，因为你不会把不确定的集成工作推到未来。如果你（或其他人）以后不得不回来，你会失去上下文切换的时间。把它弄走更有效率，而monorepo使它变得尽可能容易。
如果你需要支持旧版本的代码一段时间，因为它依赖于你不能改变的代码，有时你可以在你的主分支上存储多个版本。React是一个很好的例子，看看所有的.new.js和.old.js文件：
https://github.com/facebook/react/tree/e099e1dc0eeaef7ef1cb2b6430533b2e962f80a9/packages/react-reconciler/src * main上的当前上次提交 *
当然，这会造成一些“重复”，但是如果你需要在可预见的未来同时维护两个版本，那么如果它们一直都在那里，那就容易多了。每个人都可以拉它，没有人会因为他们没有 checkout 一些标签/分支而错过它。
当然，你也不应该做得太过分。理想情况下，这是一个临时措施，一旦没有代码依赖于旧版本，你就可以删除它。