从19年结束时，团队从多雷波模式转移到Monorepo。经过2年的时间，我也有很多看法。这篇文章主要总结了我对MonorePo项目管理模型的浅薄理解。
本文不会介绍MonorePo的概念。如果您不知道MonorePo的概念，则可以参考本文：什么是Monorepo，为什么都使用它？或其他有关MonorePo的介绍文章，有很多在线，一个搜索和很多。
该团队从Multirepo到MonorePo的迁移主要是因为它方便共享和调试工具库，但是除此之外，MonorePo还有其他优势，例如：
团队最初使用MultirePo的主要问题是多软件共享代码和调试非常不便，也就是说，开发工具库/组件库的调试非常麻烦。您需要使用纱线链接模式来开发每次。仅此版本可用于其他项目，这导致了多个软件设备共享代码的高成本。
切换到MonorePo模式后，基本库的开发非常麻烦。我们可以在项目开发和调试项目中直接引用工具库，而无需使用纱线链接。
除了繁琐的共享代码外，每个工具库还需要配置自己的基础架构，CI/CD流程和开发环境。在同一时间对象维护成本。
想象一下，如果您需要开发多个项目，并且每个项目的开发模型都不一致。这种经历非常糟糕，这是非常劳动的。
但是，当我们使用MonorePo时，我们可以使用一组基础架构构建和开发规范来降低项目维护成本。只需要拿出一个单独的1-2个人即可专门维护基础架构，其他项目也不需要照顾关于它了。
同时，由于不再用于管理公共代码的发布模式，因此MonorePo中最新版本的公共依赖性是公共代码的最新版本。关注公共代码的自动测试，因为AS只要将公共代码合并到主代码，它将立即影响所有在线项目。
因为使用完全相同的基础架构，工作流程和开发环境，当团队相互协助时，不必在配置开发环境的过程中重复时间，如何部署项目等。
MonorePo模式确实解决了诸如多软件关节调整和基础架构重复使用之类的问题，但它也带来了一些独特的问题。
幽灵使用不属于它的软件包取决于数据库。我相信大多数使用MonorePo的朋友都应该遇到或理解。
使用依赖关系假设的Unterrender现在App1依赖关系。有一天，App2还希望使用此依赖项。目前，它直接在App2中运行。看来没有问题，但是实际上，App2并未添加依赖关系，但是由于纱线的依赖性有所改善，因此它将直接改善它。最外层的层允许App2使用依赖关系。
后来，App1不需要一天依赖。目前，它从中删除了相关项目，但是目前，App2直接悬挂。
毕竟，这种情况更好，在开发或部署时，该项目直接挂起。
最糟糕的是，App1需要升级到其自己的项目的返回。没问题，代码已合并给主人上网。
App2目前不幸，并且完全不兼容，App2根本没有升级相关代码，这导致在线App2项目直接挂起。
同伴依赖性错误地看着这个场景：
但是，如果未安装App2，它将使用变量促进的版本。
如果您很幸运并且完全不兼容，那么项目操作将直接悬挂。但是，如果这两个版本中只有一些API更改，并且在开发时不会遇到问题，但是您会尽快挂断电话上网。
或App1升级到该版本，这也将导致App2直接挂断，因为App2将使用App1升级后升级。
如何解决幽灵依赖是一个相对常见的问题。很容易导致在线问题，因为它更隐藏，很难找到，并且很难找到问题。因此，我们需要从根本原因消除幽灵依赖的问题。
导致问题的罪魁祸首是“依靠增强”，因此我们只需要找到一种解决问题的方法。
我们可以用PNPM替换Bag Manager，并直接帮助我们解决使用问题，但不能写信。
这个问题是充分理解的，哪个项目和n + 1项目，哪个汇编/依赖项之一较短？显然，单独的1个项目的汇编时间较短。
但是我们可以通过这两种方式减少施工时间（团队目前正在使用的两种解决方案）：
该项目需要根据需要构建的长期汇编时间主要是因为所有项目都需要构建，但实际上我们只需要构建一个可变的项目和受变更项目影响的项目，即需求用于施工。
如果项目使用Lerna，则可以使用所有需要构造的项目，然后仅构建项目的这一部分。
当我们不需要将整个MonorePo合并到Trunk分支机构时，手动指定的编译项目时，我们只能构建需要构造的项目。我们可以指定需要在“提交机构”中编译的项目以识别提交的身体CI脚本，仅构建一个项目。
当需要合并的主要分支时，将建立整个项目。只有该项目完成CI构建和验证，才能合并到主分支中。
同样，在安装加速后，项目越来越多后会有很多依赖关系，从而导致很长一段时间的安装依赖关系。
这也很容易解决。如果使用PNPM，则可以在按需安装上使用，即使用用于按需安装的用途。相关文档：过滤。
除了按需安装外，您还可以通过缓存方案加速。您可以阅读本文：依赖缓存加速CI结构
因为每个人的提交都处于MonorePo中的线性历史上，所以这是一团糟。如果团队不标准化对提交信息的强制性验证，则将导致犯罪信息直接放弃。如果您想解决此问题，团队，团队需要定义提交规则，而git钩子可以做得很好。
但是，即使执行了标准化的处理，也无法保存异常的提交记录，因此建议使用可视化工具查看GIT记录。例如，作者使用IDE随附的GIT工具。
如果Monorepo使用单个仓库，则仓库中的所有开发人员都可以看到所有项目的代码。如果您想在某个项目中应用细化的权限，很难实现一个仓库。因此，如果您需要保密您的项目，则需要谨慎选择MonorePo（当然，如果您有其他解决方案， 你可以告诉我）。
老实说，在使用monorepo之后，我的计算机只有四个词：“武脱起来”，因为我习惯于使用webstorm / indue来开发项目。它的大于数十个项目，每个项目的代码并不小。
如果您还使用想法来通过不需要注意的项目减慢此问题，或者仅打开您需要开发的项目。如果您想彻底解决此问题，建议直接替换M1 Mac。
如果您没有使用MonorePo之类的项目管理模型，并且可以接受这些痛点，则建议您尝试一下。特别是当您开发工具库时，Monorepo的模型确实很香。
如果您想练习，最简单的方法是直接使用它，毕竟Lerna已停止维护。您可以参考VUE 3的实践方法并复制它?
以上摘要是个人的一些简单理解。我希望读者和朋友可以从作者的摘要中获得一些东西。如果您有不同的理解或建议，请在评论区域留言，非常感谢。
原始：https：//juejin.cn/post/7099090192887185439