罗湖网站建设58,本地电脑做网站服务器,青岛找网站建设公司,wordpress标签数量❌现有的架构可能会遇到什么问题
分散的git仓库
随着时间的沉淀#xff0c;项目数量在飞速增长#xff0c;增加了项目的工程管理难度
怎么区分来源呢#xff1f;
通过git目录划分通过项目命名
新员工入职的时候需要#xff0c;需要下载代码并安装所需的依赖。在这种情…❌现有的架构可能会遇到什么问题
分散的git仓库
随着时间的沉淀项目数量在飞速增长增加了项目的工程管理难度
怎么区分来源呢
通过git目录划分通过项目命名
新员工入职的时候需要需要下载代码并安装所需的依赖。在这种情况下初始设置将很复杂可能会遇到环境不一致在文档通常不完整情况下可能需要寻求帮助。
代码复用
在多个项目间涉及公共组件、公共函数或公共配置如各种config时候代码复用就成了问题。
解决方案
copy 相关代码抽取公共逻辑发布npm包
开发体验
项目开发时
多个 git 仓库管理起来天然是麻烦的。对于功能类似的模块如果拆成了多个仓库无论对于多人协作还是独立开发都需要打开多个仓库页面。
组件开发时
进入 npm 包项目执行 npm link进去 app 应用执行 npm link package调试完成后执行 npm unlink package
工作流
在当前的工作流中每个仓库都需要做一些重复的工程化能力配置如 eslint/prettier/ci 等且无法统一维护当有工程上的升级时需要手动更新所有仓库的配置。
Code Review、Merge Request 从各自模块仓库执行比较割裂。
️什么是 Monorepo
monorepo 是一种将多个项目代码存储在一个仓库里的软件开发策略
Monorepo 能带来什么
统一工作流
首先是 工作流的一致性 由于所有的项目放在一个仓库当中复用起来非常方便如果有依赖的代码变动那么用到这个依赖的项目当中会立马感知到。并且所有的项目都是使用最新的代码不会产生其它项目版本更新不及时的情况对开发调试而言都带来了方便
降低基建成本
其次是 项目基建成本的降低 所有项目复用一套标准的工具和规范无需切换开发环境如果有新的项目接入也可以直接复用已有的基建流程比如 CI 流程、构建和发布流程。这样只需要很少的人来维护所有项目的基建维护成本也大大减低
提升团队协作效率
再者 团队协作也更加容易 一方面大家都在一个仓库开发能够方便地共享和复用代码方便检索项目源码另一方面git commit 的历史记录也支持以功能为单位进行提交之前对于某个功能的提交需要改好几个仓库提交多个 commit现在只需要提交一次简化了 commit 记录方便协作
Monorepo遇到的问题
权限问题
由于单仓的管理模式使用Monorepo将无法简单的控制各个模块代码的访问限制任何有权限访问该仓库的人员将有权限访问所有的代码工程这可能会导致部分安全问题。
性能问题
当仓库的代码规模非常的巨大达到GB/TB的级别会增大开发环境的代码下载成本以及本地硬盘的压力执行git status也可能需要花费数秒甚至数分钟的时间。并且当代码工程很多且活跃数量也很多的情况会加大分支管理策略和各个代码工程版本管理的压力。
Monorepo 方案
考虑使用 turborepo 构建方案 和 pnpm 包管理方案
turborepo 构建方案
TurboRepo 的出现正是解决 Monorepo 慢的问题 多任务并行处理
Turbo支持多个任务的并行运行我们在对多个子包编译打包的过程中turbo会同时进行多个任务的处理
在传统的 monorepo 任务运行器中就像lerna或者yarn自己的内置workspaces run命令一样每个项目的script生命周期脚本都以拓扑方式运行这是“依赖优先”顺序的数学术语或单独并行运行。根据 monorepo 的依赖关系图CPU 内核可能处于空闲状态——这样就会浪费宝贵的时间和资源。 什么是拓扑 拓扑 Topological Order 是一种排序 拓扑排序是依赖优先的术语 如果 A 依赖于 BB 依赖于 C则拓扑顺序为 C、B、A。 比如一个较大的工程往往被划分成许多子工程我们把这些子工程称作活动(activity)。在整个工程中有些子工程(活动)必须在其它有关子工程完成之后才能开始也就是说一个子工程的开始是以它的所有前序子工程的结束为先决条件的 为了可以了解turbo多么强大下图比较了turbovslerna任务执行时间线 turbo它能够有效地安排任务类似于瀑布可以同时异步执行多个任务而lerna一次只能执行一项任务 所以turbo的 性能不言而喻。
增量构建
TurboRepo 的基本原则是从不重新计算以前完成的工作, Turborepo 会记住你构建的内容并跳过已经计算过的内容在多次构建开发时这也就意味更少的构建耗时。
pnpm 包管理方案
pnpm(performant npm)本质上就是一个包管理器这一点跟 npm/yarn 没有区别但它作为杀手锏的优势在于:
解决幽灵依赖包安装速度极快磁盘空间利用非常高效。
解决幽灵依赖
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},
}在 npm1、npm2 中呈现出的是嵌套结构比如下面这样:
node_modules
├── A1.0.0
├── B1.0.0
└── C1.0.0└── node_modules└── D1.0.0这样的设计会存在什么问题
依赖层级太深会导致文件路径过长的问题尤其在 window 系统下。大量重复的包被安装文件体积超级大。比如跟 A 同级目录下有一个 B, 两者都依赖于同一个版本的lodash那么 lodash 会分别在两者的 node_modules 中被安装也就是重复安装。
从 npm3 开始包括 yarn都着手来通过扁平化依赖的方式来解决这个问题
相比之前的嵌套结构现在的目录结构类似下面这样:
node_modules
├── A1.0.0
├── B1.0.0
├── C1.0.0
└── D1.0.0未定义在其 package.json 文件中的D包可以直接被引用到
pnpm 使用符号链接将项目的直接依赖项添加到模块目录的根目录中。
.pnmp 为虚拟存储目录该目录通过 package-nameversion 来实现相同模块不同版本之间隔离和复用由于它只会根据项目中的依赖生成并不存在提升所以它不会存在之前提到的 幽灵依赖问题
node_modules
├── A - .pnmp/A1.0.0
├── B - .pnmp/B1.0.0
└── C - .pnmp/C1.0.0node_modules└── D - .pnmp/D1.0.0速度快
pnpm 安装包的速度究竟有多快先以 React 包为例来对比一下: 可以看到作为黄色部分的 pnpm在绝多大数场景下包安装的速度都是明显优于 npm/yarn速度会比 npm/yarn 快 2-3 倍。
高效利用磁盘空间
当使用 npm 时如果你有 100 个项目并且所有项目都有一个相同的依赖包那么 你在硬盘上就需要保存 100 份该相同依赖包的副本。然而如果是使用 pnpm依赖包将被存放在一个统一的位置因此
如果你对同一依赖包需要使用不同的版本则仅有 版本之间不同的文件会被存储起来。例如如果某个依赖包包含 100 个文件其发布了一个新 版本并且新版本中只有一个文件有修改则 pnpm update 只需要添加一个 新文件到存储中而不会因为一个文件的修改而保存依赖包的 所有文件。所有文件都保存在硬盘上的统一的位置。当安装软件包时 其包含的所有文件都会硬链接自此位置而不会占用 额外的硬盘空间。这让你可以在项目之间方便地共享相同版本的 依赖包。
Monorepo 实践
对于一个新的项目可以运行下面的命令来生成全新的代码仓库
pnpm dlx create-turbolatest
