在开源社区流行着这样两种项目办理的方法:

  • 多repo库房办理 (multirepos)
  • 单repo库房可是多包办理 (monorepos)

在很早的时候, 我的项目 tailchat 是一个典型的多repo办理的项目。

我创立了一个组织，组织下有多个tailchat相关的项目:

  • tailchat
  • tailchat-server
  • tailchat-website
  • tailchat-cli
  • tailchat-rss-bot
  • tailchat-archive
  • tailchat-docs
  • tailchat-meeting
  • …

多repo的好处在于绝对的阻隔，独立的发布机制，独立的库房上下文(issues/prs)。可是我在长期的时候中逐步发现了多repo办理上的问题，以致于我抽出了时刻将其合并成了一个项目。

接下来我会说说我遇到的问题。

多repo遇到的问题

精力上的分散

多repo意味着要一起办理多个项目，一些边际的repo甚至会持久的失掉保护。关于开源项目来说失掉保护意味着死亡。而开源项目也往往会意味着办理人员精力上的分散，不论是企业支撑的开源项目来说还是个人支撑的开源项目来说。

比方react社区知名的UI组件库 antd。作为一个抢手库来说它一向保留着十分高的活跃度，也不缺少保护人员。可是他的基础库rc-xxx却很少有人去处理pr。由于摊子铺的很大，十几个小的组件库分红不同的repo，就意味着开发组的成员很难分配精力在这些改动并不频频的库房上面。

发版与分发上的割裂

以最根本的前后端分库来看(client/server)，两个repo意味着两套发版流程(当然能够说通过第三方渠道把他们组合在一起，这个咱们暂且不评论)。一起意味着你不得不打两个tag，发两个release，以及跑两个CICD流程。假如你有一个website项目(文档)。你不适合放在恣意一个client/server 库房。这不得不形成你必须再创立第三个项目。

这三个项目从逻辑上来看确实是没有任何关系，可是在业务上来看却是耦合在一起的！这三者的同步就意味着需求花费保护者额定的精力，也意味着风险。

产品困难

别的便是项目的产品，多repo意味着多产品。多产品也意味着用户需求更多的上下文，关于不了解或许不愿意了解的用户来说这便是额定的错误或许以及精力本钱。额定的入门门槛会极大的打击用户的使用信心。

一个简略的比方便是，作为用户愈加希望只需求布置一个应用就能完结一切。而一个需求 前端+后端 的项目意味着额定的学习本钱，不友好。

根本装备不通用

多repo的办理机制还有一个常见的问题便是项目的装备没有办法通用。比方 Tailchat 项目是使用 typescript 来进行开发的，还需求一些主动化东西比方代码格式化，代码查看，git hooks等。那么一个项目需求配套: tsconfig.json, commitlint, prettier, eslint, lintstage, editorconfig…

多个项目就要配多套装备。假如改了一处需求把一切的项目都改一遍。想想就简直是一场噩梦！

当然能够产出一套东西专门办理相关的装备，可是这也意味着额定的精力本钱，一起也引出了另一个问题，那便是改动的滞后性 —— 改动的装备没有办法当即产生效果，必须提交代码到这个东西的库房 -> 发布 -> 同步到一切相关的库房中。

假如说咱们花了太多的时刻在这种工作上，那我能够以为，这个项目的DX(Developer Experience) 是失利的。

奉献的积极性

别的一个比较隐晦的问题在于，关于开源项目来说，多个包往往也会打击潜在奉献者的奉献积极性，奉献者往往期望往主库去提交代码，而多库意味着奉献的分散化。

使用 monorepos 结构后我取得的收益

自从将本来的项目结构修改为monorepo以后，写代码都舒服了很多。其中当即能够取得的收益包括但不限于:

  • 依靠缓存复用
  • 一套装备一切项目获益
  • 一致办理一切 action 和 action env
  • 产品一致，只需求输出一个docker镜像
    • 用户也反馈布置愈加方便了
  • 一致版本号，不会再出现前端一个版本后端一个版本的情况了
  • 翻开项目愈加方便了，不需求翻开多个repo
  • 只需求关注一个项目的 github webhook 就能够订阅一切动态

一起，其他一些或许的操作也变得有或许了，比方：

  • 编写脚本，从客户端与服务端的代码中收集信息主动生成文档。
  • 客户端根据服务端代码主动生成网络请求代码
  • …

当然，有获益就有支付，monorepos 现在给我带来的问题有:

  • pnpm install的时刻更长了，由于需求装置/编译的内容更多了
  • docker build的时刻更长了，由于每次打包都需求一起编译前端和后端的项目，而不管有没有发生修改。
  • node_modules的内容过多导致在tree viewer中翻页会比较困难。

我觉得这些问题都是能够接受的，比较收益来说这点支付简直能够说是忽略不计。当然这只能说是个人开发者或许小团队开发能够有很大收益的方法，关于大型团队来说，monorepos的方法会带来很高的沟通本钱和办理本钱。只能说存在即合理，作为开发人员咱们需求找到适合自己的当前状况的最优解。