[PNPM] 其他包管理器

Yarn

Yarn 这个包管理器是在 2016 的时候由 Facebook、Google、Exponent 以及 Tilde 团队共同开发推出的。

当时 Yarn 的出现主要是为了解决 npm 在速度、安全性以及一致性方面的一些问题：

• 安装速度

• 确定性：

  • 项目A ---> 直接依赖： libraryX（1.0）-----> 间接依赖：libraryY（1.3）
  • 项目A ---> 直接依赖： libraryX（1.0）-----> 间接依赖：libraryY（2.0）
  • Yarn 引入了一个 yarn.lock 锁文件

• 安全性

• 离线安装

指令对比：

npm	Yarn	说明
npm init	yarn init	初始化项目
npm install/link	yarn install/link	默认的安装依赖操作
npm install <package>	yarn add <package>	安装某个依赖
npm uninstall <pacakge>	yarn remove <package>	移除某个依赖
npm install <package> --save-dev	yarn add <pacakge> --dev	安装开发依赖
npm update <package> --save	yarn upgrade <package>	更新某个依赖
npm install <package> --global	yarn global add <pacakge>	全局安装
npm publish/login/logout	yarn publish/login/logout	发布/登录/登出
npm run <script>	yarn run <script>	执行 script 命令

Yarn 的出现让 npm 团队也感受到了压力，做出了一定的改变。

例如从 npm v5 开始引入了名为 package-lock.json 的锁文件，类似于 Yarn 的 yarn.lock 文件。这确保了在不同环境中的依赖结构一致性。

思考🤔：package.json 和 package-lock.json 都是 npm 用于管理项目依赖的文件，两者有什么不同呢？

答案：package.json包描述文件，会包含直接依赖以及元数据信息，package-lock.json 包含所有的依赖信息（包含直接依赖和间接依赖）。

pnpm

在 Yarn 之后，又出现了 pnpm包管理器

pnpm 的优势主要表现在这么 3 个地方：

1. 节省磁盘空间
2. 解决幽灵依赖
3. 原生支持Monorepo

1. 节省磁盘空间

使用 npm 时，如果你有 100 个项目都使用同一个依赖项，你会在磁盘上保存该依赖项的 100 份副本。而使用 pnpm，依赖项会存储在一个内容可寻址的存储中。

pnpm中有两个比较重要的概念：

• 硬链接
• 符号链接

硬链接

是指多个文件名指向同一个物理文件数据块。这意味着，无论你通过哪个硬链接访问文件，看到的内容都是相同的。删除一个硬链接不会影响其他硬链接，只有当所有硬链接都被删除后，文件数据才会真正从硬盘中移除。

符号链接

符号链接是一个特殊的文件，包含了指向另一个文件或目录的路径。它类似于快捷方式，访问符号链接时，操作系统会将其重定向到实际文件或目录。符号链接本身占用少量空间，但它指向的文件或目录仍然占据实际存储空间。

在 pnpm 中，直接依赖使用硬链接，而间接依赖使用符号链接。下面来做一个和 npm 安装包的对比：

两个项目 ProjectA 和 ProjectB，它们都依赖同一个库 libraryX。

传统的 npm 安装方式

ProjectA 和 ProjectB 都会在各自的 node_modules 文件夹中创建一个独立的 libraryX 目录，并且这些目录里包含了相同的文件内容。即使 libraryX 的版本完全相同，它们仍然会各自占用磁盘空间。

# 安装依赖
cd ProjectA
npm install libraryXcd ../ProjectB
npm install libraryX# 结果:
# ProjectA/node_modules/libraryX/ -> 这是一个完整的libraryX文件
# ProjectB/node_modules/libraryX/ -> 这是另一个完整的libraryX文件

这样，libraryX 的文件在磁盘上被重复存储了两次，即使它们的内容完全一样。

pnpm 使用硬链接的方式

当你使用 pnpm 安装 libraryX 时，pnpm 会将 libraryX 的文件存储在一个全局的内容地址存储（例如 ~/.pnpm-store）中，而不是在每个项目中都完整复制一份。

