pnpm和monorepo

这是我参与2022首次更文挑战的第2天，活动详情查看：2022首次更文挑战」。

1.npm

npm没出现之前 都是通过下载一些压缩过的js包，或者通过别人部署在cdn等线上js压缩包，这样的方式不管是贡献自己的js包，还是引用别人的js包都极其麻烦。没有合适的地方寻找，不能简单的升级版本。

npm出现的好处

• 中央仓库npm服务器收集了大量的依赖包，有较为完善的文档，并且安装简单。
• 用户能够快速升级自己依赖包
• 使用package.json清晰管理到项目所依赖的包及其版本号
• 使用nodemodule形式本地安装依赖，减小了本地依赖压缩js库的大小
• 允许用户将自己编写的包或命令行程序上传到npm服务器供别人使用。

2.yarn

yarn出现解决了npm的痛点：

• 痛点1：npm install会进行顺序安装package.json的包，yarn采用了并行安装，大大提升了安装速度。
• 痛点2：npm每次安装都要重新安装，yarn采用了缓存的方式，同样内容不会重复安装。
• 痛点3:npm之前没有使用lock.json，安装版本混乱，后面npm更新汲取了yarn的lock优点

3.pnpm

3.1为什么要用pnpm?

pnpm的优点：

• 节省磁盘空间
• 速度快 npm和yarn本地如果有100个项目使用了同一个依赖吗，那么每个项目都会有这个依赖的副本，这样一来占用巨大的磁盘空间，二来一个文件升级过后会更改这个副本的全部内容进行重新安装。

使用pnpm，他的方式是100个项目用到一个依赖，他会将不同项目中的版本之间的差异存储在本地类似中央仓库的样子，这样一个依赖包假设有50个文件，两个同依赖但不同版本不会全部修改，只会更改如1个文件的形式，比较完美的解决npm和pnpm的两个缺点

• 安全性 npm安装包的安全性问题，如果 A 依赖 B， B 依赖 C，那么 A 当中是可以直接使用 C 的，但问题是 A 当中并没有声明 C 这个依赖，因此会出现这种非法访问的情况。 pnpm采用的方式是依赖分割 npm安装一个指定依赖包express的node_module目录

pnpm安装的一个指定依赖的node_module目录，全是通过.pnpm做目录结构依赖树，也就是根目录不是平铺的，只显示你所需要那个依赖express（注意根目录的express只是显示，里面仍然没东西）

express所依赖的是不会被展示在根目录的，通过.pnpm里面的关系树软链到真实的代码目录

• 支持monorepo，不用使用繁杂的lerna，直接pnpm通过简单配置进行monorepo,后面我也会更新一篇lerna做monorepo的。

4.monorepo

概念可以简单理解为，之前的代码模式都是一个项目放一个仓库MultiRepo，monorepo就是将多个项目放在同一个仓库的模式，对应到的代码目录为

├── packages
|   ├── A项目
|   |   ├── package.json
|   ├── B项目
|   |   ├── package.json
├── package.json

monoerpo的优点：

1. 代码复用：首当其冲的肯定是代码复用，因为很多项目肯定有通用的代码逻辑，可以提成组件或者通用库，这个时候多处用的地方需要都升级，使用monorepo就可以一次升级多处起效

2. 依赖一致：多个项目依赖的包可以一致性安装，不会出现某个项目版本和其他项目差异巨大，可以更好的管控版本号，比如我要做一个大的基础库，里面有自研请求库，自研工具类，可能都需要dayjs做一个操作，那么安装同一版本dayjs可以完美解决

3. 团队协作：可以规范所有项目的代码规范，目录结构规范，对于基础脚手架这种多个维护的情况能够获得很好的收益，整个生产线都是一致的，便于大家把控项目的更新迭代。

4. 易重构：可以更加原子化的拆分，公司内部的cli就是通过拆分成多个模块，便于各司其职，减小重构的难度。