共计 3233 个字符，预计需要花费 9 分钟才能阅读完成。
一、窘境频生 前端代码治理何解？
前端代码治理始终是困扰不少前端开发团队的难题，从开发到公布的整体工作流程中，除了惯例的技术问题外，往往还随同着沟通老本、保护老本及合作效率等问题。这些问题在团队规模较小的时候可能不太显著，然而当团队规模变大时就矛盾越发凸显。
数栈前端开发团队负责着离线开发，实时开发，数据服务等多条产品线的开发和保护工作，面对泛滥的产品线，如何正当的治理代码，成了团队须要思考的问题，尽管借助了 Multirepo 进行治理，但还是遇到了许多难题：
● 公有源保护成本增加
为复用相干业务逻辑，团队外部形象出一些公有包，因为不能在公网裸露，为了治理这些公有包团队应用了公有源，但因为搭建公有源服务器资源问题，公有源经常不稳固且下载速度慢，特地是对于须要源码交付的某些客户来说，装置这些公有包更会遇到各种问题，交付的工夫和人力老本大大升高。
● 逻辑难复用，反复造轮子
各个仓库中会形象出同一性能的组件，组件之间的共享往往难以同步，造成了「反复造轮子」等景象。
● 工具 / 配置不对立，沟通老本高
各个仓库所应用的工具和配置没有进行对立，在进行配置更新等的过程中，往往须要同步到各个产品线负责人，沟通老本较高。
这些问题重大拖慢了数栈前端团队从开发到公布的整体流程，同时减少了团队的保护老本和沟通老本，如何寻找新的工具解决这些问题已火烧眉毛，在进行了深刻调研和屡次探讨的过程中，新的项目管理形式 Monorepo 在这时映入了咱们的眼帘。
二、MultirepoVSMonorepo
那么 Multirepo 和 Monorepo 到底是什么呢？其实他们别离代表的是两种前端代码治理形式：
Multirepo
Multirepo 是一种分散式的前端代码治理形式，依照性能或其余维度，将我的项目拆分为不同模块并独自保护于各自仓库中。作为传统的治理形式，Multirepo 具备灵便度高、安全控制等特点，但同时也带了治理老本和写作老本的减少，依赖降级等问题。
Monorepo
Monorepo 是集中式治理的前端代码治理形式，将所有的我的项目在集中一个代码仓库中进行治理，严格的对立和收归，有利于对立的降级和治理。作为新型的治理形式，Monorepo 无效升高了经营及合作老本，但一个代码仓库的管理模式带来了我的项目体积的回升，获取工夫缩短，同时安全性也有所降落。
上图为 Multirepo 和 Monorepo 比照图，从图中咱们能够简要演绎：
- Multirepo 是由多个仓库组成的项目管理形式，每个仓库有着独立的工作流、组件与配置
- Monorepo 则将不同仓库整合成为一个仓库，并共享工作流、组件与配置。
两种治理形式各有千秋，不能简略的定义哪种形式更好，但 Monorepo 的共享机制、对立治理及合作成本低等劣势，显然更合乎深陷简单产品线挑战的数栈前端团队的需要，抉择 Monorepo 也是团队摸索效率晋升的必然路线。
三、适合才最好 Monorepo 计划布局
确定了新的治理形式后，接下来面对的就是如何与数栈相适配的问题。市面上对于 Monorepo 的解决方案和相干工具有很多，尽管 rush、nx 之类的工具可能在特定的畛域提供较好的解决方案，但却并不合乎咱们的理论需要。
在调研了社区的各种 Monorepo 实现和解决方案之后，联合咱们本身的业务场景和需要，最终咱们抉择了 pnpm 和 turborepo 作为底层的包管理工具和任务调度工具，因为只有最合适的产品才是最好的解决方案。
● 包管理工具 -pnpm
在前端社区中，npm、yarn、pnpm 三个包管理工具三足鼎立，而咱们最终抉择了 pnpm 起因在于：pnpm 对 monorepo 有着较好的反对，同时对比其余两个包管理工具，pnpm 在性能等各个方面有着显著的劣势：
● 任务调度工具 -turborepo
任务调度方面，社区中也存在很多优良的工具，如 rush、nx、lerna、turborepo 等，综合比照之后，咱们抉择了配置简略易懂、调度更加迷信的 turborepo 作为咱们的任务调度工具：
四、一直摸索 Monorepo 落地实际
在确定了底层包管理工具和任务调度工具后，数栈 &Monorepo 整体架构计划也就明确了：
Monorepo 解决了之前应用 Multirepo 时存在的问题，帮忙咱们更好的治理代码，接下来咱们将联合 Multirepo 存在的问题来具体阐明 Monorepo 是如何在数栈产品中落地的。
● 对立配置
Multirepo 存在的一个显著问题是配置的不对立导致的难以保护，所以咱们须要对格式化、代码检测、打包等相干流程的配置进行规范化和对立，同时针对不同产品线的细微差别，也须要反对其灵便的扩大。因而咱们在 Monorepo 仓库的根目录提供了对立的根底配置，同时如须要进行调整，不同产品线能够继承该配置并进行必要的批改。
● 逻辑复用
Multirepo 存在的另一个显著问题就是逻辑难以复用，迁徙之前的逻辑复用次要是靠形象到公有包并公布，或者间接复制粘贴，整体效率低，流程长且难以保护。迁徙之后咱们对各种配置等进行了对立的同时，也将专用的业务逻辑和组件整合到了仓库根目录的 packages 目录下，同时通过 pnpm 的 workspace protocal 链接到各个产品线中以复用。这样不仅解决了逻辑复用的相干问题，同时公有源也不必进行保护，Multirepo 下的公有源保护老本问题得以解决。
● 权限校验
当根底配置和公共逻辑被裸露进去之后，就面临着这些内容能够被随便批改的问题，而这往往会影响所有的产品线，稍有不慎会有造成巨大损失，因而咱们须要给这些重要的内容施以限度和爱护。
咱们基于 git hooks 做了一些工作，在 pre-commit 和 pre-push 阶段别离对权限和分支名等内容进行了校验，并定义了 Maintainer、Owner、Deverloper 三个角色，对应的权限别离为：
- Maintainer: 领有全副权限，能够批改包含根底配置文件等的所有内容。
- Owner: 各产品线或者公共组件次要负责人，领有对应范畴内的所有权限。
- Developer: 该产品线或者公共组件的辅助开发人员，只领有包含开发新性能等的局部产品线权限。
角色权限进行明确的划分之后，咱们能够将根底配置和公共逻辑等内容的批改交给更有教训的工程师。同时权限调配配置保护在本地，这样能够更清晰的理解不同产品线对应的人员，不便沟通。
● 自动化迁徙
从 Multirepo 迁徙到 Monorepo 如果采纳手动的形式一一迁徙会有如下问题:
1. 迁徙前的各产品线仓库存在多个版本须要保护，手动迁徙多个版本工作内容反复且效率较低。
2. 人为的操作往往会出错，且出错时沟通老本较高。
因而咱们在迁徙的过程中实现了自动化的迁徙流程，次要流程如下:
1. 主动克隆原仓库的指标分支内容到 Monorepo 删除须要对立的配置如 commitlint 等配置；
2. 删除须要对立的配置如 commitlint 等配置；
3. 删除 babel, webpack 等相干反复依赖；
4. 检测并替换通过 pnpm 的 workspace protocal 链接的外部依赖引入形式；
5. 删除 yarn,npm 相干的 lock 文件，并装置依赖生成最新的 pnpm-lock.yaml.
自动化迁徙的实现，保障了迁徙过程的疾速且顺利的进行，各产品线的同学能够较为平滑的过渡到新的 Monorepo 项目管理形式。
五、写在最初
数栈前端团队在往年上半年正式迁徙到了 Monorepo，解决了之前 Multirepo 项目管理形式下的公有源保护老本较高，工具 / 配置等不对立，逻辑复用链路长且难以保护等问题。在迁徙的过程中，实现了大部分迁徙工作的自动化进行，并对重要的配置等进行了权限校验以进行限度和爱护。整体晋升了数栈前端团队研发的效率，升高了合作和沟通老本，无效实现降本增效。
袋鼠云开源框架钉钉技术交换 qun（30537511），欢送对大数据开源我的项目有趣味的同学退出交换最新技术信息，开源我的项目库地址：https://github.com/DTStack
