pnpm的设计与npm的对比

2025-02-04 1,124 阅读8分钟

pnpm 与 npm 对比科普（macOS 系统下）

本文旨在对比 pnpm 与 npm 在 macOS 系统下的工作原理与使用差异，从全局包管理、配置方式、依赖安装机制以及实际使用中可能遇到的问题等角度进行详细说明，帮助开发者更好地理解两者的优缺点。

1. 全局包管理与安装路径

npm 的全局包管理

默认安装位置
npm 在 macOS 上默认将全局包安装到 /usr/local/lib/node_modules。用户可以通过以下命令确认 npm 的安装路径： npm config get prefix
命令注册
安装全局包后，npm 会自动将包内的可执行文件链接到 /usr/local/bin，从而可以在终端直接调用相应命令。

pnpm 的全局包管理

配置获取
pnpm 的配置来源更加多元：它可以从命令行参数、环境变量以及 .npmrc 文件中读取配置。
初始化与配置写入
在执行 pnpm setup 后，pnpm 会将相关配置写入用户的 shell 配置文件（例如 macOS 默认的 ~/.zshrc），配置示例如下：
```
# pnpm
export PNPM_HOME="/Users/xxx/Library/pnpm"
export PATH="$PNPM_HOME:$PATH"
# pnpm end
```
这样，pnpm 管理的包的可执行文件所在目录会被加入到环境变量 PATH 中，其优先级通常高于 npm 的全局 bin 目录。

2. 依赖安装与模块解析差异

npm 与 yarn 的“幽灵依赖”

依赖提升机制
在使用 npm 或 yarn 安装依赖时，常见的现象是某些依赖包会被“提升”到项目根目录下的 node_modules 中。这种现象有时会让开发者感觉有“幽灵依赖”，即某些包没有在 package.json 中明确声明，却可以直接引用（通常是由于扁平化依赖树的原因）。
实际效果
例如，当使用 yarn 安装时，@babel/runtime 等包可能会被提升，使得在项目其他地方直接引用变得可能。

pnpm 的严格依赖解析

无依赖提升（No Hoisting）
与 npm 和 yarn 不同，pnpm 并不会自动将依赖包提升到项目根目录的 node_modules。pnpm 使用符号链接（symlink）的方式，将包安装在一个全局的内容寻址存储区中，然后在项目中建立指向这些存储区的链接。
优势
- 一致性：这种安装方式使得每个包都在自己的独立目录中，从而避免了因依赖扁平化带来的版本冲突或隐式依赖问题。
- 节省磁盘空间：多个项目共享同一份存储，减少重复安装同一依赖的情况。
可能的问题
- 某些工具或脚本可能默认依赖于 npm 或 yarn 的依赖提升机制，导致在 pnpm 环境下找不到某些预期的“幽灵依赖”。例如，在使用 pnpm 时发现 node_modules 下并不存在 @babel/runtime 包，而使用 yarn 安装时则可以正常引用。

3. pnpm的详细设计

3.1 pnpm 的核心理念

内容寻址存储（Content-Addressable Storage）

概念：
pnpm 采用内容寻址存储的方式管理所有已下载的依赖包。每个包在存储中都有一个基于其内容生成的唯一标识（哈希值），确保相同内容的包只存储一份。
优势：
- 节省磁盘空间：多个项目如果依赖相同版本的包，pnpm 只需要存储一份，而不是每个项目各自保存一份副本。
- 提高安装速度：当缓存命中时，无需重复下载和解压，能显著加快依赖安装过程。

无依赖提升的 Node Modules

严格的依赖树：
与 npm 和 yarn 不同，pnpm 不会将依赖提升到项目根目录的 node_modules 中。每个包都保留在自己的目录中，并通过符号链接（symlink）构建依赖树。
实现方式：
- 符号链接：
  pnpm 在项目的 node_modules 目录下为每个依赖创建符号链接，链接指向全局内容寻址存储中的实际文件。
- 隔离依赖：
  这种方式确保了包之间的依赖关系更加明确，防止了隐式依赖问题，使项目的依赖结构更加透明和可控。

3.2 pnpm 的架构设计与工作原理

全局缓存与共享存储

