主流 Monorepo 框架横评

上一篇顺着"问题→能力"这条链,推演出一张现代 Monorepo 该有的能力清单:严格的依赖布局、受影响分析、任务编排与缓存、发布编排、给人的导航与边界,外加"规模"这个总前提。

这一篇就拿这份清单,逐项去对照市面上几个主流工具——pnpm workspace、Turborepo、Nx、Rush。要先说清楚的是:对照下来你不会得到"某个工具全面胜出"的结论。这几项能力,没有哪个工具能均匀占满;每个工具都是某几项做得很强、某几项留了白或只做了一半的一种分布。所以这篇的产出不是排名,而是一张"能力 × 工具"的对照表,和一套判断——在什么条件下,该优先选哪一个。我个人的答案会收敛到 Rush,但那是一个有前提的选择。

1. 候选工具按能力分层,只有三个值得深评

市面上挂着 "monorepo 工具" 名号的不少:pnpm / Yarn / Bun 的 workspace、Turborepo、Nx、Rush、Lerna,再往极端走还有 Google 系的 Bazel、Meta 系的 Buck2。但它们不在一个层面上,直接摆在一起横评并不公平。用上一篇那个分层先分档——一个工具只做"地基"(安装、链接、依赖解析),还是往上做了"编排"(任务图、缓存、发布):

• pnpm / Yarn / Bun 的 workspace —— 地基层。 只管安装、链接、按包过滤,不提供任务图、内容寻址缓存,也没有成体系的发布编排。其中 pnpm 的严格依赖布局做得最严格,后面会拿它作地基的基准线;Yarn、Bun 是同一档的不同实现,不单独展开。
• Lerna —— 已并入 Nx。 它曾是 JS Monorepo 的代名词,如今归 Nx 团队维护,新版本把任务调度直接委托给了 Nx 引擎,相关能力并到 Nx 讲即可。
• Bazel / Buck2 —— 跨语言、hermetic 的天花板。 所有构建输入被严格声明锁死、任意机器可复现,代价是要用 Starlark 重写整个仓库的构建规则,JS/TS 也不是一等公民。只作极端参照,不进逐项横评。

分层下来,真正站在"编排层"、以 JS/TS 生态为主场、支持一整套现代 Monorepo 能力的,只有三个:Turborepo、Nx、Rush。它们能力覆盖面重叠又各有侧重,后面几节就以这三个为主逐项对照(pnpm 作地基基准线一起看)。

2 到 7 节就按上一篇那张清单的顺序展开,每一项的判据都直接引自上一篇推演出的那个问题,不再逐条回溯。本文还会着重对比 AI 友好度——AI 是这条能力链最新的一环:它需要的"全局可见、上下文自然流动、即时反馈",本质上是在消费前面那些被显式表达出来的结构。既然它已经成了衡量一个 Monorepo 工具的真实维度,这轮就把它当作独立一项来对照。

2. 严格的依赖布局:地基这项,Rush 和 pnpm 并列最强

回到那个正确性问题:幽灵依赖和 NPM 分身。判据是——一个工具能不能保证"每个包只看得见自己显式声明过的依赖",没声明的一律不可见。这一项主要由底层包管理器决定,而不是上层编排工具。

• pnpm workspace —— 满足,而且是标杆。 它用一套基于符号链接的非扁平布局:真实的包存进一个全局内容寻址的仓库,每个包的 node_modules 里只符号链接到它自己声明过的依赖。幽灵依赖在这套布局下跑不起来。
• Rush —— 满足,而且更彻底。 Rush 比 pnpm 更进一步:它连根 node_modules 都不维护,依赖统一安装后由 Rush 收敛、不暴露在全局,再靠符号链接为每个子项目重建一份"只含自己声明依赖"的视图。它还能在收敛时尽量把同一个库锁成单一版本,进一步压掉 NPM 分身。早年我把一个仓库从 yarn 迁到 Rush,最直接的感受就是这套布局的较真:以前随手 import 一个没在自己 package.json 里声明过的 @types/node、lodash,迁过去后全部报"找不到"——它们本就是蹭根 node_modules 得来的幽灵依赖,严格布局一上就现了原形。
• Turborepo / Nx —— 不自己解决这一项,靠底层 PM。 这两个是纯编排层工具,不管依赖安装和链接。你在它们底下配 pnpm,就有 pnpm 那套严格布局;配 npm 的扁平 hoist,幽灵依赖照样存在。它们这一项的强弱,取决于你给它们铺了什么地基,自己不加分也不减分。

