Monorepo
Monorepo（单一代码仓库）是一种软件工程实践，指将多个独立项目、模块或包统一存放在同一个版本控制仓库中进行管理的架构策略。其核心特征包括：代码共享与复用便捷、跨项目的依赖关系统一管理、以及原子性提交可跨模块同步变更。Monorepo常见于大型软件组织，与多仓库（Polyrepo）策略相对，需配合专用构建工具（如Bazel、Nx、Turborepo）以应对规模化带来的构建与协作复杂度。
核心事实
时间轴 (近 90 天)
在 Monorepo 中修改一个包，不会连带触发所有关联项目的构建，未被影响的项目会被自动跳过。
Vercel 调整了 Monorepo 部署策略：被自动跳过的部署不再消耗部署速率限制。
对字段进行一次性全量改名都有风险，更安全的路径是先加新字段、逐个迁移使用方、再删除旧字段，这个顺序比仓库布局更重要。
原文给出的经验法则是观察一次变更需要跨越仓库边界的频率：如果两个项目经常一起改动，放在同一空间能减少协调成本；如果很少联动或因权限、归属原因必须分离，独立仓库更合适。
为每个模块（包括共享模块）明确归属，能预防Monorepo和Polyrepo两种模式下的大部分问题。
Monorepo的典型失败模式是项目间积累不必要的耦合、小改动牵动超出预期的范围；预警信号包括搜索或构建明显变慢、一次改动反复拉入无关团队。
工具质量与仓库结构选择同等重要，工具支持到位的Polyrepo可以胜过缺乏维护的Monorepo。
在Monorepo中修改共享模块可以同步更新所有使用方；在Polyrepo中需要先修改共享模块、发布新版本，再逐个更新调用方。
Monorepo将多个项目的代码放在同一个共享空间中，包括它们共同依赖的共享模块。
许多组织混合使用Monorepo和Polyrepo，例如按业务域各建一个Monorepo，同时把共享库放在独立仓库中。
还有 28 条时间轴事件
全部知识事实 (20)
Vercel AI SDK 采用 monorepo（单一代码仓库）管理模式，核心包与各框架适配包共享同一套 CI/CD 流水线与版本管理工具
90%已验证Vercel AI SDK 采用 Monorepo 单一代码仓库管理模式，核心包 ai 与各框架适配包（如 @ai-sdk/vue、@ai-sdk/react、@ai-sdk/svelte）协同发布
90%已验证AI SDK 采用 monorepo 单一代码仓库管理模式，底层 harness 包变更时上层 workflow-harness 包会跟进补丁版本
85%已验证在 monorepo 中当底层公共包更新时，所有依赖它的子包都需要跟随发布新版本，即使子包自身没有代码改动，这被称为链式发布
80%已验证Monorepo 项目中核心库改动会触发各框架适配包联动更新以保证版本一致性
80%已验证AI SDK采用monorepo加多包发布策略，每个提供商适配器作为独立的npm包发布，拥有各自独立的版本号
80%已验证monorepo 模式下单次发布可能触发大量子包的版本号递增，即便部分包本身并无实质性变更
75%已验证Vercel AI SDK 采用 monorepo 管理模式，各子包之间保持版本号同步
75%已验证在 monorepo 结构的 SDK 中，核心包的 PATCH 更新触发子包同步发布是标准做法
75%已验证在 monorepo 项目中，当共享的底层工具包升级后，依赖它的上层包会随之发布新的补丁版本
75%已验证Monorepo 工具链通常借助 Turborepo（Vercel 自研）或 pnpm workspace 实现增量构建与依赖拓扑排序
75%已验证Changesets 是 monorepo 项目常用的版本管理工具，可自动收集变更说明、计算语义化版本号并同步更新受影响包版本
75%已验证Vercel AI SDK 采用 Monorepo 单一代码仓库管理模式，核心包 ai 与各框架适配包保持协同发布
75%已验证Google和Meta等科技巨头长期采用Monorepo（将多个相关项目放在同一个代码仓库中管理）的策略
75%已验证DeepSeek Harness使用PNPM作为后台插件安装工具
65%待验证大型Monorepo与协作式Agent天然契合，因为Agent可以在统一的代码库上建立全局理解
75%待验证现代开源项目普遍采用Monorepo架构，如使用Turborepo、Nx进行管理
70%待验证在 Monorepo 中修改一个包，不会连带触发所有关联项目的构建，未被影响的项目会被自动跳过。
50%待验证Vercel 调整了 Monorepo 部署策略：被自动跳过的部署不再消耗部署速率限制。
50%待验证对字段进行一次性全量改名都有风险，更安全的路径是先加新字段、逐个迁移使用方、再删除旧字段，这个顺序比仓库布局更重要。
50%