Monorepo

❌现有的架构可能会遇到什么问题

分散的git仓库

随着时间的沉淀,项目数量在飞速增长,增加了项目的工程管理难度

怎么区分来源呢?

  • 通过git目录划分
  • 通过项目命名

新员工入职的时候需要,需要下载代码并安装所需的依赖。在这种情况下,初始设置将很复杂(可能会遇到环境不一致),在文档通常不完整情况下,可能需要寻求帮助。

代码复用

在多个项目间涉及公共组件、公共函数或公共配置(如各种config)时候,代码复用就成了问题。

解决方案:

  • copy 相关代码
  • 抽取公共逻辑发布npm包

开发体验

项目开发时

多个 git 仓库管理起来天然是麻烦的。对于功能类似的模块,如果拆成了多个仓库,无论对于多人协作还是独立开发,都需要打开多个仓库页面。

组件开发时

  1. 进入 npm 包项目,执行 npm link
  2. 进去 app 应用,执行 npm link package
  3. 调试完成后,执行 npm unlink package
    在这里插入图片描述

工作流

在当前的工作流中,每个仓库都需要做一些重复的工程化能力配置(如 eslint/prettier/ci 等)且无法统一维护,当有工程上的升级时,需要手动更新所有仓库的配置。

Code Review、Merge Request 从各自模块仓库执行,比较割裂。

️什么是 Monorepo

monorepo 是一种将多个项目代码存储在一个仓库里的软件开发策略
Monorepo_第1张图片

Monorepo 能带来什么

统一工作流

首先是 工作流的一致性 ,由于所有的项目放在一个仓库当中,复用起来非常方便,如果有依赖的代码变动,那么用到这个依赖的项目当中会立马感知到。并且所有的项目都是使用最新的代码,不会产生其它项目版本更新不及时的情况,对开发调试而言都带来了方便

降低基建成本

其次是 项目基建成本的降低 ,所有项目复用一套标准的工具和规范,无需切换开发环境,如果有新的项目接入,也可以直接复用已有的基建流程,比如 CI 流程、构建和发布流程。这样只需要很少的人来维护所有项目的基建,维护成本也大大减低

提升团队协作效率

再者, 团队协作也更加容易 ,一方面大家都在一个仓库开发,能够方便地共享和复用代码,方便检索项目源码,另一方面,git commit 的历史记录也支持以功能为单位进行提交,之前对于某个功能的提交,需要改好几个仓库,提交多个 commit,现在只需要提交一次,简化了 commit 记录,方便协作

Monorepo遇到的问题

权限问题

由于单仓的管理模式,使用Monorepo将无法简单的控制各个模块代码的访问限制,任何有权限访问该仓库的人员将有权限访问所有的代码工程,这可能会导致部分安全问题。

性能问题

当仓库的代码规模非常的巨大,达到GB/TB的级别,会增大开发环境的代码下载成本,以及本地硬盘的压力,执行git status也可能需要花费数秒甚至数分钟的时间。并且,当代码工程很多且活跃数量也很多的情况,会加大分支管理策略和各个代码工程版本管理的压力。

Monorepo 方案

考虑使用 turborepo 构建方案 和 pnpm 包管理方案

turborepo 构建方案

TurboRepo 的出现,正是解决 Monorepo 慢的问题

Monorepo_第2张图片

多任务并行处理

Turbo支持多个任务的并行运行,我们在对多个子包,编译打包的过程中,turbo会同时进行多个任务的处理

在传统的 monorepo 任务运行器中,就像lerna或者yarn自己的内置workspaces run命令一样,每个项目的script生命周期脚本都以拓扑方式运行(这是“依赖优先”顺序的数学术语)或单独并行运行。根据 monorepo 的依赖关系图,CPU 内核可能处于空闲状态——这样就会浪费宝贵的时间和资源。

什么是拓扑 ? 拓扑 Topological Order 是一种排序 拓扑排序是依赖优先的术语, 如果 A 依赖于 B,B 依赖于 C,则拓扑顺序为 C、B、A。

比如一个较大的工程往往被划分成许多子工程,我们把这些子工程称作活动(activity)。在整个工程中,有些子工程(活动)必须在其它有关子工程完成之后才能开始,也就是说,一个子工程的开始是以它的所有前序子工程的结束为先决条件的

