Monorepo（单体仓库）与 MultiRepo（多仓库）: Monorepo 单体仓库开发策略与实践指南

在这里插入图片描述

🔥 个人主页：空白诗

在这里插入图片描述

文章目录

- 一、引言
- - 1. Monorepo 和 MultiRepo 简介
  - 2. 为什么选择 Monorepo？
- 二、Monorepo 和 MultiRepo 的区别
- - 1. 定义和概述
  - 2. 各自的优点和缺点
  - 3. 适用场景
- 三、Monorepo 的开发策略
- - 1. 版本控制
  - 2. 依赖管理
  - 3. 构建和发布
  - 4. 代码质量和测试
- 四、实践指南
- - 1. 安装和初始化
  - 2. 配置 pnpm 工作区
  - 3. 创建工作区目录和示例项目
  - 4. 管理依赖
  - 5. 示例项目架构
- 五、结论

一、引言

1. Monorepo 和 MultiRepo 简介

在软件开发中，代码仓库的管理方式对项目的效率和协作有着重要影响。常见的代码仓库管理方式主要有两种：Monorepo（单体仓库）和 MultiRepo（多仓库）。

在这里插入图片描述

Monorepo（单体仓库）：是指将多个项目存储在同一个代码仓库中。这种方式允许不同项目共享代码和依赖，并在同一个版本控制系统中进行管理。
MultiRepo（多仓库）：是指将每个项目存储在独立的代码仓库中，每个仓库独立管理代码和依赖。不同项目之间的代码和依赖需要通过包管理工具或其他方式进行共享。

2. 为什么选择 Monorepo？

选择 Monorepo 的原因主要包括以下几点：

代码共享：在同一个仓库中，项目之间的代码共享更加便捷，减少了重复代码，提高了代码复用率。
一致性管理：可以统一管理依赖、构建和发布流程，确保不同项目的开发环境和工具链的一致性。
简化依赖管理：跨项目的依赖管理变得更加简单，减少了依赖冲突和版本不兼容的问题。
提升协作效率：团队成员可以在同一个仓库中协作，代码审查、问题跟踪和变更管理更加方便。

在许多优秀的开源项目中，Monorepo 方案已经被广泛采用，以下是一些知名的例子：

Babel：一个用于编译 JavaScript 的工具链，通过 Monorepo 管理其各个插件和核心库。
React：Facebook 开发的流行前端库，采用 Monorepo 管理其核心代码、工具和社区插件。
Angular：Google 开发的前端框架，使用 Monorepo 来管理其所有模块、工具和文档。
Vue：尤雨溪开发的前端框架，也采用 Monorepo 管理其核心库、工具和插件。
Nx：一个构建用于企业级 Angular 应用程序的工具，采用 Monorepo 方案来管理其所有插件和工具。
TypeScript：微软开发的 JavaScript 超集语言，使用 Monorepo 来管理编译器、语言服务和社区贡献的工具。

在这里插入图片描述

这篇文章旨在介绍 Monorepo 的开发策略与实践指南，为希望采用或正在采用 Monorepo 管理方式的开发团队提供参考和帮助。文章将详细探讨 Monorepo 的优势和挑战，并分享实际项目中的最佳实践和常见问题解决方案。

二、Monorepo 和 MultiRepo 的区别

1. 定义和概述

Monorepo（单体仓库）：

定义：将多个项目存储在同一个代码仓库中，这些项目共享一个版本控制系统和一个构建系统。
概述：所有代码和依赖都集中在一个仓库中，可以方便地进行统一管理和协调。

MultiRepo（多仓库）：

定义：将每个项目存储在独立的代码仓库中，每个仓库有自己的版本控制系统和构建系统。
概述：每个项目独立管理，项目之间的代码和依赖共享通过包管理工具或其他方式进行。

2. 各自的优点和缺点

Monorepo 的优势与挑战：

优势：
- 代码共享：容易在不同项目之间共享代码和资源，减少重复代码。
- 一致性管理：统一管理依赖、构建和发布流程，确保一致性。
- 协作效率：开发团队可以在同一个仓库中协作，代码审查和变更管理更加方便。
- 依赖管理：跨项目的依赖管理更加简单，减少依赖冲突。
挑战：
- 规模问题：仓库规模较大时，可能导致版本控制系统性能下降。
- 构建时间：随着项目数量增加，构建时间可能变长，需要优化构建流程。
- 权限管理：需要精细化的权限管理，以确保不同项目的访问控制。

MultiRepo 的优势与挑战：

优势：
- 独立性：每个项目独立管理，不受其他项目变更的影响。
- 灵活性：各项目可以选择最适合自己的工具和依赖版本。
- 权限控制：更容易对每个项目进行精细化的权限管理。
挑战：
- 代码共享：在不同项目之间共享代码和资源较为困难，可能导致重复代码。
- 依赖管理：跨项目的依赖管理复杂，需要额外的工具和配置。
- 协作效率：团队成员需要在多个仓库之间切换，可能降低协作效率。

3. 适用场景

Monorepo 适用场景：

大型项目：需要统一管理多个子项目或模块的大型项目。
频繁共享代码：多个项目之间频繁共享代码和资源的情况。
一致性要求高：对依赖、构建和发布流程一致性要求较高的项目。
团队协作：需要高效协作的团队和项目。

MultiRepo 适用场景：

