Composer如何拆分Monorepo为独立包_Composer拆分Monorepo为独立包解析

Composer如何拆分Monorepo为独立包

Composer 能不能直接把 Monorepo 拆成独立包？

答案很明确：不能。Composer 本身并不提供“拆分仓库”的功能，它的核心职责是 PHP 的依赖管理，负责处理 vendor/ 目录下包的安装、更新和自动加载。将 Monorepo 拆分为独立包，本质上是一个涉及工程组织和 Git 仓库管理的操作，Composer 的角色是在拆分完成后，参与这些独立包的声明、发布和消费环节。

拆分前必须手动完成的三件事

在动手修改任何 composer.json 文件之前，有三项基础工作必须到位。跳过任何一步，都可能在未来埋下隐患，比如自动加载冲突、版本管理混乱或者持续集成（CI）流程失败。

• 按功能切分子目录：首先，需要根据清晰的功能边界，将代码划分到不同的子目录中，例如 packages/http-client 和 packages/event-bus。确保每个目录内的代码高度内聚，并且没有运行时直接依赖其他子包的情况。
• 初始化独立 Git 仓库：为每个子目录创建独立的 Git 仓库。这里推荐使用 git subtree split 或更强大的 git filter-repo 工具来提取相关的提交历史，而不是简单地拷贝文件，这样才能保留有价值的版本记录。
• 补全包配置信息：在每个新仓库的根目录，创建或完善其专属的 composer.json 文件。必须明确声明 name（格式为 vendor/name）、配置正确的 autoload（推荐使用 "psr-4"，且路径应相对于该包的根目录），并只在其 require 部分声明真正的外部依赖，严格避免硬性引用原 Monorepo 中的其他子包。

autoload 配置写错的典型表现

配置错误通常不会直接导致语法报错，而是在运行时暴露问题，比如出现“类找不到”（Class not found）的错误，或者在本地开发与生产环境表现不一致。

• 命名空间与包名不对齐：在子包中错误地配置为 "psr-4": {"App\": "src/"}。正确的做法是让命名空间与包名保持一致。例如，如果包名是 myorg/http-client，那么命名空间可以设置为 "MyOrg\HttpClient\": "src/"。
• 根目录配置残留：拆分后，原 Monorepo 根目录的 composer.json 文件中，如果还保留着对已拆分子目录的 autoload 映射，必须将其删除。否则，执行 composer dump-autoload 时，旧的路径仍会被写入 vendor/composer/autoload_psr4.php 文件，引发冲突。
• 本地开发测试配置不全：在本地使用 path 仓库类型快速测试子包时，如果未在根项目的 composer.json 中设置 "minimum-stability": "dev" 和 "prefer-stable": false，可能会导致执行 composer require myorg/http-client 时，无法找到对应的 dev-main 分支。

发布后怎么让其他项目正确引用？

拆分并配置好包之后，如何让其他项目顺利引用？关键在于包的可发现性和版本稳定性，而不仅仅是 Composer 本身。

• 推送到包仓库：将包推送到 Packagist（公开包）或私有的 Satis/SatisPress 仓库，确保其可被 Composer 发现。同时，包内的 composer.json 中的 version 字段应保持为空，由 Git 标签（tag）来驱动版本识别。
• 使用语义化版本标签：强制使用语义化版本规范为发布打上 Git 标签，例如 git tag -a 'v1.2.0' -m 'release http-client'。没有规范的标签，Composer 将无法将其识别为稳定版本。
• 处理子包间依赖：如果拆分后的子包之间仍然存在协作需求（例如 event-bus 包依赖 http-client 包），那么必须在 require 中指向正式发布的包名和版本约束（如 "myorg/http-client": "^1.2"），绝对不能再引用原 Monorepo 的路径或分支。

最后，还有一个极易被忽略的环节：Git 历史清理。在使用 git filter-repo 等工具后，如果没有彻底清理掉原 Monorepo 历史中的大文件或敏感信息，会导致新仓库体积异常增大、CI 构建速度变慢，甚至可能造成敏感凭证的泄露，这一点需要格外警惕。