这篇文章给大家分享一个业内一款出色的包管理器——pnpm。目前 GitHub 已经有 star 9.8k，现在已经相对成熟且稳定了。它由 npm/yarn 衍生而来，但却解决了 npm/yarn 内部潜在的 bug，并且极大了地优化了性能，扩展了使用场景

---

pnpm

一、什么是 pnpm ?

pnpm 的官方文档是这样说的:

Fast, disk space efficient package manager

因此，pnpm 本质上就是一个包管理器，这一点跟 npm/yarn 没有区别，但它作为杀手锏的两个优势在于:

1. 包安装速度极快；
2. 磁盘空间利用非常高效。

它的安装也非常简单。可以有多简单?

npm i -g pnpm

优点

1. 速度快

在绝多大数场景下，包安装的速度都是明显优于 npm/yarn，速度会比 npm/yarn 快 2-3 倍。

2. 高效利用磁盘空间

pnpm 内部使用基于内容寻址的文件系统来存储磁盘上所有的文件，这个文件系统出色的地方在于:

• 不会重复安装同一个包。用 npm/yarn 的时候，如果 100 个项目都依赖 lodash，那么 lodash 很可能就被安装了 100 次，磁盘中就有 100 个地方写入了这部分代码。但在使用 pnpm 只会安装一次，磁盘中只有一个地方写入，后面再次使用都会直接使用 hardlink硬链接

• 即使一个包的不同版本，pnpm 也会极大程度地复用之前版本的代码。举个例子，比如 lodash 有 100 个文件，更新版本之后多了一个文件，那么磁盘当中并不会重新写入 101 个文件，而是保留原来的 100 个文件的 hardlink，仅仅写入那一个新增的文件。

3. 支持 monorepo

随着前端工程的日益复杂，越来越多的项目开始使用 monorepo。之前对于多个项目的管理，我们一般都是使用多个 git 仓库，但 monorepo 的宗旨就是用一个 git 仓库来管理多个子项目，所有的子项目都存放在根目录的packages目录下，那么一个子项目就代表一个package。如果你之前没接触过 monorepo 的概念，建议仔细看看这篇文章以及开源的 monorepo 管理工具lerna，项目目录结构可以参考一下 babel 仓库。
pnpm 与 npm/yarn 另外一个很大的不同就是支持了 monorepo，体现在各个子命令的功能上，比如在根目录下 pnpm add A -r, 那么所有的 package 中都会被添加 A 这个依赖，当然也支持 –filter字段来对 package 进行过滤。

4. 安全性高

之前在使用 npm/yarn 的时候，由于 node_module 的扁平结构，如果 A 依赖 B， B 依赖 C，那么 A 当中是可以直接使用 C 的，但问题是 A 当中并没有声明 C 这个依赖。因此会出现这种非法访问的情况。但 pnpm 脑洞特别大，自创了一套依赖管理方式，很好地解决了这个问题，保证了安全性，具体怎么体现安全、规避非法访问依赖的风险的，后面再来详细说说。

三、依赖管理

npm/yarn install 原理
主要分为两个部分, 首先，执行 npm/yarn install之后，包如何到达项目 node_modules 当中。其次，node_modules 内部如何管理依赖。
执行命令后，首先会构建依赖树，然后针对每个节点下的包，会经历下面四个步骤:

1. 将依赖包的版本区间解析为某个具体的版本号
2. 下载对应版本依赖的 tar 包到本地离线镜像
3. 将依赖从离线镜像解压到本地缓存
4. 将依赖从缓存拷贝到当前目录的 node_modules 目录
5. 然后，对应的包就会到达项目的node_modules当中。
   那么，这些依赖在node_modules内部是什么样的目录结构呢，换句话说，项目的依赖树是什么样的呢？
   在 npm1、npm2 中呈现出的是嵌套结构，比如下面这样:

node_modules
└─ foo
   ├─ index.js
   ├─ package.json
   └─ node_modules
      └─ bar
         ├─ index.js
         └─ package.json

如果 bar 当中又有依赖，那么又会继续嵌套下去。试想一下这样的设计存在什么问题:

依赖层级太深，会导致文件路径过长的问题，尤其在 window 系统下。
大量重复的包被安装，文件体积超级大。比如跟 foo 同级目录下有一个baz，两者都依赖于同一个版本的lodash，那么 lodash 会分别在两者的 node_modules 中被安装，也就是重复安装。
模块实例不能共享。比如 React 有一些内部变量，在两个不同包引入的 React 不是同一个模块实例，因此无法共享内部变量，导致一些不可预知的 bug。