不过严格布局能压掉的重复也有边界,别把"收敛版本"想得太满:同一个库,遇到不兼容的 range 依然会并存多份。当一个包要 1.x、另一个要 2.x,再严格的布局也没法把它们合成一份,node_modules 里仍会物理上留下多份;peer dependency、pnpm 的 injected 依赖等场景也一样。严格布局消灭的是"没必要的重复",不是"所有重复"。

这一项的结论:Rush 和 pnpm 并列最强,Rush 在"锁版本、不留全局出口"上更彻底一点;Turbo 和 Nx 完全等于它们底下那层地基。 但门槛其实不算高——只要地基选对了(用 pnpm 而非扁平 npm),这一项基本就有了。真正拉开工具差距的,是往上那几项。

3. 受影响分析:四家都有,这一项拉不开差距

受影响分析(affected):仓库变大后别再全量跑,只处理这次改动真正波及的那部分。判据是——给定一批变更文件,工具能不能沿依赖图算出"哪些包受了影响",从而让 CI 只装、只构建、只测这批。

先说结论:这一项,四家都满足,而且拉不开差距。 affected 的底座是那张下沉到依赖图层的包依赖图,而依赖图是所有这些工具共享的地基;有了图,"从变更包出发反向遍历"是一道确定的题,谁都算得出来。差异只在命令形态:

• pnpm workspace —— pnpm --filter "...[origin/main]" 就能选出"相对某个 git 基线变更了的包及其下游",连地基层都内置了这个能力。
• Turborepo —— turbo run build --affected 自动对比 git 变更,只跑受影响的包。
• Nx —— nx affected -t build 是它的招牌命令之一,基于自己维护的 project graph 算受影响范围。
• Rush —— 用 --to / --from / --impacted-by 这组选择器圈定范围,再叠加增量,只处理目标及其相关项目;要按 git 变更算范围,给选择器传一个 git: 值即可——rush build --to "git:origin/main" 就会挑出相对该基线改动过的项目及其下游,和前三家的 git-diff 检测是同一个思路。早年我在一个上百应用的仓库里就靠 --to 这套语义,把"装依赖+构建"的耗时从"和仓库大小成正比"压到"只和当前项目相关",这是大仓能跑得动的前提之一。

命令各有各的写法,但底层逻辑是同一套图遍历,没有本质高下。这是这几个工具里门槛最低的一项,基本可以看成"标配",不构成选型的区分点。

还要提醒这一项共有的一个软肋:affected 是基于依赖图的启发式剪枝,不是"绝对没有漏网"的正确性证明。运行时反射加载、读约定路径的配置、依赖代码生成的产物——这些没写进 package.json 的隐式依赖,在依赖图上根本不存在,affected 反向遍历时会漏掉它们。四家查的是同一张图,这个软肋因此也一样。

4. 任务编排与缓存:分四层递进,越往上工具越少

任务编排与缓存,对应效率问题的后半截:别重复做已经做过的活。这一项可以拆成四个递进的层次,一个工具能爬到第几层,就反映它做到了多深:

1. 任务图 —— 能不能把构建、测试、打包这些动作建成一张任务依赖图,按拓扑序调度,该并行的并行、该串行的串行。这是缓存的前提:没有任务图,就不知道该缓存哪个任务的产物。
2. 本地缓存 —— 能不能对每个任务的全部输入算内容哈希,命中就直接取上次产物,任务根本不用真跑。
3. 跨机缓存 —— 本地算出来的产物,能不能推到远程存储,让同事和 CI 复用。这是把"个人省时间"变成"团队省时间"的关键一跳。
4. 分布式任务执行(DTE) —— 能不能把一大批任务拆到多台机器上并行跑,再把结果汇总。这是超大仓压 CI 墙钟时间的终极手段。

