【Node.js】npm、yarn 和 pnpm 的区别

秀秀_heo

已于 2024-09-24 15:47:42 修改

阅读量2.8k

点赞数 1

分类专栏： Node.js 后端开发文章标签： javascript npm 开发语言

于 2023-07-10 12:17:52 首次发布

本文链接：https://blog.csdn.net/XiugongHao/article/details/131636099

版权

Node.js 后端开发专栏收录该内容

81 篇文章 1 订阅

订阅专栏

1. npm（Node Package Manager）

npm是最早出现的JavaScript包管理工具，生态系统非常成熟。使用非常广泛，几乎所有的JavaScript项目都支持npm。
提供了npx命令，可以无需先安装命令即可运行命令（原理是下载代码，运行代码，再将下载后的代码删除），直接进行 nodejs 版本切换，可以直接运行 url（npm仓库 / github gist中的代码）中的代码片段。
使用 package-lock 文件锁版本。
npm早期版本（比如v4以前）在性能和安全性上相对较差，安装速度较慢。
依赖管理上曾出现过一些问题，比如“幽灵依赖”(phantom dependency）和难以追踪的依赖版本。

2. yarn

yarn 安装速度更快且稳定，特别是在并发下载和缓存上。
yarn.lock 确保依赖版本一致性。
提供了一些 npm 没有的特性，比如可以确定所有依赖的状态，通过 yarn audit 提供更好的安全性审查。但有时有些新特性可能会出现某些问题。

npm install -g yarn

开始新项目 yarn init
添加依赖包

yarn add [package]
yarn add [package]@[version]
yarn add [package] --dev
升级依赖包 yarn upgrade [package]@[version]
移除依赖包 yarn remove [package]
安装项目的全部依赖 yarn install

3. pnpm

pnpm 使用硬链接和符号链接来共享依赖项，从而减少了磁盘空间的使用和安装时间。
安装速度极快，高效的包管理性能使其非常适合大型项目。
支持 monorepo，用于管理多个子包非常方便。
生态相对不成熟，对于老旧的工具兼容性可能会出问题。

在这里插入图片描述

pnpm 安装

pnpm store 位置：pnpm store path

从 store 中删除当前未被引用的包来释放 store 空间。

详细说明

下面图来源：npm, yarn, pnpm 的区别

依赖提升

npm@3 之前是嵌套安装，每一个包都有自己的 node_modules 文件夹：

在这里插入图片描述

这种方式导致会创建较深的依赖树，目录结构很长。

当不同包同时依赖同一个相同的包，那么本地磁盘中会存储多个相同的包。

之后，npm@3 和 yarn 使用了扁平化结构，node_modules 所有包放在同一层级。

但是多个版本的包只有一个能被提升，其他的会被嵌套在各自的依赖中。

在这里插入图片描述

至于那个版本的包被提升，取决于 package.json 中的顺序位置。谁在前，就将谁的依赖包提升。

所以引发的第一个问题是依赖结构的不确定导致扁平化结构的不确定。

锁版本

于是出现了 package-lock.json 和 yarn.lock ，保证 install 后出现确定的依赖结构。但是不能解决仍然出现各种版本的包。

区别：

这两个文件的内容格式有所差异，package-lock.json 是 JSON 格式的（记录了每一个安装包的确切版本号、依赖树，以及包的来源（npm 仓库、URL 或本地路径）），而 yarn.lock 用的是更紧凑的纯文本格式（ key-value 对）。
生成工具不同：package-lock.json 是由 npm 生成的，而 yarn.lock 是由 Yarn 生成的。
目的稍有不同：虽然两者都是用来确保项目在不同环境下依赖版本一致，但在 npm 中，package-lock.json 还用来提升安装速度并确保包管理的一致性，Yarn 的锁文件最初是解决 npm 存在的一些性能和一致性问题。

幽灵依赖

第二个问题是存在幽灵依赖，这个包没有在 package.json 中，用户却能引用到这个包:

在这里插入图片描述

当项目不引用 a 和 c ，直接引用 b 也会出现问题。

npm 分身

第三个问题是 npm 分身，提升机制可能会导致大量的依赖被重复安装：

在这里插入图片描述

这里的 e 和 f 的 1.0 版本被提升，而 2.0 版本被安装多次，造成性能损失。

这时就轮到 pnpm 解决问题了。他会在项目中生成一个 .pnpm 文件，下面的依赖进行平铺，以包名和版本号实现相同版本和不同版本之间的复用和隔离。

由于不存在提升，他没有幽灵依赖的问题。

在这里插入图片描述

为了解决 npm 和 yarn 在不同依赖下多次安装相同的包的问题，也就是 npm 分身的问题，pnpm 使用名为 .pnpm-store 的存储目录，存储所有包的 hard link 硬链接。如果依赖存在，直接在 .pnpm-store 中 hard link ，不存在则去下载。

由于硬链接只能用于目录，不能用于文件，所以项目还通过 sym link 软链接链接文件夹 node_modules 。

pnpm 建立硬链接

在这里插入图片描述

硬链接相当于对内存地址的直接拷贝，一个文件夹改变，拷贝后的文件夹内容同时改变。

软链接（符号链接）相当于建立一个快捷方式，而这个快捷方式直接指向源文件。软链接的手动创建必须拥有管理员权限。

当使用npm或Yrn时，如果你有100个项目，并且所有项目都有一个相同的依赖包，那么，你在硬盘上就需要保存100份该相同依赖包的副本。
如果是使用pnpm,依赖包将被存放在一个统一的位置，因此：
- 如果你对同一依赖包使用相同的版本，那么磁盘上只有这个依赖包的一份文件
- 如果你对同一依赖包需要使用不同的版本，则仅有版本之间不同的文件会被存储起来：
- 所有文件都保存在硬盘上的统一的位置
  - 当安装软件包时，其包含的所有文件都会硬链接到此位置，而不会占用额外的硬盘空间
  - 这让你可以在项目之间方便地共享相同版本的依赖包

pnpm store path 可以获取 pnpm 在本地的总仓库，包含了所有下载过的包。