monorepo 当前在前端圈中已经比较普及了，社区有一些开源解决方案，很多公司也在落地 monorepo，但是很多团队在业务落地的过程中出现对 monorepo 的滥用，这样会带来一系列的问题。
什么是 monorepo
monorepo 的初衷是为了解决多个项目间的版本依赖和发布问题，最有代表性的就是 babel 了，babel 项目中存在包依赖，发布时需要同时进行依赖包的发布，这种情况下 monorepo 可以完美的解决这个问题
如何使用 monorepo
lerna 是社区中可以较好处理 monorepo 的代表，使用方式也比较简单，可以参考对应的官方文档：https://lerna.js.org/
什么情况下需要使用 monorepo
库
库是最适合使用 monorepo 的了，因为发布需要牵扯到依赖包，一条命令可以通通解决
什么情况下不要使用 monorepo
项目
将多个业务项目组合成 monorepo 可以解决一部分问题，例如：
- 统一的发布管理
- 多个项目同时依赖一个库
- 项目的统一管理（多个 git 仓库变成一个 git 仓库）
这些问题虽然得到了解决，但是这会带来更大的问题
1. 开发体验差
在开发项目时，需要一次性构建 monorepo 中的所有项目，构建速度极慢，也会让编辑器变得卡顿，在开发过程中不丝滑
2. 打包速度慢
打包时需要联合多个项目进行构建，如果不使用 monorepo 而是将内容拆分为 npm 包则没有这个问题
3. code review 难
大量项目维护在一个 git 仓库中，日常会出现茫茫多的 MR，review 的时候不容易针对性的进行 reveiw，而拆分为多个仓库，每个人 own 一个仓库则不会出现这种问题
4. 发布不够稳
代码同时维护在 master 分支，某一个通用内容的上线可能会带来其他项目的不稳定；当然也可以选择差异化上线，但是这相当于将隐患后置，并且这种后置的隐患更难以排查
5. 合作体验差
由于项目统一维护在一个大的 monorepo，一些公共包（例如类型定义）如果被其他部门使用，则需要另外的部门在这个「臃肿」的项目中进行操作，这样的体验会非常差
总结
monorepo 一时爽，后续会面临着很多长痛，如果仅仅是为了解决多个业务项目间的 通用函数或组件 复用，还是老老实实使用 npm 包吧~