你知道 monorepo 居然有那么多坑么？（听说干货文章都没人看）

前言

今天文章的话题是 monorepo。在进入正文之前，笔者先来概括下什么是 monorepo 以及本文会从哪几个点来聊聊 monorepo。

monorepo 简单来说就是将多个项目整合到了一个仓库里来管理，很多开源库都采用了这种代码管理方式，比如 Vue 3.0：

从上图我们可以看到 packages 文件夹下存在一堆文件夹，这每个文件夹都对应一个 npm 包，我们把这一些 npm 包都管理在一个仓库下了。

了解 monorepo 的读者肯定听过 lerna，想必也看过不少 lerna 配置相关的文章。本文不会来聊 lerna 该怎么怎么配置，而是主要来聊聊当我们使用 monorepo 后会引入哪些问题？lerna 这些工具链解决了什么问题以及是如何解决的，总的来说将会从以下几点来聊聊 monorepo：

• 对比一下几种代码管理方式的不同处

• 这些代码管理方式各自有什么优缺点，为什么我们会选择 monorepo

• 选择 monorepo 会给我们带来哪些挑战

• 市面上流行的工具链，比如 lerna 是如何帮助我们解决问题的

两种代码管理的方式及优缺点

目前流行的就两种代码管理方式，分别为：

• multi repo

• mono repo

j55G0G

接下来聊聊它们各自的优缺点。

开发

mono repo

✅ 只需在一个仓库中开发，编码会相当方便。

✅ 代码复用高，方便进行代码重构。

❌ 项目如果变的很庞大，那么 git clone、安装依赖、构建都会是一件耗时的事情。

multi repo

✅ 仓库体积小，模块划分清晰。

❌ 多仓库来回切换（编辑器及命令行），项目一多真的得晕。如果仓库之间存在依赖，还得各种 npm link。

❌ 不利于代码复用。

工程配置

mono repo

✅ 工程统一标准化

multi repo

❌ 各个团队可能各自有一套标准，新建一个仓库又得重新配置一遍工程及 CI / CD 等内容。

依赖管理

mono repo

✅ 共同依赖可以提取至 root，版本控制更加容易，依赖管理会变的方便。

multi repo

❌ 依赖重复安装，多个依赖可能在多个仓库中存在不同的版本，npm link 时不同项目的依赖可能会存在冲突问题。

代码管理

mono repo

❌ 代码全在一个仓库，项目一大，几个 G 的话ÿ