1. 简介
理论上monorepo是仓库管理的架构。
2.使用前提
有多个项目，需要在多个项目中复用大量组件，逻辑，工具函数等。
ps:
1.我认为项目不超过三个，即使有共同组件，也不需要用monorepo。或者将公共部分打包，npm install安装也可解决问题。
2.每个项目相对独立，无复用代码，或者可复用代码较少，我觉得也不需要用monorepo。
3.使用monorepo的好处
1.便于代码复用：多个仓库会用到的组件、工具函数、类型声明、样式等，可以放到common子包中，需要的仓库直接npm install这个子包就行。
2.独立构建和部署：每个子包都是一个独立的项目，有自己的package.json文件，互不影响。（个人认为不使用monorepo时，也是独立的。）
3.降低切换成本：只有单一仓库，所有项目不需要重新clone代码，切换分支，安装依赖。（个人认为降低切换成本的前提是，各个阶段分支只有一个的情况。试想monorepo仓库有5个项目，每个项目各有5个开发版本并行呢？）
4.节约磁盘空间：支持全局依赖管理，共享依赖。
5.方便提交公共部分的更新：增加新组件或更新函数，只需要提交一次代码修改。（分支较少情况。确实方便。如果多版本分支情况下，需要将common修改依次合并到各个版本开发分支，从以前的要在每个分支改，变成common依次合并）
6.灵活便于扩展：增加一个新项目，只需要在新增加个子包，不需要申请新的仓库。（个人认为，monorepo旨在方便管理代码，维护多个公共内容较多的项目。会引起另一个问题，仓库代码不断扩大，会影响git效率，会pull下来不关自己的commit，构建速度变慢，项目启动较慢；不需要新的仓库，分支个数成倍增长，较难维护。）
以上个人认为是基于对monorepo不成熟的使用的一些体验，仅个人观点。
4.必要性，不用会怎么样
前提是多个项目有共同组件
- 多个项目放在一个仓库，一个文件夹一个项目，公共部分提到common文件夹，相对路径引入使用。
好处: 代码复用问题解决。
坏处：仓库会越来越大，项目越来越重，打包速度变慢，容易卡。
- 项目独立，公共部分各自维护
好处：相互独立，维护方便。
坏处：共同组件代码维护不方便，流水线多次修改。
5. 使用步骤
参考链接中已详细介绍。
6.总结
如果项目想要用monorepo，适不适合用monorepo，我觉得需要慎重考虑与调研。
公共部分修改一次的方便，会带来一次出错，会影响所有项目出问题，耦合性较高。（为了减少这种风险，可以在进行公共部分的修改时，加强代码审查和测试，确保修改的正确性和稳定性。同时，合理规划公共部分的代码结构，使其更易于维护和扩展。）
7.monorepo与微前端区别
Monorepo 和微前端的区别主要体现在以下几个方面：
- 关注点不同：Monorepo 主要关注代码的组织和管理方式，侧重于代码复用、统一的依赖管理等；微前端则更侧重于前端应用的架构模式，将大型应用拆分成多个独立可部署的小型前端应用。
- 应用场景不同：Monorepo 适用于多个相关项目需要共享代码和逻辑的情况；微前端适用于构建复杂的大型前端应用，以实现各个功能模块的独立开发、部署和维护。
- 架构层次不同：Monorepo 更多是在代码层面的组织；微前端是在应用架构层面的划分。
总的来说，Monorepo 着重于代码管理，微前端着重于应用架构的拆分和组合。
8.monorepo与微前端之间的联系
Monorepo 和微前端的联系：
Monorepo 主要侧重于代码组织和管理，通过将多个相关项目放在一个仓库中，便于代码复用、统一管理依赖等。
微前端则更侧重于前端应用的架构模式，将一个大型应用拆分成多个独立可部署的小型前端应用，每个应用可以有不同的技术栈，并且能够独立开发、部署和运行。
在某些情况下，Monorepo 可以为微前端架构中的各个子应用提供统一的代码管理和复用机制，使得不同的微前端应用在代码层面能够更方便地共享和复用一些通用的组件、工具函数等。但它们是两个不同层面和侧重点的概念。
参考链接： juejin.cn/post/740477…