接着，从 npm3 开始，包括 yarn，都着手来通过扁平化依赖的方式来解决这个问题。相信大家都有这样的体验，我明明就装个 express，为什么 node_modules里面多了这么多东西？
没错，这就是扁平化依赖管理的结果。相比之前的嵌套结构，现在的目录结构类似下面这样:
node_modules
├─ foo
| ├─ index.js
| └─ package.json
└─ bar
├─ index.js
└─ package.json
所有的依赖都被拍平到node_modules目录下，不再有很深层次的嵌套关系。这样在安装新的包时，根据 node require 机制，会不停往上级的node_modules当中去找，如果找到相同版本的包就不会重新安装，解决了大量包重复安装的问题，而且依赖层级也不会太深。
之前的问题是解决了，但仔细想想这种扁平化的处理方式，它真的就是无懈可击吗？并不是。它照样存在诸多问题，梳理一下:

1. 依赖结构的不确定性。

2. 扁平化算法本身的复杂性很高，耗时较长。

3. 项目中仍然可以非法访问没有声明过依赖的包
   掘金

pnpm 依赖管理

pnpm 的作者Zoltan Kochan发现 yarn 并没有打算去解决上述的这些问题，于是另起炉灶，写了全新的包管理器，开创了一套新的依赖管理机制，现在就让我们去一探究竟。
还是以安装 express 为例，我们新建一个目录，执行:

pnpm init -y

然后执行:

pnpm install express

我们再去看看node_modules:

.pnpm
.modules.yaml
express

四、再谈安全

不知道你发现没有，pnpm 这种依赖管理的方式也很巧妙地规避了非法访问依赖的问题，也就是只要一个包未在 package.json 中声明依赖，那么在项目中是无法访问的。

但在 npm/yarn 当中是做不到的，那你可能会问了，如果 A 依赖 B， B 依赖 C，那么 A 就算没有声明 C 的依赖，由于有依赖提升的存在，C 被装到了 A 的node_modules里面，那我在 A 里面用 C，跑起来没有问题呀，我上线了之后，也能正常运行啊。不是挺安全的吗？
还真不是。

pnpm使用

pnpm install

跟 npm install 类似，安装项目下所有的依赖。但对于 monorepo 项目，会安装 workspace 下面所有 packages 的所有依赖。不过可以通过 –filter 参数来指定 package，只对满足条件的 package 进行依赖安装。
当然，也可以这样使用，来进行单个包的安装:

// 安装 axios
pnpm install axios
// 安装 axios 并将 axios 添加至 devDependencies
pnpm install axios -D
// 安装 axios 并将 axios 添加至 dependencies
pnpm install axios -S

当然，也可以通过 –filter 来指定 package。

pnpm update

根据指定的范围将包更新到最新版本，monorepo 项目中可以通过 –filter 来指定 package。

pnpm uninstall

在 node_modules 和 package.json 中移除指定的依赖。monorepo 项目同上。举例如下:
// 移除 axios

pnpm uninstall axios --filter package-a

pnpm link

将本地项目连接到另一个项目。注意，使用的是硬链接，而不是软链接。如:

pnpm link ../../axios

参考文章

关于现代包管理器的深度思考——为什么现在我更推荐 pnpm 而不是 npm/yarn?

nvm

nvm 使用场景

node version manager（node版本管理工具）

通过将多个node 版本安装在指定路径，然后通过 nvm 命令切换时，就会切换我们环境变量中 node 命令指定的实际执行的软件路径。

使用场景：比如我们手上同时在做好几个项目，这些项目的需求都不太一样，导致了这些个项目需要依赖的nodejs版本也不同，这种情况下，我们就可以通过nvm来切换nodejs的版本，而不需要频繁地下载/卸载不同版本的nodejs来满足当前项目的要求

windows系统下的nvm 安装

1. 下载
   链接
   官网–GitHub
   可下载以下版本：

nvm-noinstall.zip：绿色免安装版，但使用时需要进行配置。

nvm-setup.zip：安装版，推荐使用

2. 安装（nvm-setup)
   双击解压后的文件nvm-setup.exe
   选择nvm安装路径
   遇坑警告！！！！！

这里我一开始选择的路径为 C:\Program Files\nvm
在安装完成后，执行 nvm use 14.5.0 的时候，出现了：
exit code 1:‘D:\Program’ #%$#^%$^%&%&@#的问题（后面这些符号表示当时报错时候的乱码……）
查阅了一些前人的经验后得知，问题的原因是Program Files 这个文件名中含有空格@_@
所以，各位在选择文件夹的时候，需要注意，文件夹名不要出现 中文 和 空格。

3. 使用nvm

nvm list 命令 - 显示版本列表

nvm list // 显示已安装的版本（同 nvm list installed）
nvm list installed // 显示已安装的版本
nvm list available // 显示所有可以下载的版本

nvm install 命令 - 安装指定版本nodejs

nvm install 14.5.0 // 安装14.5.0版本node
nvm install latest // 安装最新版本node

vm use 命令 - 使用指定版本node

nvm use 14.5.0 // 使用14.5.0版本node
nvm uninstall 命令 - 卸载指定版本 node
nvm uninstall 14.5.0 // 卸载14.5.0版本node

遇坑警告！！！！！
在运行nvm install 的时候，有可能会出现无权限安装的问题，如果遇到此问题，请 以管理员身份运行 cmd。

参考

简书
掘金nvm 安装与使用（详细步骤）