monorepo
Monorepo是一种项目管理方式，在Monorepo之前，每个项目都对应着一个单独的代码仓库每个项目进行分散管理 这就会导致许多弊端，例如可能每个项目的基建以及工具库都是差不多的，基础代码的重复复用问题等等
一般 Monorepo 的目录如下所示
一般 Monorepo 的目录如下所示，在 packages 存放多个子项目，并且每个子项目都有自己的package.json:
├── packages
| ├── pkg1
| | ├── package.json
| ├── pkg2
| | ├── package.json
├── package.json
- 子包的命名推荐使用：
@<项目名>/<子项目名>
monorepo优缺点
优点
- 复用更加容易，由于所有的项目放在一个仓库当中，复用起来非常方便，如果有依赖的代码变动，那么用到这个依赖的项目当中会立马感知到。并且所有的项目都是使用最新的代码，不会产生其它项目版本更新不及时的情况
- 更好的代码共享：在单个存储库中维护所有代码可以让团队更容易地在项目中共享代码。此外，这也可以帮助团队更好地协调更改，因为所有更改都在同一个地方进行
- 团队协作也更加容易，一方面大家都在一个仓库开发，能够方便地共享和复用代码，方便检索项目源码
- 工程统一标准化: 如果使用多仓库的话，每个团队可能都有各自的一套标准，新建一个仓库又得重新配置一遍工程及 CI / CD 等内容
- **更好的依赖管理：**在单个存储库中维护所有代码可以帮助团队更好地管理依赖关系。例如，如果一个模块依赖另一个模块，可以直接在同一个存储库中引用这两个模块，而不需要通过外部存储库来引用
- **维护性：**可以让团队在一个地方维护所有代码，而不需要将它们分散在许多不同的存储库中
缺点
- 编译时间&依赖安装时间变长
- 可利用pnpm的指定项目依赖的安装 pnpm i -F='packageA'
- git的commit记录会比较混乱，所有人都在同一个仓库进行提交
- 需要指定一套git的标准化 【git hooks、changeLog、version发版等】
- 所有的应用代码必须放到同一个仓库
- 项目数量多起来之后依赖安装时间会很久，项目整体构建时间会变长等等
- 项目隐私性和安全问题，由于所有项目都是同一个仓库，那么这个仓库的所有开发者是可见的，如果希望对某些项目进行细粒度的权限控制，对于单仓库比较难实现
- 如果项目需要做权限操作保密性处理，那么就需要谨慎选择monorepo
monorepo 和 multrepo 区别
monorepo： 是将所有的模块统一的放在一个地方去管理
multrepo： 将项目分化成为多个模块，并针对每一个模块单独的开辟一个reporsitory来进行管理
多仓库依赖升级
monorepo 中不同的包对同一个依赖有多个版本，会导致什么问题？如何解决
- 同一个依赖包作为其他多个不同 Package包 的依赖项时，会导致被拷贝复制很多次。
- 如何通过ppnpm monorepo来解决，因为pnpm是通过软连接的方式，pnpm在 软链接的作用 项目的node_modules这个文件夹中创建符号链接，包之间通过软链接的方式来相互引用依赖包，来复用相同版本的包依赖
workspace理解
workspace工作区间，可以理解为多包存储库
workspace:*- 表示该依赖项属于当前Monorepo中的一个本地包，而非来自远程npm仓库
- Bun在安装依赖时，会自动将
common解析为本地工作区内的对应包 *表示匹配任何版本
"dependencies": {
"common": "workspace:*"
}