什么是Monorepo（单体仓库）(monolithic repository)

背景：多代码仓库存在问题

多代码仓库：将不同的功能模块、组件或服务等分别存放在独立的仓库中，可以单独进行版本控制、构建、部署和发布，使得不同的团队或开发者可以独立地开发、测试和维护各自的模块，更容易实现并行开发和团队协作。

存在问题：

• 跨仓库开发：多仓维护成本高，
  多个仓库之间功能关联紧密时，涉及到跨仓库的开发、联调、合并、发布等操作，流程繁琐。需要频繁在不同仓库间切换上下文，操作复杂。
• 版本管理：依赖版本同步升级管理麻烦
• 项目基建：脚手架升级，新老项目规范很难保证统一

虽然多代码仓库允许每个团队独立管理他们的项目，但同时也阻碍了协作。它们就像眼罩一样，让开发人员只关注自己所拥有的部分，而忽略了整体。

什么是monorepo(monolithic repository)

Monorepo是“单一代码仓库”（Monolithic Repository）的简称.

Monorepo是一种将所有相关项目和组件存储在一个统一代码仓库中的开发与管理策略模式，具有代码复用、版本控制一致、构建流程统一等优点，但也可能面临复杂性和权限管理等问题。

Monorepo（单一代码仓库）作为一种新兴的解决方案，正在成为开发团队的新宠。

在 Monorepo 模式中，所有相关的项目和组件都被存储在一个统一的代码仓库中，而不是分散在多个独立的代码仓库中。

monorepo 是一种将多个项目代码存储在一个仓库里的软件开发策略（mono 意为单一，repo 意为 仓库）。与之相对的是另一种流行的代码管理方式 MultiRepo，即每个项目对应一个单独的仓库来分散管理。

单一代码库的好处

可见性（Visibility）：每个人都可以看到其他人的代码，这样可以带来更好的协作和跨团队贡献。
更简单的依赖关系管理（Simpler dependency management）：共享依赖关系很简单，因为所有模块都托管在同一个存储库中，因此都不需要包管理器。
唯一依赖源（Single source of truth）：每个依赖只有一个版本，意味着没有版本冲突，没有依赖地狱。
共享时间线（Shared timeline）：API 或共享库的变更会立即被暴露出来，迫使不同团队提前沟通合作，每个人都得努力跟上变化。
统一的 CI/CD（Unified CI/CD）：可以为代码库中的每个项目使用相同的 CI/CD[4]部署流程。

Monorepo有哪些缺点

• 性能问题：当仓库的代码规模非常的巨大，达到GB/TB的级别，会增大开发环境的代码git clone、pull成本
• 权限管理问题：项目粒度的权限管理较为困难，github、gitlab权限目前不支持文件夹级别。

优秀案例

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

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

Monorepo 在前端领域确实应用非常广泛，但实际上，Monorepo 方案不仅仅适用于前端项目，在后端、移动、数据、AI、大型基础设施等领域也有很多成功实践。

非前端领域的 Monorepo 成功案例
Google：全公司代码基本都在一个超大 Monorepo 里（包含前后端、基础设施、AI等）。
Meta（Facebook）：不仅 React，几乎所有产品代码都在 Monorepo，包括后端、移动、AI。
微软（Microsoft）：TypeScript、VS Code、Azure SDK 等都采用了 Monorepo。
Uber、Twitter、Airbnb、Shopify、Pinterest、Dropbox、腾讯、字节跳动等也都有大规模 Monorepo 实践。
AI 领域：如 Hugging Face Transformers、OpenAI 的部分项目，常以 Monorepo 管理不同模型和组件。

适用场景

Monorepo 适用场景：

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

MultiRepo 适用场景：

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

你应该使用单一代码库吗?

看情况而定，没有适合所有用例的答案，有些公司可能会暂时选择单一代码库，然后决定需要转向多代码库，或者相反，而其他人可能会选择混合代码库。当你有疑问的时候，考虑一下从单一代码库到多代码库通常比反过来要更容易。但千万不要忽视这一点，最终，这与技术无关，而是与工作文化和沟通有关。所以，根据你想要的工作方式来做决定。