概述
不把 Monorepo 当成一堆功能来罗列,而是沿着「问题→能力」的逻辑链,推演出一个现代 Monorepo 必须具备的形态,再拿这张能力清单去量市面上的主流工具。持续迭代中。
市面上讲 Monorepo 的内容,大多停在"是什么、怎么配"。这个系列想往下走一层:把 Monorepo 当成一种组织方式来理解——它为什么会出现,又是如何被一个接一个的现实问题,一步步推到今天这套能力的。
系列的写法是一条因果链:先有一个问题,才有针对它的一项能力;这项能力带来新问题,再引出下一项能力。走完这条链,你不会记住一堆孤立的功能名词,而会得到一张有内在逻辑的能力清单——以及判断"我的场景该用什么"的尺子。
这个系列会讲什么
系列分四部分推进。导论两篇做对比:第一篇沿着能力链,从最原始的发包成本一路推演,回答"为什么会有 Monorepo、它必须具备哪些能力";第二篇拿这张能力清单去逐一评判主流工具(pnpm workspace、Turborepo、Nx、Rush 等),看谁满足了哪几项、又在哪一格上留了白,最后收敛到"什么场景该用什么"。
第一部分落到 Rush:先用一章概述把 Rush 的能力全景铺成一张地图,再顺着"一个数百包的仓从搭起来到跑起来"的顺序逐块深入——rush.json 的显式登记表与单一版本策略、项目选择器与 affected 增量、subspaces 的隔离与复杂度守恒、一组自研插件如何在依赖图变化的源头钉死约束,最后把 Rush 接进 AI 的编码回路。这一部分依据的是一个数百包量级的真实 Rush 仓库的实践。
第二部分是前端工程化在 Monorepo 上的落地,顺着"哲学→机制→度量"展开:先讲依赖与版本这两件事在 Monorepo 下的哲学转变——依赖为什么倾向收敛、版本协商为什么被后移到发布期;再落到 Git 与 CI/CD 的具体门禁;最后把性能与可观测性作为需要持续对抗退化的治理维度收口。
AI 作为一条暗线穿过全程——每一处工程机制,顺带点出它对 AI 协作意味着什么;第三部分单独收束:AI 是加速器,不是新内核,它只放大速度、不改变方向,所以那套对抗熵增的地基一样都不能省。
系列持续迭代中,篇章会陆续补齐。
目录
全系列分四部分,左侧菜单里可逐部分展开。导论两篇先做对比、勾出现代 Monorepo 的模样;之后三部分依次落到 Rush、工程化、AI。目前只有导论两篇成稿,其余标注 WIP,会陆续补齐。