npm workspaces 已经够强了，为何还需要 MonoRepo 方案？

随着项目规模的增长和模块化需求的增强，MonoRepo（单一代码库）的管理方式正在成为热门选择。本文将带领你了解 MonoRepo 的形成背景，探讨主流解决方案（如 pnpm workspaces、TurboRepo、Nx 和 Rush），并通过对比分析这些工具的优劣与适用场景，最终帮助你选择最适合的工具。

MonoRepo 的形成背景

随着项目复杂度和团队规模的扩大，传统的单体代码库或多代码库（PolyRepo）模式逐渐暴露出以下问题：

• 依赖管理复杂： 各项目间共享依赖需要人工管理，更新成本高且容易出错。
• 重复代码和资源浪费： 各项目可能重复实现相同功能，导致资源浪费和维护困难。
• 协作效率低： 跨团队协作难以同步进度，各自为政造成沟通和交付的瓶颈。

为了解决这些痛点，MonoRepo 应运而生。它将多个相关项目放在一个代码库中，提供一致的依赖管理和工具支持，使团队协作和代码复用变得更加高效。

MonoRepo 的优点：

1. 统一依赖管理： 共享依赖和工具链，避免重复安装和版本冲突。
2. 跨项目协作： 项目间可以方便地引用和测试，减少交付时间。
3. 原子化更改： 单次提交可以跨多个模块，确保更改的完整性和一致性。

然而，MonoRepo 也带来了新的挑战，比如如何高效地管理构建任务、优化性能、以及避免依赖关系复杂化。因此，适合 MonoRepo 的工具解决方案应运而生。

用一个场景来比对目前主流解决方案的差异

场景概述

假设我们有一个MonoRepo 工程。 整体工程结构如下。

my-monorepo/
├── package.json         # 根目录
├── packages/
│   ├── lib-a/           # 公共库，提供基础功能
│   │   ├── src/
│   │   └── package.json
│   ├── app1/            # 应用1，依赖 lib-a
│   │   ├── src/
│   │   └── package.json
│   └── app2/            # 应用2，依赖 lib-a
│       ├── src/
│       └── package.json

如果，我们修改了 app1 和 app2 的依赖库 lib-a 。 那么，我们在运行 app1 或者 app2 的时候， 需要先运行 lib-a 在运行，具体工程。 如果，没有变动，则直接运行app1 或 app2.

使用 PNPM workspaces

1. 安装依赖

pnpm install 

由于 pnpm 的特性， packages 下所有工程的共有依赖，通过符号链接链接到全局缓存。

1. 运行构建任务

    pnpm recursive run build

• 运行所有子项目的 build 脚本，但无法自动跳过未修改的模块。
• 构建顺序需人工保证正确，无法根据依赖关系自动调整。

优点：

简单直接，适合小型项目。

使用全局缓存优化安装速度和磁盘利用率。

子项目依赖不会污染其他项目。

缺点:

无法基于任务依赖关系优化执行顺序或跳过未修改模块。

只能适用于比较简单，轻量级的项目。

使用 TurboRepo

TurboRepo 是由 Vercel 推出的现代化 MonoRepo 工具，专注于任务调度和构建优化。

1. 配置工程

在项目根目录创建 `turbo.json`：

{
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**"]
    }
  }
}

1. 运行构建任务

turbo run build

• TurboRepo 会自动分析依赖关系，确保 lib-a 构建在前。
• 如果 lib-a 没有修改，TurboRepo 会利用缓存跳过构建，直接运行 app1 和 app2 的任务。

优点：

• 自动依赖管理，任务按顺序执行。
• 支持结果缓存，大幅提升效率。

缺点：

• 对大型项目的任务调度和可视化支持较弱。

使用 Nx 解决

Nx 是一款功能强大的 MonoRepo 工具，提供了任务调度、依赖分析和可视化支持。 前 MonoRepo 解决方案 lerna 的收购方。

安装和初始化：

npx create-nx-workspace@latest my-monorepo

生成依赖图：

nx graph

自动生成可视化依赖图，展示 lib-a 和应用之间的关系。

运行构建任务：

nx run-many --target=build --all

• Nx 会根据依赖关系自动调整执行顺序。
• 支持本地和分布式缓存，跳过未修改的模块任务。

优点：

• 提供依赖可视化工具，任务管理更加直观。
• 分布式缓存适合团队协作。

缺点：

• 配置稍显复杂，对上手要求较高。

使用 Rush 解决

Rush 是 Microsoft 为企业级项目设计的 MonoRepo 工具，专注于复杂依赖和构建管理。

初始化项目：

# 在根目录下， 执行 rush init 初始化
rush init

定义构建流程：

在 rush.json 中配置依赖和任务：

{
  "projects": [
    {
      "packageName": "lib-a",
      "projectFolder": "packages/lib-a"
    },
    {
      "packageName": "app1",
      "projectFolder": "packages/app1",
      "dependencies": ["lib-a"]
    },
    {
      "packageName": "app2",
      "projectFolder": "packages/app2",
      "dependencies": ["lib-a"]
    }
  ]
}

运行构建任务：

rush build

• Rush 会严格按照依赖顺序执行任务，避免构建出错。
• 内置支持结果缓存和高效的 CI/CD 集成。

优点：

• 企业级功能强大，适合超大型团队协作。

缺点：

• 配置复杂，上手门槛高。

整体对比

工具	依赖分析	缓存支持	构建优化	配置难度	适用场景
pnpm workspaces	无	本地缓存	无依赖优化	简单	小型项目
TurboRepo	自动	本地缓存	增量构建	简单	中小型项目
Nx	强大	本地/分布式缓存	可视化依赖分析	适中	中大型项目
Rush	强大	分布式缓存	高效任务调度	较高	超大型项目，企业级团队

总结

通过例子我们可以看出，不同的 MonoRepo 工具在依赖分析、任务调度和缓存支持上的能力差异显著：

1. 轻量化选择：

   • pnpm workspaces 适合简单项目和个人开发者，易于上手但功能有限。

2. 构建速度优先：

   • TurboRepo 在任务缓存和增量构建方面表现出色，适合中小型项目。

3. 团队协作：

   • Nx 提供依赖图和分布式缓存功能，适合协作频繁的中大型团队。

4. 企业级复杂场景：

   • Rush 是企业项目的最佳选择，支持超大规模项目和严格的依赖管理。

最终，选择工具时需要综合考虑项目规模、团队需求和未来扩展规划，找到最适合的 MonoRepo 解决方案。希望本文的实例和对比能够为你的选型提供启发！