为什么选择 Monorepo？

随着项目复杂度提升，Node.js 团队越来越倾向于把多套服务、组件库、CLI 工具放在同一个仓库里。Monorepo 的核心价值在于 集中管理依赖与流程，从而让重构、协作、发布都更高效。

Monorepo 的主要收益

维度	收益
依赖管理	`pnpm` 等工具会共享缓存、避免重复安装；严格依赖隔离杜绝“幽灵依赖”
构建效率	借助 Turborepo 的缓存与依赖图，仅构建真正改动的包，CI 时间显著降低
原子提交	一个提交即可跨多个模块同步改动，便于回滚与审计
协作体验	同一仓库统一配置、脚本与规范，减少跨项目跳转和环境差异
可复用性	公共库、UI 组件、工具函数在 workspace 内即可本地引用并共享

与 Polyrepo 的对比

Polyrepo 常见痛点	Monorepo 的解决方式
每个仓库单独装依赖、重复维护脚本	Workspace 共享依赖与脚本，一次配置多处使用
同步多个仓库中的接口或配置	原子提交 + Turborepo 构建，修改一次即可全仓库生效
CI/CD 配置分散、发布流程冗长	基于 changesets 和统一仓库配置快速搭建自动化流水线
大规模重构成本高	搜索范围集中，易于批量修改、验证与回滚

常见落地场景

多端同仓：Web、Server、CLI 共存，代码共享严格受控。
组件库/工具链：公共 API 与内部应用一起维护，避免版本漂移。
微服务集成：多个服务共享协议、类型定义，发布与部署流程统一。
巨石拆分：将原有大型项目拆成多个 package，逐步抽象并复用。

迁移建议

先集中依赖：把最常见的公共依赖和脚本统一到根目录，利用 pnpm workspace 管理版本。
逐步迁移模块：按照业务领域或团队边界迁移子模块，保留原 CI 作为兜底。
引入构建缓存：配置 Turborepo，使用 turbo run <task> --filter=<scope> 控制任务范围。
接入 changesets：在迁移过程中就开始记录版本与变更，养成可发布的节奏。
通过 monorepo.config.ts 定制命令：按团队习惯调整 create 模板、clean 行为、upgrade 目标等，提高可维护性。

进一步阅读

仓库管理实践 —— 如何将 pnpm + Turborepo + monorepo.config 协同使用。
发包与变更日志 —— 使用 changesets 管理版本、自动化发布。
工具专题 —— 常用工具的配置与技巧。
常见思考 —— 关于模块拆分、包结构的经验分享。

Monorepo 不是银弹，但在需要大量复用、自动化、跨团队协作的场景下，它能显著提升工程效率。关键是配合合适的工具与规范，让拆分后的每个模块都有清晰的职责与边界。