为了可以了解turbo多么强大,下图比较了turbovslerna任务执行时间线:

Monorepo_第3张图片

turbo它能够有效地安排任务类似于瀑布可以同时异步执行多个任务,而lerna一次只能执行一项任务 所以turbo的 性能不言而喻。

增量构建

TurboRepo 的基本原则是从不重新计算以前完成的工作, Turborepo 会记住你构建的内容并跳过已经计算过的内容,在多次构建开发时,这也就意味更少的构建耗时。

pnpm 包管理方案

pnpm(performant npm)本质上就是一个包管理器,这一点跟 npm/yarn 没有区别,但它作为杀手锏的优势在于:

  • 解决幽灵依赖
  • 包安装速度极快;
  • 磁盘空间利用非常高效。

解决幽灵依赖
Monorepo_第4张图片

package.json
// project
{
  "name": "test",
  "version": "1.0.0",
  "main": "lib/index.js",
  "dependencies": {
    "A": "1.0.0",
		"B": "1.0.0",
		"C": "1.0.0"
  },
}

// c package
{
  "name": "C",
  "version": "1.0.0",
  "main": "lib/index.js",
  "dependencies": {
		// "A": "2.0.0",
    "D": "1.0.0"
  },
}

npm1npm2 中呈现出的是嵌套结构,比如下面这样:

node_modules
├── [email protected]
├── [email protected]
└── [email protected]
  └── node_modules
    └── [email protected]

这样的设计会存在什么问题:

  1. 依赖层级太深,会导致文件路径过长的问题,尤其在 window 系统下。
  2. 大量重复的包被安装,文件体积超级大。比如跟 A 同级目录下有一个 B, 两者都依赖于同一个版本的lodash,那么 lodash 会分别在两者的 node_modules 中被安装,也就是重复安装。

从 npm3 开始,包括 yarn,都着手来通过扁平化依赖的方式来解决这个问题

相比之前的嵌套结构,现在的目录结构类似下面这样:

node_modules
├── [email protected]
├── [email protected]
├── [email protected]
└── [email protected]

未定义在其 package.json 文件中的D包,可以直接被引用到

pnpm 使用符号链接将项目的直接依赖项添加到模块目录的根目录中。

.pnmp 为虚拟存储目录,该目录通过 @ 来实现相同模块不同版本之间隔离和复用,由于它只会根据项目中的依赖生成,并不存在提升,所以它不会存在之前提到的 幽灵依赖问题!

node_modules
├── A -> .pnmp/[email protected]
├── B -> .pnmp/[email protected]
└── C -> .pnmp/[email protected]
		node_modules
		└── D -> .pnmp/[email protected]

Monorepo_第5张图片

速度快

pnpm 安装包的速度究竟有多快?先以 React 包为例来对比一下:

Monorepo_第6张图片

可以看到,作为黄色部分的 pnpm,在绝多大数场景下,包安装的速度都是明显优于 npm/yarn,速度会比 npm/yarn 快 2-3 倍。

高效利用磁盘空间

当使用 npm 时,如果你有 100 个项目,并且所有项目都有一个相同的依赖包,那么, 你在硬盘上就需要保存 100 份该相同依赖包的副本。然而,如果是使用 pnpm,依赖包将被存放在一个统一的位置,因此:

  1. 如果你对同一依赖包需要使用不同的版本,则仅有 版本之间不同的文件会被存储起来。例如,如果某个依赖包包含 100 个文件,其发布了一个新 版本,并且新版本中只有一个文件有修改,则 pnpm update 只需要添加一个 新文件到存储中,而不会因为一个文件的修改而保存依赖包的 所有文件。
  2. 所有文件都保存在硬盘上的统一的位置。当安装软件包时, 其包含的所有文件都会硬链接自此位置,而不会占用 额外的硬盘空间。这让你可以在项目之间方便地共享相同版本的 依赖包。

Monorepo 实践

对于一个新的项目,可以运行下面的命令来生成全新的代码仓库

pnpm dlx create-turbo@latest

你可能感兴趣的:(前端,npm)