大家好，我是讯享网，很高兴认识大家。



关于软件包的管理工具，大家比较熟知的是 和 ，今天给大家介绍一个新的包管理工具pnpm。

讯享网

通过此文，您将学习到的以下知识：

1. 基础使用、常用命令等
2. 依赖包是如何管理和存储的
3. workspace协议，支持
4. 对比、，有什么优势
5. 如何将、转为

阅读此文之前，需要了解的知识：

1. 内容可寻址存储(CAS)
2. 软链接（符号链接）
3. 硬链接

节约磁盘空间并提升安装速度

代表（高性能的npm），同和，都属于包管理安装工具，它较和在性能上得到很大提升，被称为快速的，节省磁盘空间的包管理工具。

当使用 或 时，如果你有 100 个项目使用了某个依赖（dependency），就会有 100 份该依赖的副本保存在硬盘上，而在使用 时，依赖会被存储在内容可寻址的存储中，所以：

1. 如果你用到了某依赖项的不同版本，只会将不同版本间有差异的文件添加到仓库。 例如，如果某个包有100个文件，而它的新版本只改变了其中1个文件。那么  时只会向存储中心额外添加1个新文件，而不会因为仅仅一个文件的改变复制整新版本包的内容。
2. 所有文件都会存储在硬盘上的某一位置。 当软件包被安装时，包里的文件会硬链接到这一位置上对应的文件，而不会占用额外的磁盘空间。 这允许你跨项目地共享同一版本的依赖。

因此，您在磁盘上节省了大量空间，这与项目和依赖项的数量成正比，并且安装速度要快得多！

摘自官网：pnpm.io/zh/motivati…

安装

通过安装，也可以在官网查看其他安装方式

讯享网

通过下述命令查看已安装的的版本

讯享网

使用

1. 初始化，生成文件

2. 安装依赖

讯享网

3. 运行中定义的脚本，启动服务即可

示例：创建一个项目

通过使用套件新建一个的项目，直达vue官方链接

讯享网

通过上述操作，我们学到了项目的初始化、安装依赖、启动服务等，可以运行起来，感受一下它和运行速度的差异。

官网查看更多命令

设置源

• 查看源：
• 切换源：

初始化

• 初始化package.json：

注意：只能一键快速生成文件，如果要一步一步填写每个属性的值生成文件，则需要通过生成，如果要一键快速生成，需要增加参数来生成。

管理依赖

• 安装依赖包到  ：
• 安装依赖包到：
• 安装依赖包到：
• 全局安装依赖包：
• 安装项目全部依赖：，别名
• 更新依赖包：，别名
• 删除依赖包：，别名

查看依赖

• 查看本地安装的依赖：，别名
• 查看全局安装的依赖：，别名
• 检查过期的依赖：

运行脚本

• 运行自定义脚本：，别名
• 运行测试脚本：
• 启动套件创建项目：
• 运行启动命令：

发布依赖包

• 发布依赖包：

管理node环境

可实现、等版本管理工具，安装并切换版本的功能。

• 本地安装并使用：
• 全局安装并使用：

pnpm基于符号链接来创建非扁平化的

对比和安装的：

那怎么管理这些依赖包的呢？带着这一问题，我们继续探究。

详细看一下生成的目录如下：

 中只有一个  的文件夹以及三个符号链接、  和 。 这是因为我们的项目只安装了、  和 三个依赖，使用符号链接的方式将项目的直接依赖添加到的根目录下，也就是说目录下只有我们项目中依赖的、和一个目录。

以依赖包举例，看一下依赖包和目录里都有些什么：

展开依赖包，我们会有两个疑问：

1. 是一个符号链接，那它的实际位置在哪里？
2. 依赖的其他次级依赖在哪里？

的实际位置

称为虚拟存储目录，以平铺的形式储存着所有的项目依赖包，每个依赖包都可以通过路径找到实际位置。

即直接依赖的包 符号链接到路径：，包中的每个文件都是来自内容可寻址存储的硬链接。

讯享网

的次级依赖

