Monorepo - 理论篇

点击上方 前端Q，关注公众号

回复加群，加入前端Q技术交流群

去年年底，公司进行了部门调整，自己原先做的项目也交给部门内别的科室去做了，做了一年的系统，总有些伤感。

原先是做的是客服系统，主要包含客服、话务、工单和三方四大模块，使用的技术栈包含JQuery、React、Vue2和Vue3。客服系统是单点登录，通过Iframe连接上述四大模块，也算是比较原始的微前端技术。

今年年初被调到其他部门，开始做其他的项目，做的项目是公司ToB的项目，所有的项目都是基于React开发，所有的项目UI也比较统一，并且科室领导也将部门内的很多基于React的项目，基于Monorepo技术重构了一下，以前没接触过该技术，所以专门写写文章来记录Monorepo的学习。

有关Monorepo的知识点还是比较多的，今天主要介绍相关理论。

Monorepo 介绍

Monorepo 是指在一个版本库（repository）中管理多个项目或应用程序的做法。这种做法有助于简化代码管理、提高团队协作效率，并促进代码共享和重用。

在 Monorepo 中，不同的项目或模块可以共享同一个代码仓库，并共享相同的构建、测试和部署工具。这样可以减少重复的配置和管理工作，并且方便进行跨项目的代码重构和共享功能的开发。

Monorepo 通常使用一种工具或框架来管理多个项目或模块之间的依赖关系和版本控制。常见的工具包括 Lerna、Yarn Workspaces 和 Bazel 等。这些工具提供了一些特定的命令和功能，用于管理 Monorepo 中的项目、依赖和版本。

使用 Monorepo 的优势包括：

1. 代码复用性：不同的项目或模块可以共享相同的代码和组件，减少重复开发的工作量。

2. 依赖管理：可以统一管理和更新依赖项，避免版本冲突和依赖问题。

3. 团队协作效率：开发团队可以更容易地协作和共享代码，减少沟通和集成的成本。

4. 统一构建和部署：可以使用相同的构建和部署工具，简化项目的管理和发布流程。

当然，Monorepo 也有一些挑战和适用场景需要考虑。例如，Monorepo 的代码库可能会变得非常庞大，导致构建和部署时间增加。同时，如果项目之间的耦合度较低，或者需要独立维护和发布，那么使用多个独立的代码仓库可能更合适。

Monorepo 演进

Monorepo 的演进可以简单概括为从Monolith（单体应用）到 MultiRepo（多个代码仓库）再到 Monorepo（单一代码仓库）的过程。以下是这一演进过程的详细说明：

1. Monolith（单体应用） ：

• 在单体应用中，所有的代码、功能和组件都存储在同一个代码库中。

• 随着业务复杂度不断提升，项目代码量和复杂度也会逐渐增加。大量代码会降低构建效率，最终可能导致单体巨石应用的出现。

• 这种方法简单直接，适用于小型团队和项目。

MultiRepo（多仓库多模块应用） ：

• 随着项目的增长和团队的扩大，开发团队可能会将不同的功能或组件拆分到单独的存储库中。通过模块解耦，可以降低巨石应用的复杂度。每个模块可以独立进行编码、测试和发布，简化了代码管理，提高了构建效率。

• 每个存储库都有自己的版本控制和依赖管理，使得团队可以更容易地管理和协作。

Monorepo（单仓库多模块应用） ：

• 随着 Monorepo 的兴起，团队将多个项目或组件存储在同一个存储库中。

• 这种方法简化了依赖管理、版本控制和协作，提高了开发效率和代码重用性。

Monorepo vs MultiRepo

下面是 Monorepo 和 MultiRepo 的对比表格：

特征	Monorepo	MultiRepo
存储库数量	单个存储库	多个存储库
依赖管理	统一管理	每个存储库独立管理
版本控制	单个版本控制系统（例如 Git）	每个存储库有自己的版本控制系统（例如 Git）
协作和共享代码	更容易共享代码和组件，促进代码重用	需要显式共享代码和组件，较难实现代码重用
代码一致性	更容易维护一致的代码库	每个存储库可能有不同的代码风格和质量
构建和部署	统一构建和部署流程	每个存储库可能有不同的构建和部署流程
依赖冲突	更容易发现和解决依赖冲突	依赖冲突可能在不同存储库中产生，并且需要额外的管理和解决方案
项目规模和团队规模	适用于大型项目和团队	适用于小型到中型项目和团队
学习曲线	相对较陡峭，需要学习 Monorepo 的最佳实践和工具	相对较平缓，每个存储库都有自己的流程和工具

