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

为什么 MultiRepo 有局限性

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

代码复用问题：
- 多个项目需要复制和维护相同的代码，增加了工作量和风险。
- 如果将代码抽取为 npm 包，重新发布和安装的步骤繁琐。
- 多个项目依赖的工具包更新不一致，导致版本管理困难。
基建和部署繁琐：
- 需要为每个项目建立独立的基础设施、构建流程、部署流程和发布流程，增加了管理和维护成本。

Monorepo 的优势

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

代码复用和管理：
- 代码改动可以同步到所有项目，便于代码复用和统一管理。
- 统一更新代码库可能导致项目 bug，但也提升了对代码的维护和管理效率。
共享基础设施：
- 可以共享同一套基础设施，简化构建流程，减少重复工作，提高开发效率。

搭建 Monorepo 步骤

初始化项目

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

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

go 复制代码

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

在这个示例中：

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

创建 `pnpm-workspace.yaml` 文件

yaml 复制代码

packages:
  - 'packages/**'

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

子项目的配置

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

shell 复制代码

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

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

json 复制代码

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