大家好,我是雷布斯。
在前端开发领域,Monorepo(单一代码仓库)是一种越来越常见的代码管理策略。
它将所有相关的代码和项目放在一个集中的代码仓库中管理,而不是分散在多个仓库中。这种方法有许多优点,比如共享代码和组件、简化依赖管理、提升工程效率等优势,在大型团队和复杂项目中推荐使用。
今天就给大家带来一篇介绍 Monorepo 的文章,以下是正文:
去年年底,公司进行了部门调整,自己原先做的项目也交给部门内别的科室去做了,做了一年的系统,总有些伤感。
原先是做的是客服系统,主要包含客服、话务、工单和三方四大模块,使用的技术栈包含JQuery、React、Vue2和Vue3。客服系统是单点登录,通过Iframe连接上述四大模块,也算是比较原始的微前端技术。
今年年初被调到其他部门,开始做其他的项目,做的项目是公司ToB的项目,所有的项目都是基于React开发,所有的项目UI也比较统一,并且科室领导也将部门内的很多基于React的项目,基于Monorepo技术重构了一下,以前没接触过该技术,所以专门写写文章来记录Monorepo
的学习。
有关Monorepo
的知识点还是比较多的,今天主要介绍相关理论。
Monorepo
是指在一个版本库(repository)中管理多个项目或应用程序的做法
。这种做法有助于简化代码管理、提高团队协作效率,并促进代码共享和重用
。
在 Monorepo 中,不同的项目或模块可以共享同一个代码仓库,并共享相同的构建、测试和部署工具。这样可以减少重复的配置和管理工作,并且方便进行跨项目的代码重构和共享功能的开发。
Monorepo 通常使用一种工具或框架来管理多个项目或模块之间的依赖关系和版本控制
。常见的工具包括 Lerna、Yarn Workspaces 和 Bazel 等。这些工具提供了一些特定的命令和功能,用于管理 Monorepo 中的项目、依赖和版本。
使用 Monorepo 的优势包括:
代码复用性
:不同的项目或模块可以共享相同的代码和组件,减少重复开发的工作量。依赖管理
:可以统一管理和更新依赖项,避免版本冲突和依赖问题。团队协作效率
:开发团队可以更容易地协作和共享代码,减少沟通和集成的成本。统一构建和部署
:可以使用相同的构建和部署工具,简化项目的管理和发布流程。当然,Monorepo 也有一些挑战和适用场景需要考虑。例如,Monorepo 的代码库可能会变得非常庞大,导致构建和部署时间增加。同时,如果项目之间的耦合度较低,或者需要独立维护和发布,那么使用多个独立的代码仓库可能更合适。
Monorepo
的演进可以简单概括为从Monolith(单体应用)到 MultiRepo(多个代码仓库)再到 Monorepo(单一代码仓库)
的过程。以下是这一演进过程的详细说明:
Monolith(单体应用) :
MultiRepo(多仓库多模块应用) :
Monorepo(单仓库多模块应用) :
下面是 Monorepo 和 MultiRepo 的对比表格:
特征 | Monorepo | MultiRepo |
---|---|---|
存储库数量 | 单个存储库 | 多个存储库 |
依赖管理 | 统一管理 | 每个存储库独立管理 |
版本控制 | 单个版本控制系统(例如 Git) | 每个存储库有自己的版本控制系统(例如 Git) |
协作和共享代码 | 更容易共享代码和组件,促进代码重用 | 需要显式共享代码和组件,较难实现代码重用 |
代码一致性 | 更容易维护一致的代码库 | 每个存储库可能有不同的代码风格和质量 |
构建和部署 | 统一构建和部署流程 | 每个存储库可能有不同的构建和部署流程 |
依赖冲突 | 更容易发现和解决依赖冲突 | 依赖冲突可能在不同存储库中产生,并且需要额外的管理和解决方案 |
项目规模和团队规模 | 适用于大型项目和团队 | 适用于小型到中型项目和团队 |
学习曲线 | 相对较陡峭,需要学习 Monorepo 的最佳实践和工具 | 相对较平缓,每个存储库都有自己的流程和工具 |
总的来说,Monorepo 适用于大型项目和团队,它提供了更简单、更统一的管理和协作方式,同时促进了代码重用和一致性。而 MultiRepo 则更适用于小型到中型项目和团队,每个存储库都有自己的独立管理和流程。选择 Monorepo 还是 MultiRepo 取决于项目的规模、团队的需求和开发流程。
Monorepo 模型有许多优点和一些潜在的劣势,以下是它们的一些主要方面:
优点:
劣势:
总的来说,Monorepo 适合于大型项目和团队,能够带来更好的协作、代码共享和一致性。
然而,对于小型项目和团队来说,Monorepo 可能会显得过于复杂和冗余
。因此,在选择使用 Monorepo 还是 MultiRepo 时,需要根据具体的项目需求和团队情况做出权衡。
在使用npm或yarn安装依赖时,可能会出现依赖提升的情况,即某个项目使用的依赖并未在其package.json中声明,但仍然可以直接使用,这种现象被称为“幽灵依赖”。随着项目迭代,如果这个依赖不再被其他项目使用,它也不会被安装,导致依赖于该“幽灵依赖”的项目会因找不到依赖而报错。
为了解决这个问题,基于npm或yarn的Monorepo方案可以采用pnpm来彻底解决“幽灵依赖”问题。pnpm是另一种Node.js包管理器,它提供了一种更加智能和高效的依赖管理方式,可以避免“幽灵依赖”问题的发生。通过使用pnpm,即使某个依赖未在package.json中显式声明,也能够被正确安装和管理,从而确保项目的稳定性和可靠性。
因此,对于Monorepo项目来说,采用pnpm作为包管理工具可以有效解决“幽灵依赖”问题,提升项目的开发效率和可维护性。
在Monorepo中,每个项目都有自己的package.json依赖列表。随着Monorepo中依赖总数的增加,每次进行安装时会耗费较长时间。
为了解决这个问题,可以将相同版本的依赖提升到Monorepo的根目录下,以减少冗余依赖的安装。这样可以避免在每个项目中重复安装相同版本的依赖,从而节省时间并提高安装效率。此外,还可以使用pnpm来按需安装依赖并进行依赖缓存,这将进一步加快安装过程并减少重复下载依赖的时间。
通过这些优化措施,可以显著减少Monorepo项目中依赖安装的耗时,提高开发效率并优化整体开发流程。
还没有使用过我们刷题网站(https://fe.ecool.fun/)或者刷题小程序的同学,如果近期准备或者正在找工作,千万不要错过,题库主打无广告和更新快哦~。
老规矩,也给我们团队的辅导服务打个广告。
原文链接:https://juejin.cn/post/7382430057492512802