逐层对照下来:

• pnpm workspace —— 一层都做不到。 它能并行跑脚本,但既没有任务依赖图,也没有内容寻址缓存。这一项,正是编排层工具存在的理由。
• Turborepo —— 前三层做得干净利落。 它以任务图(turbo.json 里的 pipeline / tasks)为核心,本地缓存开箱即用,远程缓存(Remote Cache)可以用官方托管,也可以自建兼容的缓存服务。它的定位就是"把缓存这件事做到最省心"。第四层的分布式执行不是它的主战场,更多靠远程缓存 + CI 并行来逼近。
• Nx —— 四层爬得最高。 任务图 + 本地缓存是基本盘,远程缓存和分布式执行则挂在 Nx Cloud 上:Nx Agents 能把一批任务自动分发到多台机器并行执行、动态分配,是这几家里对第四层(DTE)做得最成体系的。代价是——最完整的那部分能力绑在 Nx Cloud 这个托管服务上。
• Rush —— 四层都具备。 任务图和本地缓存是基本盘;跨机缓存这一层,Rush 的 build cache 既能接本地磁盘,也能接 Azure Blob Storage、Amazon S3 这类云存储(插件化的 cache provider);分布式执行这一层,Rush 有 Cobuilds,靠多台机器共享同一份 build cache、再用 Redis 之类做协调来跑。实现路子和 Nx Agents 那种托管式的动态编排不太一样——Rush 更偏"给你机制,基建自己接",超大规模的分布式构建官方也会引导到微软自家的 BuildXL。

四家的差别更多在风格,不在有没有:Turbo、Nx 把跨机缓存和分布式执行做成了开箱即用的托管服务,Rush 则倾向"给你机制、基建自己接"。所以这一项好不好用,得看你所在的组织有没有自建的构建缓存 / 分布式执行基建——有,Rush 这套"自己接"反而顺手,你本来就会用自己那套;没有、又想要开箱即用的极致缓存,那 Turbo / Nx 会更省心。

但四层不是"越高越好"的排行榜,而是一把按规模用的尺子。单机构建还扛得住的仓库,有前两层(任务图 + 本地缓存)就够了,跨机缓存和分布式执行搭起来、维护起来都是净成本,规模没到,这笔投入回不了本;只有当 CI 墙钟时间被单机拖垮、一次全量构建要几十分钟,后两层才开始划算。所以这一项该怎么选,不取决于哪个工具爬得最高,而取决于你的仓库到底压到了第几层。

5. 发布编排:Rush 的强项,三段式是它的看家能力

发布编排。合仓省掉的是内部依赖间的版本号,却没省掉对外发布——一旦要把某个库发到 npm 给外部用,版本号、changelog、发布顺序一样都不能少;而且几十个包在一个仓库里,一次改动可能同时动好几个,谁跟着发、按什么顺序发,都得有人管。判据就是——框架能不能把这摊事管起来:识别出这一轮该发哪些包、替它们把版本号和 changelog 联动好、再按依赖顺序依次发出去。

这一项是 Rush 的强项:

• Rush —— 满足,而且是内建的看家能力。 Rush 自维护一套三段式:rush change(收集这一轮有哪些变更、每个该升哪一级版本)→ rush version(据此生成 changelog、把相关包版本号 bump 好)→ rush publish(把这一轮涉及的包依次发布出去)。这套流程是 Rush 一开始就当核心功能做的,不是外挂。它和社区 Changesets 的 add → version → publish 是同构的思路——区别在于 Rush 把它做成了内建的、和依赖布局、affected 一整套东西长在一起的能力,不需要你再拼一个第三方工具进来。
• Nx —— 部分满足。 Nx 有 nx release,版本联动和发布都能做,这一项有解。但它的成熟度、以及发布是否严格按拓扑序推进,官方文档我没有查到足够明确的说法,所以这里不下"和 Rush 三段式完全等价"这种绝对结论。
• Turborepo / pnpm workspace —— 都不自带,靠 Changesets。 这两家在发布这件事上是同一处境:自己不提供发布编排,实践中都靠外挂 Changesets 来补。区别只在 Turbo 官方文档直接把这活推给了 Changesets,而 pnpm 是社区约定俗成的组合——但从"工具自带不自带"这个判据看,两家都是"不自带"。

