Monorepo

解释

Monorepo（单一代码库）是一种将多个项目存储在同一个代码仓库中的方法。它允许团队在一个统一的代码库中管理多个相关项目，从而简化依赖管理、版本控制和协作。

案例

## 背景
1. 在活动页面的开发中，我们需要维护大量的活动页面，这些页面可能是内嵌在不同app内，
一般来说一个app对应一个项目仓库，但是有些页面可能复用，有些页面内的模块也可能复用。
2. 这些活动页面最初分散不同的仓库中，导致了以下问题：
   - 代码复用困难：要么使用npm管理复用模块，要么直接复制粘贴代码，如果公共代码需要修改
       ，在各个仓库更新也很麻烦。如果某个活动页面需要在不同app内复用，手动再各个仓库中
       复制粘贴代码，容易出错。
   - 标准不统一：不同仓库的代码风格和规范可能不一致，导致协作困难。
   - 页面管理困难：有些页面可能是临时的，过期后需要删除，但分散在不同仓库中很难管理。
   
   
## 解决方案
1. 分支管理：由于协助者较多，在release分支的时候，使用node脚本会检测是否有其他
   未合并的release分支，避免分支遗漏。
2. 一个活动页即作为一个子项目：
   - 每个活动页面作为一个独立的子项目，放在monorepo的`packages`目录下。 
      每个子项目可以有自己的依赖和配置，但共享同一个根目录的依赖。
   - 通过统一的脚本管理构建、测试和发布流程：通过Jenkins参数判断当前是哪个子项目，
      执行对应的子项目构建、测试和发布脚本。
3. 使用CLI脚本，一键生成模版页面，避免代码风格的差异。

## 解决传统的Monorepo的问题
1. 构建和依赖安装时间太久：但是我们只将最公共的依赖放在根目录下，其他子项目的依赖都放在
   子项目目录下，这样可以避免根目录依赖过多导致安装时间过长。
2. 代码冲突：由于公共方法可能被多个子项目使用，导致公共方法修改后可能会影响到其他子项目。
   为了解决这个问题，我们在公共方法的修改时会进行严格的代码审查，并且我们每次修改了代码，
   只发布当前子项目，其他子项目是不会发布的。

## 仍无法解决的问题
1. 代码体积大：git clone时间长
2. 权限问题，如果需要有权限划分，则需要将monorepo拆分成多个仓库。

## 总结
Monorepo适合需要频繁共享代码的项目