Monorepo是什么，为何众多团队选择用它来管理项目？

Monorepo到底是个啥玩意儿？

先说实话，听到 Monorepo，很多人会脑子里立刻浮现出一大堆仓库合体的画面。 其实它就是把一堆相关项目塞进同一个 Git 仓库里管理的策略。 别搞混了 Monolith 是架构层面的“大而全”，Monorepo 则是代码组织层面的“一锅端”。 哈哈，这种“一锅端”听起来有点吓人，但真的不一定是噩梦，放心去做...。

为什么越来越多团队要搬进 Monorepo 的“大屋子”

第一，跨项目改动太频繁。 想象一下 你在公共 UI 库里改了一个按钮的颜色，原来每个业务线都得单独发布 npm 包、跑 CI、再手动更新依赖。 在 Monorepo 里 一次提交就能同步到所有使用它的子项目，省得你天天打开十几个 PR，真是爽到飞起。

第二，统一依赖管理简直是福音。 以前每个仓库都有自己的 node_modules， 磁盘空间嗖嗖上涨，还常常出现“幽灵依赖”。 用了 pnpm 工作区以后 根目录下只装一份依赖， 内卷... 子项目通过硬链接共享，同版本的包只会出现一次。 这不止省磁盘，还让“未声明却能用”的问题立马曝光，让 bug 更早被抓住。

第三，CI/CD 能够实现增量构建。 在大型 Monorepo 中， 我们可以通过分析本次提交影响的范围，只编译受影响的服务或库。 比如改了 utils 包， 就只重建引用了它的模块；如果改了公共组件库，那所有依赖它的前端应用都会自动重新打包。 这样一来构建时间从几个小时压缩到几分钟，大大提升团队效率。

常见工具链大盘点

npm、 yarn、pnpm 都提供了 Workspace 能力。 其中 pnpm 主要原因是严格模式和硬链接特性，被不少公司冠以 “依赖管理神器”。 而 Turborepo、 Nx 之类则负责任务编排：判断哪些子项目需要跑测试、哪些可以并行施行、哪些可以直接走缓存，哭笑不得。。

最终的最终。