你好！
系列背景： 这是瓦西娅系列的第10部分。此前的文章涵盖了实体系统、访问控制、API层、数据库抽象层迁移、国际化、测试、部署以及人工智能软件包。
一个无法被安装的框架并不是真正的框架，而只是一个演示。本文将介绍瓦西娅如何从一个所有子软件包都依赖于@dev路径仓库的单一代码仓库（monorepo），转变为在Packagist上各自独立版本化的软件包。
“直接发布就行”有什么问题？
瓦西娅是一个单一代码仓库。根目录下的composer.json文件在packages/目录下定义了43个子软件包，每个子软件包都被引用为带有@dev约束的路径仓库。在开发过程中，这种方式非常方便。Composer会在本地解析所有依赖，你完全不需要考虑版本管理的问题。
但一旦你尝试将根软件包注册到Packagist上，问题就立刻显现出来。Packagist无法解析路径仓库。每个子软件包require块中的"waaseyaa/entity": "@dev"都指向一个本地目录，而这个目录在软件包注册表中并不存在。如果不先发布所有子软件包，根软件包根本无法被发布。
这并非一个简单的元数据修复问题，而是关于单一代码仓库与其使用者之间关系的一项架构决策。
四种策略，一个胜出者
在编写任何代码之前，我们考虑了四种方案。
| 策略 | 首次安装所需时间 | 维护成本 | 使用者体验 |
|---|---|---|---|
| 拆分为独立仓库 | 数周 | 高 — 需要维护43个仓库 | 干净，但开发过程痛苦 |
| 单一仓库 + splitsh-lite | 数天 | 低 — 在打标签时自动拆分 | 安装体验干净，开发仍用单一仓库 |
| 私有Satis注册表 | 数天 | 中等 — 需要自托管注册表 | 需要Satis基础设施支持 |
| Composer元软件包 | 数小时 | 低 | 一次性安装全部内容，缺乏粒度控制 |
splitsh-lite最终胜出，因为它既保留了单一代码仓库作为唯一真实来源，又满足了Packagist的要求：每个软件包拥有独立的代码仓库，各自包含自己的composer.json文件和带标签的发布版本。
开发者的工作流程不会发生任何改变。你仍然在单一代码仓库中工作，仍然从根目录运行测试。代码拆分只是发布阶段需要考虑的问题，而非开发阶段的问题。
splitsh-lite 的工作原理
splitsh-lite会从你的Git历史记录中读取一个子目录，并生成一个新的提交树，其中仅包含该目录的内容。
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