然后，pnpm 会为 ProjectA 和 ProjectB 中的 libraryX 创建硬链接。硬链接指向全局存储中的同一个物理文件，因此即使在 ProjectA 和 ProjectB 中都有 libraryX 的文件，这些文件在磁盘上只存储了一次。

# 使用 pnpm 安装依赖
cd ProjectA
pnpm install libraryXcd ../ProjectB
pnpm install libraryX# 结果:
# ~/.pnpm-store/libraryX/ -> 这是libraryX的实际物理文件，存储在全局内容地址存储中
# ProjectA/node_modules/libraryX/ -> 这是指向全局存储的硬链接
# ProjectB/node_modules/libraryX/ -> 这是另一个指向全局存储的硬链接

符号链接的使用

pnpm 在处理间接依赖时，会使用符号链接。

例如，假设 libraryX 本身依赖 libraryY，而 libraryY 也存储在全局内容地址存储中。此时 pnpm 会在 libraryX 中创建一个符号链接，指向全局存储中的 libraryY，而不是将 libraryY 的文件直接复制到 libraryX 中。这进一步减少了文件的重复存储。

# 符号链接示例:
# ProjectA/node_modules/libraryX/node_modules/libraryY -> 这是一个符号链接，指向全局存储中的libraryY

思考🤔：如果不同的项目依赖同一个包（libraryX）的不同版本，应该怎么处理？

答案：在全局仓库下分别存储每个版本的 libraryX. 但是这里有一个优化，仅存储不同版本之间不同的文件。

实战演练

使用 pnpm create vue@latest 命令分别创建两个 Vue 项目，查看依赖结构。

pnpm store path

2. 解决幽灵依赖

所谓幽灵依赖，是指当一个包（A）依赖于另一个包（B）时，后者会被放置在前者的 node_modules 目录中。这意味着一个包可能会意外地访问并使用另一个包的依赖，即使它没有在自己的 package.json 文件中声明这些依赖。

实战演练

演示 npm 和 pnpm 对于幽灵依赖的处理。

幽灵依赖会存在的问题：

1. 难以理解的依赖关系
2. 潜在的错误

3. 原生支持Monorepo

目前企业中搭建 Monorepo 项目方案，常见有这么几种：

1. Lerna
2. Yarn + Workspace
3. pnpm + Workspace

4. 相关指令

• 安装 pnpm：可以使用 npm 或者 yarn 进行安装，npm install -g pnpm
• 创建新项目：pnpm init
• 添加依赖：pnpm add <package>
• 添加所有依赖：pnpm install
• 升级依赖：pnpm update <package>
• 删除依赖：pnpm remove <package>

包的隔离和提升

这是一张来自于 pnpm 官方给出的和其他包管理器之间的 对比图，如下：

pnpm 默认策略是包隔离，老牌的 npm 的默认策略是包提升。

• 包隔离：是指在项目中，每个依赖包都有自己独立的安装环境，这样可以避免不同依赖之间的冲突。这个概念尤其重要，当不同的依赖包需要相同的子依赖但不同版本时，如果没有良好的隔离机制，就可能导致依赖版本冲突，进而导致项目运行错误或行为异常。
• 包提升：是指将依赖关系中某些包提升到更高的目录层次，以减少冗余，节省磁盘空间。

示例：假设我们有一个项目 MyApp，该项目依赖两个包 PackageA 和 PackageB（这两个包是直接依赖），这两个包又有相同的间接依赖：

• PackageA 依赖 lodash@4.17.21
• PackageB 依赖 lodash@3.10.1

在没有包隔离的情况下，传统的包管理工具（例如 npm 早期版本）可能会尝试将 lodash 的一个版本提升到项目的 node_modules 根目录。如果 lodash@4.17.21 被安装在根目录下，那么 PackageB 依赖的 lodash@3.10.1 就会被忽略，导致 PackageB 无法正常运行。

而 pnpm 默认采用的就是包隔离策略，自然不存在上面的问题。

思考🤔：包提升本质上是为了节省磁盘空间，pnpm 采用包隔离的话磁盘空间会有浪费么？

答案：不会，因为pnpm有全局的存储空间，最终不同版本的依赖都是存储在全局空间里面，本地项目通过硬链接连接到对应版本的包。