关于前端:为什麽前端工程越来越爱使用-Monorepo-架构

作者：HannahLin
起源：medium

有幻想，有干货，微信搜寻【大迁世界】关注这个在凌晨还在刷碗的刷碗智。
本文 GitHub https://github.com/qq449245884/xiaozhi 已收录，有一线大厂面试残缺考点、材料以及我的系列文章。

Monorepository (简称 Monorepo) 概念尽管有一段历史了，但这个名词却是近几年才变得如此热门。本人公司也是这半年才导入这个架构，再尝到许多苦头后想写一篇来介绍它，心愿多一点人意识此架构。这篇并不会有源代码，而是从现有架构痛点开始 (Single Repo Monolith、Multi-repo)、为什麽要用 Monorepo 等等。

现有架构遇到了什麽问题 ?

20 年前的前端相当单纯，但在这 6 ~7 年却产生巨变，当初应该没几个人只用纯 html/css/js 做出网站了，大部分都是以前端框架登程搭配一大堆的 dependencies (SCSS preprocessors、task managers、npm、typescript…)。当团队倒退到肯定规模又会分出好几个不同产品，每一个产品应用的 dependencies 都不大雷同使得保护变得艰难，到底要怎麽做到防止重覆源码以及分好责任归属呢？通过理论例子来介绍一下。

若 shop.com 公司明天有数个专案，每一个专案都有不同负责的团队.

 购物网站 shop.com (React)
结帐 shop.com/cart

购物网站手机版 m.shop.com (不是 RWD，是独立网站)
后盾 admin.shop.com (Vue)
剖析使用者网站 analytics.shop.com (Angular)

Note. 尽管不同专案你能够抉择用不同前端框架，但若都用同一种会看到 monorepo 的更大益处。

shop.com 跟 shop.ocm/cart 尽管是在一个 domain 底下，但负责的却是齐全不同的团队

在这种简单的架构下，咱们比拟相熟的办法为 Monolith 跟 Multi repo [延长浏览: 初探 Micro Frontends 程式架构]

Single-repo Monolith 😰

最开始大家都是应用这种架构开发的，但随著前端工程日益複杂，前端须要做的事越来越多、更多 dependencies 被引入，在 Single-repo Monolith 架构下整包会变超级瘦小，部署时也必须要整包一起，想当然尔 delopy 工夫都爆久，这样的架构毛病很显著，也无奈达到高扩充性与高效率的组织开发。

Single-repo Monolith 
apps
  ├ node_modules
  ├ libs // 放 share 的東西
  ├ design-systems 
  | ├ node_modules
  | ├ xx...
  ├ shop 
  | ├ node_modules
  | ├ cart
  | | ├ xx...
  | ├ xx...
  ├ shop-mobile
  | ├ node_modules
  | ├ xx...
  ├ admin
  | ├ node_modules
  | ├ xx...
  ├ analytics
  | ├ node_modules
  | ├ xx...
  ├ e2e
  | ├ xx...

Multi repo 😢

当初大部分的前端会採用 Multi repo，每一个独立案子都会有绝对应 repo，团队各自保护本人 product，釐清责任也很容易

Design-systems Repository
design-systems
  ├ node_modules  
  ├ e2e
  ├ xxxx
Shop Repository
shop 
  | ├ node_modules
  | ├ e2e
  | ├ xx...
Shop Cart Repository: Cart Cart 因为附属另一个团队所以会拆分成两个 Repository
shop-cart
  | ├ node_modules
  | ├ e2e
  | ├ xx...
Mobile Version Repository
shop-mobile
  | ├ node_modules
  | ├ e2e
  | ├ xx...
Admin Repository
admin
  | ├ node_modules
  | ├ e2e
  | ├ xx...
Analytics Repository
analytics
  | ├ node_modules
  | ├ e2e
  | ├ xx...

看似不错，但问题又来了

重覆配置

Multi repo 因为每一个 repo 都是独立的，所以必须建本人的 webpack、开发环境、如何 deploy 等等，若十个 repo 就要保护这 10 个配置，若 repo 之间都不统一，那治理很麻烦

共用代码保护老本变很高

