大型React Native项目架构咨询：团队扩张下monorepo适配方案问询

先明确核心结论：不建议一上来就拆分独立仓库或切换微服务架构 #

我所在的团队之前负责过14人协同维护的React Native monorepo仓库，包含3款线上应用、30+公共包，踩过很多拆分相关的坑，首先可以明确两个误区：

• 拆分为独立仓库的成本远高于预期：公共包修改后需要走发版、同步流程，跨包调试、bug回溯的效率会下降40%以上，我们之前尝试拆分过6个公共包为独立仓库，仅依赖对齐、版本冲突解决的工作每周就要占用1人天的工作量，最后又合并回了monorepo
• 移动端微服务架构（通常指动态化微前端方案）适配React Native的成本极高，需要解决bundle拆分、公共依赖去重、路由打通、原生侧兼容等大量问题，除非你有明确的动态下发业务需求，否则完全没必要为了协同问题引入额外复杂度

我们在现有的monorepo架构下做的优化方案，已经支撑14人协同开发1年以上 #

• 权责划分前置：在packages/目录下按业务域拆分二级目录，每个二级目录绑定1-2名负责人，在仓库根目录配置CODEOWNERS文件，所有修改对应目录的PR会自动触发负责人审批规则，从流程上避免跨模块乱改代码
• CI任务分片提速：配置CI工具基于Git提交记录做增量检测，仅运行当前PR修改的包对应的单测、lint、构建任务，我们把单PR的CI执行耗时从22分钟降到了4分钟，大幅提升合码效率
• 公共包版本分层管理：稳定迭代的公共包发版遵循语义化版本规则，依赖声明用^x.y.z格式；仍在高频迭代的公共包使用workspace本地依赖，声明为workspace:*；所有公共包的break change修改必须提前同步所有使用方，评审通过后才能合入
• 定期做公共包治理：每双周抽半天时间清理废弃公共包、合并重复的工具方法，把长期仅单个应用使用的公共包下沉到对应应用的内部目录下，避免公共包无意义膨胀

只有满足以下条件时，才建议考虑拆分独立仓库 #

• 单款应用的开发人数超过15人，和仓库内其他应用的业务关联度极低，连续6个月以上没有跨应用复用公共逻辑的需求
• 单个公共包已经稳定迭代1年以上，没有频繁的break change，同时有多个外部仓库需要依赖该公共包

内容的提问来源于stack exchange，提问作者Diego Oliveira