这一项的精度红线,正好落在 Rush 强项的边界上:依赖图本身,算不出一份完整的发布计划。发布顺序看似只是拓扑排序,但拓扑序通常不唯一;更关键的是"哪几个包一起发、版本号怎么联动、要不要带上没直接改动的下游"——这些决策点,依赖图里根本没有答案,只能由团队定的发布策略来补。举个最常见的分歧:一批互相关联的包要发版,是让它们锁同一个版本号、一个包改动就全体一起 bump(前后好对齐,但会发出一堆没实质变化的版本),还是各自独立管版本、只连带发布受影响的上游(版本干净,但联动关系得自己盯)?这两条路没有对错,只有取舍,而依赖图对该走哪条一无所知。发布策略这套取舍本身值得单独讲,留到第 9 节《版本管理哲学》展开;这里只需记住:Rush 的三段式给你的是一套执行发布策略的机制,不是替你做决策的大脑。

也正是在这一项,我想引一句自己早年写 Rush 落地时的判断,拿到今天依然成立:以我个人的经验,到目前为止,没有任何一套发布方案能满足各方需要,每一种都在灵活度和稳定性之间做了自己的取舍。 策略越自动(下游一律跟发、版本一律对齐),越省心,但容易发出一堆没必要的版本;越靠人把关,发出来的版本越干净,但每次都得有人盯着做判断。所以 Rush 的强,强在把"执行"这半边做得扎实、内建、成体系;"决策"那半边没有哪个工具能替你解决,这是发布这件事本身的性质,不是 Rush 独有的短板。

6. 给人的导航与边界:这一项 Nx 是唯一的一等公民

合仓之前,包分散在各自的仓库里,一个仓库拉不到另一个仓库的代码,依赖关系天然被切开;合到一起之后,复用顺了,但这道天然的隔离也没了——任何包都能 import 任何包。这道隔离得由 Monorepo 框架在原地补回来:一是把依赖关系画出来给人看,二是把"谁能依赖谁"写成可检查的规则。判据也就落在这里——框架有没有原生把"依赖可视化 + 边界约束"这两件事做成一等公民。

这一项,Rush 是相对弱的,Nx 是唯一把它当一等公民做的:

• Nx —— 满足,而且是唯一的一等公民。 可视化上,nx graph 在浏览器里打开一张可交互的项目依赖图,谁连着谁一目了然。边界约束上,Nx 有一套完整的机制:给每个项目打 tags,再用 ESLint 规则 @nx/enforce-module-boundaries 的 depConstraints 声明"打了某标签的项目只能依赖打了另一标签的项目",违反就在 lint / CI 阶段报错。可视化 + 可检查的边界规则两件事都原生做齐了,这一项没有对手。
• Turborepo —— 部分。 它能用 turbo run <task> --graph 导出任务依赖图,可视化有一点;但它不提供边界约束规则,想拦越界依赖,得自己配 eslint-plugin-import 的 import/no-restricted-paths 之类的通用规则。
• Rush —— 部分,而且偏弱。 Rush 的选择器能让你探查项目间的依赖关系,但它没有官方的模块边界 ESLint 规则;想要 Nx 那样的边界约束,得靠 rushstack 自带的 eslint 工具或者自己搭一套通用 ESLint 规则 + CODEOWNERS 来补。这一项的边界约束,需要开发者自行补齐,后续章节会单独讲怎么补。
• pnpm workspace —— 基本缺失。 地基层只能给你 pnpm list -r 这种文本依赖树,谈不上图形化导航,更没有边界约束。

不过这些手段有一个共同的性质:它们都是软约束,拦不住铁了心要越界的人。enforce-module-boundaries 再强,也只是在 lint / CI 阶段报错;而当初仓库分开时,越界是根本做不到的——代码就在另一个仓库里,拉都拉不到。合仓换来复用,代价就是这道约束从"做不到"降级成了"做了会被报错",而报错是可以绕的:加一行 disable 注释、或在 CI 里开个豁免就过去了。规则本身(允许谁依赖谁)也是人定的,工具只负责执行。所以这一项各家比的是谁把可视化和规则检查做得更顺手,而合仓前那种"想越界都越不了"的硬性隔离,没有哪家能恢复。

