用途
Monorepo Management 用于组织与构建多包仓库（monorepo），解决在单一代码库中管理多个相互依赖的包时遇到的构建顺序、依赖版本、变更检测与 CI 效率问题。资料以决策表、配置示例和命令片段的形式给出可操作的做法。
何时使用 Monorepo
资料提供了一张 Monorepo 与 Polyrepo 的对比表，按情况选择：
- 包之间共享库：Monorepo 适合，Polyrepo 不适合。
- 包之间紧耦合：Monorepo 适合。
- 需要独立发布周期：Polyrepo 适合。
- 不同团队、不同节奏：Polyrepo 适合。
- 需要原子化跨包变更：Monorepo 适合。
- 包数量少于 20：Monorepo 适合，Polyrepo 也可。
- 包数量超过 100：视情况而定，Polyrepo 往往更好。
主要能力
JavaScript/TypeScript 工作区
使用 pnpm workspaces 定义包范围，示例 pnpm-workspace.yaml 包含 packages/*、apps/*、tools/*。根 package.json 设为 private: true，并通过脚本调用 turbo 执行 build、test、lint。
典型目录结构包含 packages/（如 ui、config、utils 共享包）、apps/（如 web、api 应用）和 tools/（构建/部署脚本）。内部包引用使用 workspace:* 协议，例如在 apps/web/package.json 中声明 "@myorg/ui": "workspace:*"。
Turborepo 配置与过滤构建
turbo.json 定义任务依赖与输出：build 依赖 ^build 并输出 dist/**、.next/**；test 依赖 build；lint 无输出；dev 为 persistent 且不缓存。
过滤构建命令示例：
turbo build --filter=...[HEAD~1]：只构建受变更影响的包。turbo build --filter=@myorg/web：构建指定包及其依赖。turbo build --filter=...@myorg/ui：构建所有依赖该包的包。
Python Monorepo 模式
资料给出共享虚拟环境方案：根 pyproject.toml 通过 optional-dependencies 引用各子包（core、api、worker）及 dev 依赖，使用 pip install -e ".[all]" 安装。也提到命名空间包（namespace packages），让多个包安装到同一 myorg 命名空间下。
依赖管理
- 版本一致性：使用 syncpack，通过
.syncpackrc的 versionGroups 固定依赖版本（如 react、react-dom 固定为^18.3.0），并用syncpack list-mismatches检查、syncpack fix-mismatches修复。 - 依赖图可视化：
turbo ls --graph或nx graph。
CI/CD 与变更检测
资料提供基于 git diff 的变更检测脚本，以及 GitHub Actions 矩阵构建示例：先 detect-changes 作业输出变更包列表，再以矩阵方式对每个包执行 npm ci && npm run build。
使用方式
按资料示例，先建立工作区配置文件与根 package.json，再定义 turbo.json 任务，随后在子包中声明内部依赖，最后在 CI 中接入变更检测与过滤构建。Python 项目则通过根 pyproject.toml 的 optional-dependencies 统一安装。
适用场景
适用于包之间共享库、紧耦合、需要原子化跨包变更的团队；包数量较少（<20）时尤其合适。包数量超过 100 或需要独立发布周期、不同团队不同节奏时，资料建议考虑 Polyrepo。
限制与反模式
资料列出的反模式包括：缺少任务运行器（手动构建顺序不可扩展，应使用 Turborepo 或 Nx）；循环依赖（包必须构成 DAG，需在 CI 中校验）；所有内容放在一个 package.json（即使在 monorepo 中也应拆分包）；CI 中缺少变更检测（每次提交都全量构建浪费时间）；版本漂移（用 syncpack 等强制一致版本）；隐式依赖（始终显式声明包级依赖）。
关于具体收费、价格、平台支持范围等信息，资料暂未提供。