为什麽前端工程越来越爱使用 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... 已收录，有一线大厂面试完整考点、资料以及我的系列文章。