全局缓存目录：
pnpm 会在用户目录下创建一个专用的缓存目录（例如 ~/.pnpm-store 或者用户配置的 PNPM_HOME），用于存放所有下载的包文件。
共享机制：
当不同项目需要相同的依赖时，pnpm 直接利用全局缓存中的内容而不是重复下载。即使是离线模式，也可以通过缓存进行安装。

安装过程优化

硬链接与软链接：
pnpm 倾向于使用硬链接来实现文件共享，这种方式比软链接更高效且可靠。但在某些跨分区或特定文件系统环境下，pnpm 会选择使用软链接作为替代。
原子性安装：
pnpm 在安装过程中采用原子操作，确保在安装或更新依赖时，不会出现中间状态导致项目无法正常运行的情况。

多版本共存

依赖隔离：
由于不进行依赖提升，每个模块可以维护其独立的依赖树。这意味着不同的包可以依赖同一库的不同版本而互不干扰，解决了版本冲突的问题。
平行安装：
pnpm 充分利用 CPU 多核的优势，支持并行下载和安装依赖，进一步加快了依赖管理效率。

3.3 pnpm 配置与使用技巧

配置文件与环境变量

.npmrc 支持：
pnpm 支持读取 .npmrc 文件中的配置，这使得很多原本在 npm 中使用的配置项也可以在 pnpm 中生效。例如，私有仓库地址、认证信息等都可以直接迁移。
环境变量：
用户可以通过设置环境变量（例如 PNPM_HOME）来控制 pnpm 的行为和存储位置，确保与系统其他工具的集成。

CLI 命令与常用参数

基本命令：
- pnpm install：安装项目所有依赖。
- pnpm add <package>：添加新的依赖到项目，并自动更新 package.json。
- pnpm update：更新已安装的依赖到符合版本规则的最新版本。
- pnpm remove <package>：移除项目中的指定依赖。
高级参数：
- --frozen-lockfile：确保锁定文件与项目依赖严格一致，防止意外版本更新。
- --filter：用于多包仓库（monorepo）场景，允许针对特定子项目执行操作。

多包仓库（Monorepo）支持

工作区功能：
pnpm 原生支持多包仓库，可以在单个仓库中管理多个相互依赖的包。
优势：
- 一致性：所有包共用同一份依赖版本声明和锁定文件，减少冲突。
- 高效：跨包引用使用符号链接，无需重复安装。

4. 优势与局限对比

pnpm 的优势

性能提升
- 利用全局内容寻址存储，安装速度更快，并且磁盘占用更少。
依赖管理严格
- 明确的依赖树结构帮助开发者及早发现未声明的依赖，从而提高项目的稳定性和可维护性。
更高的环境一致性
- 由于不进行依赖提升，项目在不同机器上的表现更加一致，减少因环境差异引起的问题。

npm 的优势

生态成熟
- npm 是最早的 Node.js 包管理器，拥有最广泛的社区支持和丰富的文档。
依赖提升的便利性
- 对于某些依赖要求较为宽松的项目，依赖提升可以简化包引用，但这同时也可能带来隐患。
兼容性
- 许多第三方工具或脚本默认假定依赖被提升，使用 npm（或 yarn）时可能会更加顺畅。

5. 实践建议

选择合适的工具
- 如果你的项目对依赖管理要求严格、需要确保环境的一致性，并且愿意适应较为严格的包解析规则，那么 pnpm 是一个不错的选择。
- 对于快速原型开发或已有大量依赖提升习惯的项目，npm 或 yarn 可能会更顺手。
注意配置管理
- 无论使用哪种工具，都建议定期检查配置文件（如 .npmrc、.yarnrc、~/.zshrc）中的设置，确保路径和环境变量配置正确，避免工具之间的冲突。
应对“幽灵依赖”问题
- 在 pnpm 中，由于依赖不会被自动提升，如果遇到某些包引用不到的问题，应检查 package.json 中是否正确声明了所有依赖，必要时可以显式安装缺失的依赖包。

总结

在 macOS 系统下，npm 和 pnpm 都各有优缺点。npm 的传统方式使得全局包管理和依赖提升相对直观，但可能隐藏依赖关系带来的风险；而 pnpm 则通过独特的全局内容寻址存储和无依赖提升机制，实现了更高的效率和一致性，但同时也要求开发者对依赖管理有更明确的认知。