6

为什麽前端工程越来越爱使用 Monorepo 架构？

 2 years ago
source link: https://segmentfault.com/a/1190000041105399
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

作者： 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 的更大好处。

image.png

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

image.png

在这种复杂的架构下，我们比较熟悉的方法为 Monolith 跟 Multi repo [延伸阅读: 初探 Micro Frontends 程式架构]

Single-repo Monolith 😰

image.png

最开始大家都是使用这种架构开发的，但随著前端工程日益複杂，前端需要做的事越来越多、更多 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 😢

image.png

现在大部分的前端会採用 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 😊

image.png

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 的案子即可。

image.png

  • 管理 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... 已收录，有一线大厂面试完整考点、资料以及我的系列文章。


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK