为什么我不建议滥用 monorepo

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 包吧~