浅谈monorepo

现在业内对repo的组织方式开始从multiple repo转而推崇monorepo, 那它有什么好处, 毕竟新东西意味着新的学习成本, 它一定是解决了我们开发上的某些痛点, 另外本篇幅不涉及具体的monorepo技术细节选型，如rush、lerna

更统一的业务视角，项目没有割裂

我在猪厂做的是一款客服产品, 根据不同的功能模块会分成在线端、呼叫端、智能端, 但有时候会导致对应的rd同学只关心自己负责的每个项目，无法以整体的业务视角看待

有些业务可能有bff模块, 拆成多个repo总觉得割裂

一个需求如果涉及多个repo时，multi repo的git也显得不统一，a仓库有改动，b仓库有改动，merge branch和code review时都有一种割裂感, 明明做的是同一件事，却涉及那么多仓库，很容易理解你的变更对整个项目的影响

一些构建发布的流水线、eslint、prettier等相关配置可以收敛至一份

有一些公共业务模块(components、hooks)的复用, 如果一直使用复制粘贴大法, 同样一份代码多处存在是我们极力要避免的, 且后续的更新迭代都需要手工再复制粘贴（也可能a项目迭代了一些功能，b项目迭代了另外的功能，慢慢的就变成不是一个东西了）

我们可能会把这些公共组件抽成私有npm包, 但是用npm包的模式也会遇到一些问题

a项目、b项目依赖了foo包, 随着时间更迭a项目依赖foo@3.x, b项目还在foo@1.x，这时候想在foo上加个新功能给b使用，foo从v1-v2-v3的破坏性更新让foo的升级又心惊胆战

针对上述的问题，最好的办法还是强制保持各个项目（a、b）都依赖最新的foo, 每次对foo升级后, 观察各个项目是否符合预期

但如果多仓库，不太能知道到底有多少项目依赖了foo 且每次调整, 都需要对foo发布一次npm，对a、b更新foo的版本号，再发布项目a、b, 流程感觉较为繁琐, 本地调试时也是（需要通过软链设置）

但是在一个monorepo下我们就可以快速的搜一下, 知道哪些项目会受影响（可以做到心中有底）, 对于锁定最新版本，在一些monorepo的生态中我们可以直接写死foo: workspace:*

monorepo模式下, 可以减少共同依赖的重复安装, 当然pnpm也可以做到这一点, 安利pnpm一波, 详情可见pnpm的topicopen in new window