7. AI 友好度:结构 AI 拿不拿得到,以及怎么拿

AI 要在 Monorepo 里干活,靠的正是前面几节沉淀下来的那些结构:project graph、affected 范围、边界规则——读到这些,AI 才清楚谁依赖谁、改一处会波及哪里、哪些依赖是不允许的。所以评估现代 Monorepo 框架,还有一个越来越重要的维度:AI 友好度。

它可以拆成两问,后一问才是关键。第一问,框架沉淀的这些结构,AI 能不能拿到——这一点几乎所有编排工具都做到了,前面几项对照的就是这些结构。第二问,框架有没有把这些结构经一套标准接口主动递给 AI,而不是让 AI 自己去仓库里翻;今天最主流的这套接口就是 MCP(Model Context Protocol)。真正拉开差距的是第二问:有没有官方做好的 MCP 接口。

• Nx —— 满足,而且又是一等公民。 Nx 官方提供了 Nx MCP,把 project graph、任务信息、affected 范围这些它本就维护的结构,经 MCP 直接暴露给 AI。AI 不用自己去猜依赖关系、扒配置,通过标准接口就能拿到一张标注好的图。前面几项它一路做的图化,到这一项正好接上了。
• Turborepo —— 轻量支持。 Turbo 的结构(任务图、affected)也在,生态里也有把它接给 AI 的做法(比如放一份 AGENTS.md、或社区的 MCP 封装);但一套官方、一等公民的 MCP 接口是否成型,我没有查到足够明确的说法,所以这里只说它"轻量、可接"。
• Rush —— 官方有 MCP,但还早。 Rush 官方维护了一个 MCP 服务(@rushstack/mcp-server,由 rushstack 团队发布),能把它沉淀的项目信息、affected 结果经 MCP 递给 agent。但这个包目前还在 0.x(写这篇时是 0.4.x),暴露的能力面比 Nx MCP 那套围绕 project graph 打磨过的接口要窄、要新。所以这一项 Rush 是"有,但还在早期"——比 Nx 那种打磨已久的一等公民差一截,比"完全靠自研"要好。
• pnpm workspace —— 谈不上这一项。 地基层沉淀的结构最少,能给 AI 的也最少。

这一项最后要澄清一个误区:AI 友好,不等于"把一个大仓直接丢给 AI 就行"。恰恰相反,一个没有严格布局、没有 affected、没有边界规则的大仓,只会让 AI 面对一堆理不清的代码无从下手。所以这一项看的从来不是仓库大不大,而是前面那些结构显不显式、接口通不通——它是前面几项的延伸,而不是一项能单独刷高的分。这也解释了 Rush 在这一项的位置:差距的根子不在有没有 MCP 接口,而在它前面在图化、边界上留的白,决定了眼下能经这个接口递给 AI 的结构本就比 Nx 少。

8. 什么条件下选谁

六项对照完,可以把判定收进一张表:

✅ 强 / 🔶 部分或偏弱 / ❌ 缺失 / ⬜ 不由自己决定(取决于底层 PM,故与 affected 那格靠共享依赖图打 ✅ 不同)。

这张表最直接的一个结论:没有哪一列是全绿的。每个工具都是某几项强、某几项留白的一种分布——这不是谁做得不够好,而是这些能力本就分属互相拉扯的取舍方向。缓存和分布式执行要做到极致,最省心的路是托管成云服务,可这就和"不绑单一云厂"直接对立;边界与图化治理要做成一等公民,就得让框架深度介入你的项目结构,可这又和"低侵入、少约束"背道而驰。每一项强都在另一个方向上欠一笔,想同时把六项都推到顶,这些张力就会互相顶牛。所以选型不是"挑最全的那个",而是拿你的规模和诉求,去匹配某一列的形状。

按诉求匹配,选型标准大致是:

