Monorepo(单仓多模块) 与其他项目开发模式有什么区别？
Monorepo(单仓多模块) 模式中所有相关项目和组件都被存储在一个代码仓库中，彼此之间可以互相依赖， 每个子模块单独构建部署流程。
Monolithic(单体应用) 模式中整个项目由单一代码库组成，构建和部署流程针对整个代码库。
Multirepo(多仓多模块) 模式中项目拆分为多个独立仓库，每个仓库有单独的构建部署流程。
| 特点\模式 | Monorepo | Monolithic | Multirepo |
|---|---|---|---|
| 仓库个数 | 单个 | 单个 | 多个 |
| 构建部署流程 | 单个模块 | 整个项目 | 单个仓库 |
| 代码复用 | 模块之间复用 | 直接调用 | 相同逻辑重写或提取到通用仓库 |
为什么组件库/工具库选用 Monorepo？
其实也该叫为什么不选用 Monolithic(单体应用) 和 Multirepo(多仓多模块)？
monorepo 的优势：
- 方便代码复用，工作流复用
- 模块独立管理
- 分工明确
选用 Multirepo(多仓多模块) 的缺点
当选用这种模式时，可以想象这么一种场景：
view 库依赖 components 组件库
components 组件库依赖 shared 通用方法库
当我们更新 shared 库时，components 组件库和 view 库都要进行依赖更新。
上层包想要得到底层包更改的效果，需要严格逐层升级。
其次，每个包会有很多相似的配置，一旦涉及到整体的修改，需要对多个仓库都进行修改。
选用 Monolithic(单体应用) 的缺点
- 代码维护性差，耦合性强
- 任何小修改必须重新构建整个项目，过程长
- 任何一个功能出现问题，可能导致整个应用挂掉
为什么 pnpm 是 monorepo 的最佳搭配？
npm 与 yarn 的历史遗留问题
- npm 和 yarn 将依赖进行扁平化处理，相同依赖提升到顶层，这需要消耗很多性能，并且依赖是串行安装
- 大量文件重复下载
- 扁平化依赖带来了幽灵依赖的问题(可以访问没有安装的依赖)
pnpm 是如何解决上述问题的？
- 并行安装依赖，其中对每个包 resolving(解析依赖树，决定下载包) -> fetching(并行下载tar包) -> wrting(解压构建依赖树)，同一个包的不同版本只格外存储diff内容。
- 使用硬链接节省磁盘空间，虚拟存储目录+软连接解决幽灵依赖。