总的来说，Monorepo 适用于大型项目和团队，它提供了更简单、更统一的管理和协作方式，同时促进了代码重用和一致性。而 MultiRepo 则更适用于小型到中型项目和团队，每个存储库都有自己的独立管理和流程。选择 Monorepo 还是 MultiRepo 取决于项目的规模、团队的需求和开发流程。

Monorepo优劣

Monorepo 模型有许多优点和一些潜在的劣势，以下是它们的一些主要方面：

优点：

1. 统一管理：所有项目和组件都存储在同一个存储库中，使得依赖管理、版本控制和协作更加简单和一致。

2. 代码共享：Monorepo 可以促进代码重用，因为不同项目之间可以更轻松地共享代码和组件。

3. 依赖管理：Monorepo 可以更容易地管理项目之间的依赖关系，减少了依赖冲突和版本不一致的问题。

4. 一致性：由于所有代码都存储在同一个库中，更容易确保代码风格、质量和最佳实践的一致性。

5. 构建和部署：统一的构建和部署流程可以简化开发流程，减少重复工作，并提高整体效率。

6. 可扩展性：对于大型项目和团队来说，Monorepo 提供了更好的可扩展性，因为所有相关代码都可以在同一个存储库中进行管理。

劣势：

1. 学习曲线：对于团队成员来说，可能需要一些时间来适应 Monorepo 模型的工作方式和最佳实践。

2. 存储库大小：随着项目的增长，Monorepo 的存储库可能会变得非常大，这可能会对版本控制和存储/备份造成一些挑战。

3. 权限管理：对于某些项目或组件的访问权限管理可能需要更精细的控制，这可能在 Monorepo 中更加复杂。

4. 构建和部署复杂性：由于所有项目都在同一个代码仓库中，构建和部署过程可能会变得更加复杂和耗时。

总的来说，Monorepo 适合于大型项目和团队，能够带来更好的协作、代码共享和一致性。然而，对于小型项目和团队来说，Monorepo 可能会显得过于复杂和冗余。因此，在选择使用 Monorepo 还是 MultiRepo 时，需要根据具体的项目需求和团队情况做出权衡。

Monorepo 可能存在问题

幽灵依赖

在使用npm或yarn安装依赖时，可能会出现依赖提升的情况，即某个项目使用的依赖并未在其package.json中声明，但仍然可以直接使用，这种现象被称为“幽灵依赖”。随着项目迭代，如果这个依赖不再被其他项目使用，它也不会被安装，导致依赖于该“幽灵依赖”的项目会因找不到依赖而报错。

为了解决这个问题，基于npm或yarn的Monorepo方案可以采用pnpm来彻底解决“幽灵依赖”问题。pnpm是另一种Node.js包管理器，它提供了一种更加智能和高效的依赖管理方式，可以避免“幽灵依赖”问题的发生。通过使用pnpm，即使某个依赖未在package.json中显式声明，也能够被正确安装和管理，从而确保项目的稳定性和可靠性。

因此，对于Monorepo项目来说，采用pnpm作为包管理工具可以有效解决“幽灵依赖”问题，提升项目的开发效率和可维护性。

依赖安装耗时长

在Monorepo中，每个项目都有自己的package.json依赖列表。随着Monorepo中依赖总数的增加，每次进行安装时会耗费较长时间。

为了解决这个问题，可以将相同版本的依赖提升到Monorepo的根目录下，以减少冗余依赖的安装。这样可以避免在每个项目中重复安装相同版本的依赖，从而节省时间并提高安装效率。此外，还可以使用pnpm来按需安装依赖并进行依赖缓存，这将进一步加快安装过程并减少重复下载依赖的时间。

通过这些优化措施，可以显著减少Monorepo项目中依赖安装的耗时，提高开发效率并优化整体开发流程。

原文链接：https://juejin.cn/post/7382430057492512802

往期推荐

VTable 一款高性能的多维数据分析表格，更是一个在行列间创作的方格艺术家家

17个强大的 AI 工具，让你的工作效率翻倍

面试官：如果一个NPM包部分功能不满足需求，如何修改其部分功能~

最后

• 欢迎加我微信，拉你进技术群，长期交流学习...
  

• 欢迎关注「前端Q」,认真学前端，做个专业的技术人...

点个在看支持我吧