本文并不针对仅仅面试，也是对过往遗憾的一段怀念，就是看到新公司选用pnpm，一时有些感慨。
正文
遥想起过往的时候，pnpm的风潮刚刚在社区里走起来，而自己一直没能在老公司推广pnpm。
如今，pnpm在很多公司项目中都通用了，我这个老年人也算是起了个大早，赶了个晚集。
发展史
关于pnpm，yarn，npm三者的发展历史，我这里不详细介绍了，详情可以自己去看：pnpm、npm、yarn 包管理工具『优劣对比』及『环境迁移』 - 掘金 (juejin.cn)。
关于三者的发展历史，无非就是从npm时代有了线上管理的方式，到了yarn时代拍平包依赖，版本锁定，然后被npm抄走。
之后为了解决多项目重复依赖的问题，于是就诞生了pnpm，至于之后会不会被npm抄走，也很难说。
三者现阶段也并非完全的你死我活状态，具体的使用场景，还是要根据自身环境来判断的。
本次不会花时间去讲三者的发展史，而是笔者根据自身经验，简单讲讲使用pnpm的场景。
选用原因
如果你有以下需求，可以考虑选择用pnpm
- 项目node版本不低于v20
- 大型项目，企业级管理系统，项目依赖包很多，且多同类型项目开现场开发，重复使用npm下载依赖包，导致硬盘内存占用过大
- 对npm依赖安装速度不满，且符合以上两个条件
如果您有以上的需求，那就请选择pnpm吧。
之所以pnpm快，就是因为pnpm 内部使用基于内容寻址的文件系统来存储磁盘上所有的文件，这样可以做到不会出现重复安装。
如果你仔细观察的话，你会发现pnpm安装的依赖的node_moudles下边都是快捷方式类型的文件夹。
在项目中需要使用到依赖的时候，pnpm 只会安装一次，之后再次使用都会直接硬链接指向该依赖，极大节省磁盘空间，并且加快安装速度
注：硬链接是多个文件名指向同一个文件的实际内容，而软链接（符号链接）是一个独立的文件，指向另一个文件或目录的路径
首次安装的速度可能较慢，但是后续安装和删除node_moudles都会极快。
注意事项
npm、yarn和pnpm都是当下十分优秀的包管理工具，具体选择哪个，还是要根据团队项目情况和个人喜好来决定。
npm 是 Node.js 生态系统的一部分，yarn 提供了更快的依赖项安装和锁定文件功能，而 pnpm 则专注于减少磁盘空间的使用和安装时间。
| 功能 | pnpm | Yarn | npm |
|---|---|---|---|
| 工作空间支持（monorepo） | ✔️ | ✔️ | ✔️ |
| 隔离的 node_modules | ✔️ - 默认 | ✔️ | ✔️ |
| 提升的 node_modules | ✔️ | ✔️ | ✔️ - 默认 |
| 自动安装 peers | ✔️ | ❌ | ✔️ |
| Plug’n’Play | ✔️ | ✔️ - 默认 | ❌ |
| 零安装 | ❌ | ✔️ | ❌ |
| 修补依赖项 | ✔️ | ✔️ | ❌ |
| 管理 Node.js 版本 | ✔️ | ❌ | ❌ |
| 有锁文件 | ✔️ - pnpm-lock.yaml | ✔️ - yarn.lock | ✔️ - package-lock.json |
| 支持覆盖 | ✔️ | ✔️ - 通过 resolutions | ✔️ |
| 内容可寻址存储 | ✔️ | ❌ | ❌ |
| 动态包执行 | ✔️ - 通过 pnpm dlx | ✔️ - 通过 yarn dlx | ✔️ - 通过 npx |
| 辅助缓存 | ✔️ | ❌ | ❌ |
| 列出许可证 | ✔️ - 通过 pnpm licenses list | ✔️ - 通过插件 | ❌ |
结语
这篇文章本来想多抄点别人整理的发展史，但是想了想，pnpm终归是工具，实在没必要在这种发展史上花太多时间。
而且，面试也很少有人去考你发展史，人家都是直接问你真实的使用经历，所以这里干脆直接捞干的来说。
总之，推荐企业级大型项目开发使用pnpm，尤其是多项目现场部署的那种。
至于个人级别的普通项目，依然推荐按照自己的习惯来做，普通的npm足够覆盖大多数人的普通项目开发需求了。