独立性强的项目：各项目相互独立，变更较少影响其他项目。
灵活性需求高：需要为每个项目选择不同的工具和依赖版本。
权限控制严格：需要对每个项目进行精细化权限管理的情况。
规模较小的项目：项目规模较小，不需要频繁共享代码和资源。

三、Monorepo 的开发策略

1. 版本控制

Git 分支策略

主分支（main/master）：用于发布稳定版本的分支，代码应保持高稳定性和可发布状态。
开发分支（develop）：主要开发活动的分支，包含最新的开发代码，定期合并到主分支。
功能分支（feature）：每个新功能或改进的独立分支，从开发分支创建，完成后合并回开发分支。
修复分支（fix/hotfix）：用于紧急修复生产环境问题的分支，从主分支创建，修复后合并回主分支和开发分支。

Commit 规范

Commit 消息格式：使用一致的格式，如 type(scope): description，例如 feat(api): add new endpoint for user data。
类型（type）：如 feat（新功能）、fix（修复）、docs（文档）、style（格式）、refactor（重构）、test（测试）、chore（其他）。
范围（scope）：指明修改的具体模块或组件。

2. 依赖管理

使用工具

Lerna：用于管理 JavaScript 和 TypeScript 项目的 Monorepo 工具，支持版本控制和依赖管理。
Yarn Workspaces：Yarn 的一项功能，允许在 Monorepo 中高效管理依赖，减少重复安装的依赖包。
Nx：一个强大的 Monorepo 管理工具，提供了更高级的依赖分析、构建和测试功能。
pnpm Workspaces：pnpm 提供的 workspace 功能，允许在 Monorepo 中高效管理依赖，并利用硬链接技术减少磁盘空间占用。

如何管理跨项目的依赖

统一版本：确保所有项目使用相同版本的依赖，避免版本冲突。
本地链接：通过工具（如 Lerna、Yarn Workspaces 或 pnpm Workspaces）实现本地依赖的链接，确保项目之间的依赖关系清晰。

3. 构建和发布

持续集成/持续交付（CI/CD）方案

CI 工具：使用 Jenkins、GitHub Actions、GitLab CI 等工具，实现自动化构建和测试。
流水线设计：定义清晰的构建和发布流水线，包括编译、测试、打包、发布等步骤。

自动化发布流程

版本控制：使用语义化版本（Semantic Versioning）管理项目版本。
发布脚本：编写自动化发布脚本，实现从代码合并到发布的全流程自动化。

4. 代码质量和测试

代码审查流程

代码审查工具：使用 GitHub、GitLab 或 Bitbucket 的 Pull Request 功能进行代码审查。
审查标准：定义统一的代码审查标准和最佳实践，确保代码质量。

测试策略

单元测试：为每个模块和功能编写单元测试，确保其独立运行正确。
集成测试：测试项目之间的依赖关系和交互，确保整体系统的正确性。
端到端测试：模拟用户操作，测试整个系统的功能和性能，确保最终用户体验。

通过上述开发策略，可以有效管理和优化 Monorepo 的开发流程，提高代码质量和团队协作效率。

四、实践指南

1. 安装和初始化

全局安装 pnpm

npm install pnpm -g

在项目下进行初始化

pnpm init

得到初始的 package.json

{
  "name": "my-monorepo",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}

修改 package.json 文件
删除 main 这一行以及 scripts 的内容，调整后如下：

{
  "name": "my-monorepo",
  "version": "1.0.0",
  "description": "",
  "scripts": {},
  "keywords": [],
  "author": "",
  "license": "ISC"
}

在 scripts 中后期应当加上 eslint 以及 prettier、commit 等配置，以便于统一代码规范以及格式化信息。

2. 配置 pnpm 工作区

新建 pnpm-workspace.yaml 文件

touch pnpm-workspace.yaml

声明对应的工作区

# pnpm-workspace.yaml
packages:
    # 主包，存放所有项目的目录
    - 'packages/**'
    # 存放组件的目录
    - 'components/*'
    # 组件库使用的示例代码
    - 'examples/*'
    # 存放文档
    - 'docs/**'
    # 存放公共库（配置文件、工具函数、模版等）
    - 'shared/**'

3. 创建工作区目录和示例项目

在根目录创建相应的工作区目录以及示例项目

# 新建 packages 目录
mkdir packages
# 新建 components 目录
mkdir components
# 新建 examples 目录
pnpm create vite examples
# 新建 docs 目录
mkdir docs
# 新建 shared 目录
mkdir shared

4. 管理依赖

将所有项目用到的共同依赖的 dependencies 和 devDependencies 添加到根目录的 package.json 中

在根目录下载依赖到仓库全局锁定，后面创建的项目将沿用这套依赖

pnpm install -w

5. 示例项目架构

root
├── .husky           # Git钩子，自动化代码检查
├── node_modules     # 依赖存放
├── packages         # 各项目或包的集合
│   ├── proj1        # 项目1
│   ├── proj2        # 项目2
│   └── ...          # 其他项目
├── components       # 存放组件的目录
├── examples         # 组件库使用的示例代码
├── docs             # 文档
├── shared           # 存放公共库（配置文件、工具函数、模版等）
├── .cz-config.js    # 提交信息格式化
├── .gitignore       # Git忽略规则
├── .prettierrc.js   # Prettier格式化配置
├── pnpm-workspace.yaml # pnpm工作区配置
└── README.md        # 项目总览