观察上面的目录结构，发现目录下还是没有次级依赖的。

pnpm 的 设计 ，包的依赖项与依赖包的实际位置位于同一目录级别。

所以  的次级依赖包不在 ， 而是在 ，与实际位置位于同一目录级别。

这里的等次级依赖包又是一个符号链接，仍符合刚才的逻辑，实际位置在，包内的每个文件再硬链接到中的对应文件。

我们再通过官网提供的依赖图，再辅助理解一下依赖包之间的关系。

项目依赖了版本，依赖了版本，下只有直接依赖包符号链接和目录。

解析时，就会符号链接到实际位置，包中的文件（并非包文件夹）都硬链接到中的对应文件，做为的依赖，与的实际位置处于同一层级，符号链接指向实际位置，包中的文件再硬链接至。

关于peerDependencies是怎么处理依赖的，可以看官网这篇文章

总结：pnpm使用符号链接Symbolic link（软链接）来创建依赖项的嵌套结构，将项目的直接依赖符号链接到的根目录，直接依赖的实际位置在，依赖包中的每个文件再硬链接（Hard link）到。

：资源在磁盘上的存储位置

一般在Mac/Linux系统中，默认会设置到；windows下会设置到当前盘的根目录下，比如C（）、D盘（）。

可以通过执行命令查看store存储目录的路径

进入存储路径，查看存储的内容如下：

以文件夹进行分类，每个文件夹内包含重新编码命名后的文件，依赖包硬链接到此处对应的文件。

在项目中执行的时候，依赖包存在于中，直接创建依赖包硬链接到中，如果不存在，则从远程下载后存储在中，并从项目的依赖包中创建硬链接到中。

上图中提示包从硬链接到，以及和的作用位置。

• 内容寻址存储 — Content-addressable store(CAS)

它是一种存储信息的方式，根据内容而不是位置进行检索信息的存储方式，被用于高速存储和检索的固定内容，如存储。这里的CAS作用于目录。

• 虚拟存储 — Virtual store

指向存储的链接的目录，所有直接和间接依赖项都链接到此目录中，项目当中的.pnpm目录。

因为这样的处理机制，每次安装依赖的时候，如果是相同的依赖，有好多项目都用到这个依赖，那么这个依赖实际上最优情况(即版本相同)只用安装一次。如果依赖包存在于中，则从目录里面去，避免了二次安装带来的时间消耗，如果不存在的话，就会去下载并存储在中。

如果是 或 ，那么这个依赖在多个项目中使用，在每次安装的时候都会被重新下载一次。

对比发现安装速度相当之快！必须给个大大的赞！

❓紧接着会有人问，那一直往里存储依赖包，会不会越来越大？

官方提供了一个命令：，从存储中删除未引用的包。

未引用的包是系统上的任何项目中都未使用的包。 在大多数安装操作之后，包有可能会变为未引用状态。

官方举例：在  期间，包  被更新为 。 pnpm 将在存储中保留  ，因为它不会自动除去包。 如果包  没有被其他任何项目使用，它将变为未引用。 运行  将会把  从存储中删除 。

运行  是不会影响项目的。 如果以后需要安装已经被删除的包，pnpm 将重新下载他们。建议清理不要太频繁，以防在切换分支等时pnpm需要重新下载所有删除的包，减慢安装过程。

pnpm store的其他命令

：查看store中已修改的包，如果包的内容与拆包时时相同的话，返回退出代码0。

：只把包加入存储中，且没有修改存储外的任何项目或文件

：删除存储中未被引用的包

跟和一样，内置了对单一存储库monorepo的支持，只需要在项目根目录下创建  文件，定义的根目录。

例如：

讯享网

Workspace协议（workspace:）

workspace：工作空间

默认情况下，如果可用的 与已声明的可用范围相匹配，pnpm 将从工作空间链接这些 。

例如，如果  中有  的这个依赖项，则  链接到 。 但是，如果  的依赖项中有 ，而  在工作空间中并不存在，则将从 npm registry 安装  ，这种行为带来了一些不确定性。