projects 间许多逻辑是反复的，但因为不同 repo，所以在 debug 时就要一次修五份，保护耗时耗力老本相当高。你可能会想那把会反复用到的货色另外拉进去独自创一个 libs Repository，间接改 libs 得货色即可，那流程就会变成改

• libs Repository，version 从 1.0 到 1.1 2.
• shop、shop-mobile、admin、analytic 装置最新的 libs 1.1
• commit 变动，再 push 更新个自 repo，期待 deploy

这也是 Multi repo 最常被埋怨的事，因为 Repo 被切得太细了，导致只是 share code 小改变流程也超简单，所花工夫也绝对变很高。

dependencies 的版本治理变异样複杂

react 17.0.2 而 shop 还在 15.6，若新版本捨弃某些反对，就会产生 bug。或是因为没有及时 pull 最新的 libs Repo 所以更新不及时而产生 bug。

Mono repo 😊

Mono repo 能够解决下面 Multi repo 的痛点，因为只有一个 Repo 所以治理起来很不便，一个 webpack、一个 test suite runner、共用 dependency 若有变动，那有用到此 dependency 的 project 都会晓得，并且因为只有个 repo 所以大家都是应用最新的 code 不会用更新不及时的情况。

apps
  ├ design-systems
  ├ design-systems-e2e
  ├ shop
  | | ├ cart
  ├ shop-e2e
  ├ shop-mobile
  ├ shop-mobile-e2e
  ├ admin
  ├ admin-e2e
  ├ analytics
  ├ analytics-e2e
node_modules
libs
  ├ utils

libs 上面能够放任何会被共用的货色，例如 design systems、TS Interfaces、JS Utilities 等等。这样架构各自团队是只专一本人的我的项目，例如 shop-mobile team 只会改这个 folder 里的货色，build 时也能够独自跑 shop-mobile only。

尽管 monorepo 是主打 一个 repo，一个 package.json，但本人公司还是会把一些 team specific 的 package 放到本人的 folder 外面，例如很确定只有 design-system 有用到 gatsby。所以这边设置还是能够针对本人公司做调整，但若这个 package 将来很有可能被别的 team 用，最好也是放到最外层。

apps
  ├ design-systems
  | ├ node_modules
  ├ design-systems-e2e

长处

• 对立治理 configs and tests: 因为只有一个 repo 所以不须要再重覆配置环境，包含 CI/CD、unit、e2e、webpack 都只须要保护一份就好
• 部署工夫很快 : 尽管是同一个 repo 但能够针对不同案子设定 CI/CD 个别部署。若 share code 有变动，你不须要 pull request multi-repo 的每一个专案，而是只有去更新有用到此 share code 的案子即可。

• 治理 dependency 变很容易 : 一个 repo，一个 package.json
• 能生蚝利用 share code (libs)
• 编译工夫: 应用 monorepo 编译工夫并不会变慢，因为应用好的 monorepo 工具 (例如 nx) 都帮你做好缓存跟效力优化了

当然，monorepo 还是有一些毛病

• codebase 宏大
• 所有人都能够改变别的 team 的 code: 因为只有一个 repo，但这不是大问题，因为把 code push 下来都须要通过 pull request 审核，若轻易都被 approved 那就是没有治理好了。

❌
// shop.js
import 'adminTools' from 'admin'

想要导入 monorepo，本人是蛮举荐 Nx，官网文件写的很分明也搭配一些视频教程。

总结

当然并不是每一个我的项目都适宜应用 monorepo 治理，还是要针对我的项目内容抉择适合的架构，但总体而言若我的项目够宏大、又有不同团队解决不同我的项目，monorepo 就蛮适宜的

代码部署后可能存在的 BUG 没法实时晓得，预先为了解决这些 BUG，花了大量的工夫进行 log 调试，这边顺便给大家举荐一个好用的 BUG 监控工具 Fundebug。

原文：https://medium.com/hannah-lin…

交换

有幻想，有干货，微信搜寻 【大迁世界】 关注这个在凌晨还在刷碗的刷碗智。

本文 GitHub https://github.com/qq44924588… 已收录，有一线大厂面试残缺考点、材料以及我的系列文章。