一分钟入门 Monorepo，确定不看看吗？

为什么 MultiRepo 有局限性

在软件开发过程中，采用 MultiRepo（一个项目一个仓库）的方式存在一些不足之处：

1. 代码复用问题：

   • 多个项目需要复制和维护相同的代码，增加了工作量和风险。
   • 如果将代码抽取为 npm 包，重新发布和安装的步骤繁琐。
   • 多个项目依赖的工具包更新不一致，导致版本管理困难。

2. 基建和部署繁琐：

   • 需要为每个项目建立独立的基础设施、构建流程、部署流程和发布流程，增加了管理和维护成本。

Monorepo 的优势

Monorepo 是将多个项目放置在一个仓库中的方式，具有以下优势：

1. 代码复用和管理：

   • 代码改动可以同步到所有项目，便于代码复用和统一管理。
   • 统一更新代码库可能导致项目 bug，但也提升了对代码的维护和管理效率。

2. 共享基础设施：

   • 可以共享同一套基础设施，简化构建流程，减少重复工作，提高开发效率。

搭建 Monorepo 步骤

初始化项目

在根目录下创建 package.json 文件，并在 packages 目录下放置各个子项目仓库。

以下是一个简单的 Monorepo 项目结构示例：

my-monorepo/
├── package. json
├── pnpm-workspace. yaml
└── packages/
    ├── project1/
    │   ├── package. json
    │   ├── src/
    │   └── ...
    ├── project2/
    │   ├── package. json
    │   ├── src/
    │   └── ...
    └── shared-utils/
        ├── package. json
        ├── src/
        └── ...

在这个示例中：

1. my-monorepo/ 是根目录，包含了主要的项目配置文件。
2. package. json 是根目录下的配置文件，用于定义整个 Monorepo 项目的依赖和脚本。
3. pnpm-workspace. yaml 文件定义了哪些目录下的包被视为 workspace 中的一部分。
4. packages/ 目录是存放各个子项目仓库的文件夹。
5. project1/ 和 project2/ 是两个独立的项目，每个项目都有自己的 package. json 文件和代码目录。
6. utils/ 是一个存放共享工具库的项目，其他项目可以依赖这个工具库进行代码复用。

创建 pnpm-workspace.yaml 文件

packages:
  - 'packages/**'

这个文件定义了哪些目录下的包被视为 workspace 中的一部分。

子项目的配置

• 切换到子项目进行初始化和下载依赖。
• 或者使用 pnpm -f <package_selector> <command> 命令。

# 添加第三方包
pnpm -f @packages/components add lodash
# 添加内部包
pnpm -filter @packages/components add @packages/utils@*

对应子项目的 package.json 会生成配置如下：

{
  "dependencies": {
    "lodash": "^4.17.21",
    "@packages/utils": "workspace:*"
  }
}

参考