支持 协议（写法： ）。 当使用此协议时，pnpm 将拒绝解析除本地 包含的 之外的任何内容。 因此，如果您设置为  时，安装将会失败，因为  不存在于此 中。

接下来，我们使用代码库来理解一下Workspace协议：

代码库地址：github.com/vuejs/core

根目录可以看到有这两个文件、， 其中lock文件为时生成的lock文件，space文件则为仓库中必须需要的定义工作空间目录的文件。

1. 点开文件：github.com/vuejs/core/…

我们看到文件内容为：

也就表示这个目录下面所有的文件为的内容。

2. 点开文件：github.com/vuejs/core/…

我们看到用到本地包的都标注了协议，这样依赖的就一直是本地的包，而不是从安装的包。

3. 我们验证一下到底依赖的是不是本地包

clone代码库到本地，安装依赖

查看文件夹，发现文件中依赖的、包都已符号链接的形式存在，如下图：

按协议，打开文件夹，做一个测试，在文件中加入，如下图：

这时候再打开文件，可以发现刚才在里面改的内容，显示在了目录下的包里。

打开磁盘上存储（）的依赖包，并没有上面新增的，上面的改动只影响了本地依赖包，而不是远程下载后存储在磁盘上的包，也就是说符合协议引入的依赖包就是本地的目录（即）下的包。

别名引用

假如工作区有一个名为  的包，可以通过这样引用 ，如果是其它别名，可以这么引用：。

相对引用

假如下有同层级的、，其中依赖于，则可以写作。

发布workspace包

当包打包发布时，将会动态替换这些依赖。

假设我们的 中有 、 、 、  并且它们的版本都是 ，如下：

讯享网

将会被转化为：

现在很多很受欢迎的开源项目都适用了pnpm的工作空间功能，感兴趣的可以前往官网查看哦！

性能对比

在官网上，提供了一个基准测试图表，它展示了、、、在、等场景下的耗时：

通过上图，可以看出的运行速度基本上是的两倍，运行速度排名。

功能对比

官网链接

通过上图可以看出独有的两个功能：

• 管理Node.js版本()
• 内容可寻址存储（）

竞争

在 v3.1 添加了 链接器。 因此 可以创建一个类似于 创建的 目录结构。

此外， 团队计划实现内容可寻址存储，以提高磁盘空间效率。

团队决定也采用 使用的符号链接的 目录结构（相关 RFC）。

可参考代码库的这一次升级commit log

操作步骤：

1. 全局安装

讯享网

2. 删除或生成的

3. 从其他软件包管理器的 文件生成 ，再执行（相当于）生成依赖，防止没有lock文件意外升级依赖包，导致项目出错

讯享网

4. 删除或生成的文件

5. 项目中的命令等修改为，包括文档、运行命令等

可参考代码库，本人亲测，已成功升级

卸载全局安装的包

通过查看全局安装的包，只有通过安装的包才为全局包哦！

1. 列出每个全局包进行删除

2. 找到全局目录的位置并手动删除它

移除

1. 通过独立脚本安装的，可以通过进行移除（谨慎：删除前确定好删除的内容）
2. 使用安装的，可以通过进行移除

删除全局内容可寻址存储

如果您不在主磁盘中使用 ，您必须在使用 的每一个磁盘中运行上述命令。 因为 会为每一个磁盘创建一个专用的存储空间。

还有一些问题，需要进一步的验证和考究：

1. 打包的时候，依赖包之间引用是怎么处理的？
2. 手动修改中的包的内容，其他引用地方是不是影响了？
3. 删除项目文件夹，的机制是什么，能否正确处理？

是高性能的，通过、、等管理依赖包，达到多项目之间依赖共享，减少安装时间，也非常的好上手，通过安装，安装依赖即可。

又get了一个新的知识，有不对的和想要探讨的，欢迎评论留言哦！

参考文档

1. pnpm.io/zh/motivati…
2. juejin.cn/post/…
3. juejin.cn/post/…