Monorepo和pnpm很早之前听说过，只是一直觉得暂时用不上，就没有去了解。而越来越多的知名开源项目开始使用Monorepo策略，vue3、vite在去年九月十月就迁移使用pnpm。
其它一些开源项目更是很早就宣布使用monorepo，比如npm7:
Multirepo策略
传统Multirepo策略就是一个项目一个仓库，当我们要开新的项目，很多时候从旧项目copy一些工具函数或者全局逻辑、配置等。
现在公司用的就是Multirepo策略，新建项目使用封装的模板项目，统一有一个公共的SDK。所以自己正在经历这些痛点：
- 不同项目组使用模板项目新建之后，扩展、修复、调整，不同步。
- 自己项目组多个项目，扩展、修复、调整，得修改多个项目，维护成本越来越高。
- 使用封装的SDK，当修改调整一些代码的时候，得通知到所有使用这个SDK的项目进行升级，所有项目得发版上线。
- 不同项目组解决相同的问题却各自编写自己的代码。
痛点是存在的，优势也很明显，那就是独立存在：
- 独立部署
- 独立的版本控制
- 更快的开发
- 独立的权限，更安全
Monorepo策略
Monorepo策略是多个项目放到一个仓库里面，可以说完美解决了Multirepo的痛点：
- 重用和共享代码非常容易
- 可以访问所有项目
- 公共模块和项目之间的依赖很明确
- 重构会影响的非常清晰
随之而来的缺点：
- 项目越来越多，体积越来越大，版本控制也会变得困难，Git可能无法支撑过大的项目。
- 权限太过开放，安全性肯定就降低，造成严重后果机率随之提高。如何做到更细的权限管理是一个难点。
- 发布面临更多问题，CI（持续集成）/CD（持续部署）非常困难。
Multirepo和Monorepo是天然对立的两种模式，没有哪一种是完美的，Multirepo相对来说更大众，也更符合现在互联网的团队。
还需要明确一点，Monorepo不仅仅是把项目放到一个仓库下就可以，这需要一套完整的体系支撑。代码管理、开发流程、发布流程、测试等，每一个环节需要考虑的远远多于Multirepo。想要使用Monorepo，更重要的是团队整体的素质。
没有实践过Monorepo，所以并不能感受到Monorepo落地的困难程度，对于普通的团队来说，想要落地Monorepo，肯定是找已经一些比较成熟的开源项目，然后再去定制。