• 只想让 CI 跑快、仓库不算太大、诉求集中在缓存 —— 选 Turborepo(搭 pnpm)。 它把任务图 + 缓存这一项做得最省心,配置轻、上手快,发布交给 Changesets。回本门槛最低。
• 要强架构治理、要深度的 AI / 图集成 —— 选 Nx。 它是导航与边界、AI 友好度这两项唯一的一等公民,nx graph + enforce-module-boundaries + Nx MCP 一整套,把"结构显式化"做到了头。代价是最完整的能力绑在 Nx Cloud 上,以及一定的框架侵入性。
• 规模已经大到超大、每天大量对外发包、生态是纯 JS/TS —— 这才轮到 Rush。 下面单独展开。
• 规模顶到跨语言、要求 hermetic 可复现 —— 那是 Bazel / Buck2 的地界了,代价是全仓构建规则重写,JS/TS 不是一等公民。

Nx 和 Rush 不是替代关系,是两条各有主场的路径:Nx 是治理与 AI 友好方向的首选,它把图和边界做成了一等公民;Rush 是严格发包 + 不绑云 + 大仓长期验证方向的首选。选谁,取决于你的主诉求落在哪条路径上,而不是谁"更好"。

最后单独说一下 Rush——前面几项,它在三处不算最省心:跨机缓存和分布式执行走的是"给机制、基建自己接"的路子(第 4 节)、边界约束没有一等公民(第 6 节)、官方 AI 接口还在早期(第 7 节)。既然这样,为什么我个人在特定场景下仍然优先选 Rush?

Rush 的强项集中在一条特定路径上:严格依赖布局做到最彻底(不留全局出口、尽量锁单例)、发布编排内建成体系(三段式)、命令统一且能自定义全局命令、subspaces 能把超大仓拆成多个 lockfile 分治、微软自家的超大仓库长期 self-host 验证、维护活跃(rushstack 仓库至今仍在持续提交)。对应地,它最能发挥的场景也很明确:

• 仓库规模大到单机构建 / 单个 lockfile 已经扛不住、需要 subspaces 拆分;
• 对外发包频繁、需要一套扎实内建的发布编排;
• 严格依赖布局是硬要求而非"有更好";生态是纯 JS/TS,用不上 Bazel 那种跨语言能力。

这组条件同时成立时,Rush 那几项强项的组合,是这几个工具里最合身的。

而更关键的一点是:前面给 Rush 留白的那几项,恰恰在这种规模的团队里,往往已经不再是问题。 一个大到需要 Rush 的组织,通常早就有了自建的构建缓存、分布式执行系统,以及一套自己的 AI 接入基建——这些本就不该指望一个开源 Monorepo 工具开箱提供。Rush 走"给机制、基建自己接"的路子,反而正好接进你现成的那套,而不是逼你迁到某个托管云上。所以那几处留白不是硬伤,而是可以顺着自己的节奏逐步补齐的空位;你真正拿到手的,是布局、发包、subspaces、不绑单一云厂这几项扎实的强项。反过来,如果你没有这些基建、又极度依赖开箱即用的极致缓存和图化治理,那 Rush 的"优先"就不成立,该回到 Turbo 或 Nx。

9. 总结

最后收回到那个总前提:规模。这几个工具,越往上(Nx 的 Cloud、Rush 的全套治理)做得越重,开始划算的规模门槛就越高。所以选型的第一问从来不是"谁功能多",而是 "我到那个规模了吗" ——一个三五个包的项目硬上 Rush,严格布局和发布编排带来的配置成本,大概率盖不过它省下的东西,这时候 pnpm workspace、甚至什么框架都不上,可能才是对的。

工具会变,新的能力项(比如 AI 这一项)还会加进来;但"从问题出发、按诉求匹配分布"这个思路不会过时。

综合来看,Rush 在能力覆盖的完整度和扩展性上更胜一筹,也正是本系列面向的大仓、大团队场景里最合身的一个。所以从下一部分起,后续章节都以 Rush 作为落地的 Monorepo 技术方案展开,其余框架不再逐一铺开——但前面那套"按问题拆能力、按诉求配工具"的分析框架,换成任何一个工具都同样适用。