为啥突然搞 Monorepo？被多仓库折腾怕了！

先给大家吐槽下我的 “痛苦往事”。
之前维护着一堆独立的 PHP 包，每次进行技术升级，简直就像经历一场噩梦：

• 升级地狱：想给所有包统一升级技术栈，得一个仓库一个仓库地打开修改。就拿 Webman 升级来说，一个个包都得去更改；最近又想把所有包的 PHP 最低版本提到 8.2，想想都不想干了。
• 重复造轮子：给每个包添加 phpstan 静态检查、pest 测试，这些配置工作得重复做，时间全浪费在这些琐碎的事情上，效率低到让人抓狂。

那段时间我就天天琢磨，有没有一种办法，能让这些包集中管理，别再这么零散折腾人了？Monorepo 的想法，就是这么冒出来的！

PHP 圈子的 Monorepo：表面安静，实则暗流涌动

说起 Monorepo，前端圈已经玩得风生水起了，pnpm 原生支持，npmjs 还能一个仓库发多个包，特别方便。
再看看咱们 PHP 社区，相关资料少得可怜，一开始我都怀疑是不是自己找错方向了。

但深入了解后才发现，原来不少大佬框架早就悄悄用上 Monorepo 了！
像 Laravel、Symfony，它们都有自己的拆包工具，能把代码拆分到不同仓库发布。
像 symplify/monorepo-builder，专门做 monorepo 构建的。
但以上的仓库探索和实践下来其实都不理想，不是配置繁琐，就是工具不够透明化。

土法炼钢：PHP Monorepo 的低成本实现

既然没有现成的完美方案，那就自己想办法 “搞事情”！我发现了 docker-gitsplit 这个宝藏工具，再搭配自己写的一些脚本，居然真的把 Monorepo 跑起来了！
这里给大家安利两个现成案例：

• webman-tech/laravel-monorepo： 我维护的所有 laravel 依赖
• webman-tech/components-monorepo：我维护的其他一些自用的 webman 依赖

大致的一些流程介绍下：

• 拆包：使用 gitspit 在代码 push 时，通过 github action 自动触发拆包
• 新加包，调整依赖等：使用 generate_composer.php 脚本，将相关 composer 信息从内部包的 composer.json 中提取到外部的 composer.json 上
• 统一测试和代码质量检查：只需要在 monorepo 的级别做 tests 和 phpstan 依赖即可，全局共享
• 独立包发版流程：可以通过 split 批量发版本（类似 laravel 和 symfony），也可以选择主动一个个去各个仓库下单独发版本

踩过的坑，给大家提个醒

当然，探索的路上哪能不踩坑：

• 旧项目迁移：对于旧项目迁移进来的，如果最终还需要 split 到旧的仓库，由于是构建了新的仓库，gitsplit 会 force push 出新的分支，导致原仓库该分支的提交历史就没了（建议提前备份好）。
• 依赖管理：在 Monorepo 里，有时候包 A 会顺手用了包 B 引入的依赖，结果单独发布 A 包时，就漏写了这个依赖，会导致在单独用 A 包时存在依赖丢失（请保持对依赖敏感）。