`pnpm`是一款当代备受关注的 **新兴(问题较多)** 包管理工具，使用过的同学们都会被它极快的安装速度、极少的磁盘存储空间所吸引！首先，为什么会出现`pnpm`？作者一开始对`yarn`的发布有很高的期待，但是发布后并没有满足作者的一些期待，反而让作者有些失望。 > After a few days, I realized that Yarn is just a small improvement over npm. Although it makes installations faster and it has some nice new features, it uses the same flat *node_modules* structure that npm does (since version 3). > And flattened dependency trees come with a bunch of issues
> 几天后，我意识到 Yarn 只是对 npm 的一个小小的改进。尽管它使安装速度更快，并且具有一些不错的新功能，但它使用与npm相同的平面*node_modules*结构（自版本 3 起）。`扁平化的依赖树带来了一系列问题`(具体后面会讲) 至于为什么叫`pnpm`？是因为`pnpm`作者对现有的包管理工具，尤其是`npm`和`yarn`的性能特别失望，所以起名叫做`performance npm`，即`pnpm`（高性能npm）如何突显`pnpm`的性能优势？在`pnpm`官网上，提供了一个benchmarks图表，它比对了[项目](https://github.com/pnpm/pnpm.github.io/blob/main/benchmarks/fixtures/alotta-files/package.json)在npm、pnpm、yarn（正常版本和PnP版）中，`install`、`update`场景下的耗时： ![image.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0922e407d53a46b3a64a4c037d897e62~tplv-k3u1fbpfcp-watermark.image?) 下面表格是上图中的具体数据： action | cache| lockfile| node_modules | npm | pnpm | Yarn | Yarn PnP | | ------- | ----- | -------- | ------------ | -------- | ----- | ----- | -------- | | install | | | | 1m 12.2s | 15.7s | 22.1s | 27.5s | | install | ✔ | ✔ | ✔ | 1.6s | 1.3s | 2.6s | n/a | | install | ✔ | ✔ | | 9.5s | 4s | 8.6s | 1.9s | | install | ✔ | | | 14.2s | 7.9s | 14.2s | 7.4s | | install | | ✔ | | 25.4s | 13s | 15.3s | 21.1s | | install | ✔ | | ✔ | 2.1s | 1.8s | 8.3s | n/a | | install | | ✔ | ✔ | 1.6s | 1.4s | 9.4s | n/a | | install | | | ✔ | 2.1s | 5.9s | 15s | n/a | | update | n/a | n/a | n/a | 1.6s | 12.1s | 18.7s | 32.4s | 可以看到`pnpm（橘色）`有很明显性能提升，在我们项目实践中（基于`gitlib`）提升**更明显**（`cache-paths`跟`store dir`搭配使用后）在讨论性能提升原因之前，我们需要先了解下现有包管理工具中`node_modules`存在的问题

node_modules 安装方式

目前有两种安装方式：`Nested installation`、`Flat installation`

Nested installation 嵌套安装

在 *npm@3* 之前，*node_modules*结构是`干净`、`可预测`的，因为node_modules 中的**每个依赖项**都有自己的*node_modules*文件夹，在*package.json中*指定了所有依赖项。例如下面所示，项目依赖了`foo`，`foo`又依赖了`bar`，依赖关系如下图所示： ``` node_modules └─ foo ├─ index.js ├─ package.json └─ node_modules └─ bar ├─ index.js └─ package.json ``` 上面结构有两个严重的问题： - package中经常创建太深的依赖树，这会导致 Windows 上的目录路径过长问题 - 当一个package在不同的依赖项中需要时，它会被多次复制粘贴并生成多份文件

Flat installation 扁平安装

为了解决上述问题，npm 重新考虑了*node_modules*结构并提出了扁平化结构。在*npm@3+* 和 *yarn*中，*node_modules* 结构变成如下所示： ``` node_modules ├─ foo | ├─ index.js | └─ package.json └─ bar ├─ index.js └─ package.json ``` 可以看到，`hoist`机制下，`bar`被提升到了顶层。如果同一个包的多个版本在项目中被依赖时，node_modules结构又是怎么样的？例如：一个项目`App`直接依赖了`A（version: 1.0）`和`C（version: 1.0）`，`A`和`C`都依赖了不同版本的`B`，其中`A`依赖`B 1.0`，`C`依赖`B 2.0`,可以通过下图清晰的看到`npm2`和`npm3+`结构差异： ![image.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/66612d54fac34ced8367b2a42f854efc~tplv-k3u1fbpfcp-watermark.image?) 包`B 1.0`被提升到了顶层，这里需要注意的是，多个版本的包`只能有一个`被提升上来，其余版本的包会嵌套安装到**各自的依赖当中**（类似`npm2`的结构）。 ![image.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4ebfdd76c31e47cca8a10a881b464e60~tplv-k3u1fbpfcp-watermark.image?) > 至于哪个版本的包被提升，依赖于包的安装顺序！依赖变更会影响提升的**版本号**，比如变更后，有可能是`B 1.0` ，也有可能是 `B 2.0`被提升上来（但只能有一个版本提升）细心的小伙伴可能发现，这其实并没有解决之前的问题，反而又引入了新的问题 ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6492d6f91e5e4a108fd87423ad0eb318~tplv-k3u1fbpfcp-watermark.image?)

npm3+和yarn存在的问题

Phantom dependencies 幽灵依赖

**Phantom dependencies** 被称之为**幽灵依赖**或**幻影依赖**，解释起来很简单，即某个包没有在`package.json` 被依赖，但是用户却能够引用到这个包。引发这个现象的原因一般是因为 node_modules 结构所导致的。例如使用 npm或yarn 对项目安装依赖，依赖里面有个依赖叫做 `foo`，`foo` 这个依赖同时依赖了 `bar`，yarn 会对安装的 node_modules 做一个扁平化结构的处理，会把依赖在 node_modules 下打平，这样相当于 `foo` 和 `bar` 出现在同一层级下面。那么根据 nodejs 的寻径原理，用户能 require 到 `foo`，同样也能 require 到 `bar`。 > nodejs的寻址方式：([查看更多]()) > 1. 对于核心模块（core module） => 绝对路径寻址 > 2. node标准库 => 相对路径寻址 > 3. 第三方库（通过npm安装）到node_modules下的库（可以在node环境中输入`module.paths`查看）：
> 3.1. 先在当前路径下，寻找 currentProject/node_modules/xxx
> 3.2 递归从下往上，到上级路径寻找，例如 ../node_modules/xxx
> 3.3 循环步骤3.2
> 3.4 在全局环境路径下寻找，例如 .node_modules/xxx
> 3.5 在用户目录下寻找，例如 users/金虹桥程序员/.node_modules/xxx 或者 users/金虹桥程序员/node_libraries/xxx
> 3.6 node安装目录下查找，例如 nodejs/lib/node/.node_modules/xxx

NPM doppelgangers NPM分身

这个问题其实也可以说是 hoist 导致的，这个问题可能会导致有大量的依赖的被重复安装. 举个例子：项目中有`packageA`、`packageB`、`packageC`、`packageD`。`packageA`依赖package**X 1.0**和package**Y 1.0**，`packageB`依赖package**X 2.0**和package**Y 2.0**，`packageC`依赖package**X 1.0**和package**Y 2.0**，`packageD`依赖package**X 2.0**和package**Y 1.0**。在**npm2**时，结构如下 ``` - package A - packageX 1.0 - packageY 1.0 - package B - packageX 2.0 - packageY 2.0 - package C - packageX 1.0 - packageY 2.0 - package D - packageX 2.0 - packageY 1.0 ``` 在**npm3+**和**yarn**中，由于存在hoist机制，所以X和Y各有一个版本被提升了上来，目录结构如下 ``` - package X => 1.0版本 - package Y => 1.0版本 - package A - package B - packageX 2.0 - packageY 2.0 - package C - packageY 2.0 - package D - packageX 2.0 ``` 如上图所示的packageX 2.0和packageY 2.0被重复安装多次，从而造成 npm 和 yarn 的性能一些性能损失。这种场景在monorepo 多包场景下尤其明显，这也是`yarn workspace`经常被吐槽的点，另外扁平化的算法实现也相当复杂，改动成本很高。那么`pnpm`是如何解决这种问题的呢？ ![image.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6272f5e65f9842a38f2c929046d1863f~tplv-k3u1fbpfcp-watermark.image?)

pnpm的破解之道：网状 + 平铺的node_modules结构

> 一些背景知识：[inode、hardl link和symbolic link的基础概念](https://juejin.cn/post/7032116303737389086/) `pnpm`的用户可能会发现它`node_modules`并不是扁平化结构，而是目录树的结构，类似`npm version 2.x`版本中的结构，如下图所示 ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e553fcf2111a4472a3c0b5d0f2aeea68~tplv-k3u1fbpfcp-watermark.image?) 同时还有个`.pnpm`目录，如下图所示 ![image.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/fcab63e8007b4d69a8a6199b3c2ba5b3~tplv-k3u1fbpfcp-watermark.image?) `.pnpm` 以平铺的形式储存着所有的包，正常的包都可以在这种命名模式的文件夹中被找到（**peerDep**例外）： ``` .pnpm/+@/node_modules/ // 组织名(若无会省略)+包名@版本号/node_modules/名称(项目名称) ``` 我们称`.pnmp`为虚拟存储目录，该目录通过`@`来实现相同模块不同版本之间隔离和复用，由于它只会根据项目中的依赖生成，并不存在提升，所以它不会存在之前提到的**Phantom dependencies**问题！那么它如何跟文件资源进行关联的呢？又如何被项目中使用呢？ **答案是`Store` + `Links`！**

Store

`pnpm`资源在磁盘上的存储位置。 `pnpm` 使用名为 .pnpm-store的 [store dir](https://pnpm.io/zh/npmrc#store-dir)，Mac/linux中默认会设置到`{home dir}>/.pnpm-store/v3`；windows下会设置到当前盘的根目录下，比如C（`C/.pnpm-store/v3`）、D盘（`D/.pnpm-store/v3`）。具体可以参考 `@pnpm/store-path` 这个 `pnpm` 子包中的代码: ```js const homedir = os.homedir() if (await canLinkToSubdir(tempFile, homedir)) { await fs.unlink(tempFile) // If the project is on the drive on which the OS home directory // then the store is placed in the home directory return path.join(homedir, relStore, STORE_VERSION) } ``` > 由于每个磁盘有自己的存储方式，所以Store会根据磁盘来划分。如果磁盘上存在主目录，存储则会被创建在 `/.pnpm-store`；如果磁盘上没有主目录，那么将在文件系统的根目录中创建该存储。例如，如果安装发生在挂载在 `/mnt` 的文件系统上，那么存储将在 `/mnt/.pnpm-store` 处创建。 Windows系统上也是如此。可以在不同的磁盘上设置同一个存储，但在这种情况下，`pnpm` 将**复制包**而不是**硬链接**它们，因为**硬链接只能发生在同一文件系统同一分区上**。 windows store如下图所示 ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/35a63653baea4a6bafa409698feb18aa~tplv-k3u1fbpfcp-watermark.image?) `pnpm install`的安装过程中，我们会看到如下的信息，这个里面的`Content-addressable store`就是我们目前说的`Store` ![image.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c421c89392344ac8a9c2ffbe90c37ba2~tplv-k3u1fbpfcp-watermark.image?) > **CAS 内容寻址存储**，是一种存储信息的方式，根据内容而不是位置进行检索信息的存储方式。 > **Virtual store 虚拟存储**，指向存储的链接的目录，所有直接和间接依赖项都**链接**到此目录中，项目当中的.pnpm目录 ![image.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a5e6928ce7e34212aac71330912c22ac~tplv-k3u1fbpfcp-watermark.image?) 如果是 npm 或 yarn，那么这个依赖在多个项目中使用，在每次安装的时候都会被重新下载一次如图可以看到在使用 pnpm 对项目安装依赖的时候，如果某个依赖在 sotre 目录中存在了话，那么就会直接从 store 目录里面去 hard-link，避免了二次安装带来的时间消耗，如果依赖在 store 目录里面不存在的话，就会去下载一次。看到这里，你应该对Store有了一些简单的了解，接着我们来看下项目中的文件如何跟Store关联。

Links（hard link & symbolic link）

还记得文章刚开始，放了两张beachmark的图表，图表上可以看到很明显的性能提升（如果你使用过，感触会更明显）！ pnpm 是怎么做到如此大的提升的呢？一部分原因是使用了计算机当中的 **[Hard link](https://zh.wikipedia.org/wiki/%E7%A1%AC%E9%93%BE%E6%8E%A5)** ，它减少了文件下载的数量，从而提升了下载和响应速度。 ### hard link 通过`hard link`，用户可以通过不同的路径引用方式去找到某个文件，需要注意的是一般用户权限下只能硬链接到文件，**不能用于目录**。 `pnpm` 会在`Store`(上面的Store) 目录里存储项目 `node_modules` 文件的 `hard links` ，通过访问这些link直接访问文件资源。举个例子，例如项目里面有个 2MB 的依赖 `react`，在 pnpm 中，看上去这个 `react`依赖同时占用了 2MB 的 node_modules 目录以及全局 store 目录 2MB 的空间(加起来是 4MB)，但因为 `hard link` 的机制使得两个目录下相同的 2MB 空间能从两个不同位置进行`CAS寻址`直接引用到文件，因此实际上这个`react`依赖只用占用2MB 的空间，而不是4MB。因为这样一个机制，导致每次安装依赖的时候，如果是个相同的依赖，有好多项目都用到这个依赖，那么这个依赖实际上最优情况(即版本相同)只用安装一次。而在`npm`和`yarn`中，如何一个依赖被多个项目使用，会发生多次下载和安装！如果是 npm 或 yarn，那么这个依赖在多个项目中使用，在每次安装的时候都会被重新下载一次。 ![image.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/59a9e225408c414aad4f534359b26ac6~tplv-k3u1fbpfcp-watermark.image?) 如图可以看到在使用 pnpm 对项目安装依赖的时候，如果某个依赖在 store 目录中存在了话，那么就会直接从 store 目录里面去 hard-link，避免了二次安装带来的时间消耗，如果依赖在 store 目录里面不存在的话，就会去下载一次。通过`Store` + `hard link`的方式，不仅解决了项目中的**NPM doppelgangers**问题，项目之间也不存在该问题，从而完美解决了`npm3+`和`yarn`中的包重复问题！如果随着项目越来越大，版本变更变多，历史版本的资源会堆积，导致`Store`目录越来越大，那如何解决这个问题呢？针对这个现象，pnpm 提供了一个命令来解决这个问题: [pnpm store | pnpm](https://pnpm.io/cli/store)。同时该命令提供了一个选项，使用方法为 `pnpm store prune` ，它提供了一种用于删除一些不被全局项目所引用到的 packages 的功能，例如有个包 `axios@1.0.0` 被一个项目所引用了，但是某次修改使得项目里这个包被更新到了 `1.0.1` ，那么 store 里面的 1.0.0 的 axios 就就成了个不被引用的包，执行 `pnpm store prune` 就可以在 store 里面删掉它了。该命令推荐偶尔进行使用，但不要频繁使用，因为可能某天这个不被引用的包又突然被哪个项目引用了，这样就可以不用再去重新下载这个包了。 ### symbolic link 由于`hark link`只能用于文件不能用于目录，但是`pnpm`的`node_modules`是树形目录结构，那么如何链接到文件？通过`symbolic link`（也可称之为软链或者符号链接）来实现！通过前面的讲解，我们知道了`pnpm`在全局通过`Store`来存储所有的node_modules依赖，并且在`.pnpm/node_modules`中存储项目的hard links，通过`hard link`来链接真实的文件资源，项目中则通过`symbolic link`链接到`.pnpm/node_modules`目录中，依赖放置在同一级别避免了循环的软链。 `pnpm` 的 `node_modules` 结构一开始看起来很奇怪： 1. 它完全适配了 Node.js。 2. 包与其依赖被完美地组织在一起。 > 有 peer 依赖的包的结构[更加复杂](https://pnpm.io/zh/how-peers-are-resolved)一些，但思路是一样的：使用软链与平铺目录来构建一个嵌套结构。假设我们有个mono repo，它有`repo A`、`repo B`、`repo C`和`repo D`4个repo。每个repo有各自的一些依赖项（包括**dependencies**和**peerDependencies**），**假定**结构如下图所示：(需要注意有个peer dep) ![image.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6b71a1e9bf7a4a99a8d177875961225d~tplv-k3u1fbpfcp-watermark.image?) 下面是`pnpm workspace`中，比较清晰（不清晰的话留言，我可以改改！）说明了`Store`和`Links`间的相互关系： ![image.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ca7baa4581b641cf98ca556849c659de~tplv-k3u1fbpfcp-watermark.image?) 官网也更新了类似的调用关图，大家也可以看看！ ![image.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/647ad2ac0e93413fbfb62e1db90cfc40~tplv-k3u1fbpfcp-watermark.image?)

PeerDependencies

pnpm 的最佳特征之一是，在一个项目中，`package`的一个特定版本将始终只有一组依赖项。这个规则有一个例外 -那就是具有 [peer dependencies ](https://docs.npmjs.com/files/package.json#peerdependencies)的`package`。通常，如果一个`package`没有 peer 依赖项（peer dependencies），它会被硬链接到其依赖项的软连接（symlinks）旁的 `node_modules`，就像这样： ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/08fc3d6dd49f4d2a92d1d31a9a9999e6~tplv-k3u1fbpfcp-watermark.image?) 如果 `foo` 有 peer 依赖（peer dependencies），那么它可能就会有多组依赖项，所以我们为不同的 peer 依赖项创建不同的解析： ![image.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4dd2ecc8c09b4cf7a01d72e6f5113102~tplv-k3u1fbpfcp-watermark.image?) `pnpm`创建` foo@1.0.0_bar@1.0.0+baz@1.0.0` 或`foo@1.0.0_bar@1.0.0+baz@1.1.0`内到`foo`的软链接。因此，Node.js 模块解析器将找到正确的 peers。 `peerDep`的包命名规则如下(看起来就很麻烦) ``` .pnpm/+@_+@/node_modules/ // peerDep组织名(若无会省略)+包名@版本号_组织名(若无会省略)+包名@版本号/node_modules/名称(项目名称) ``` > *如果一个`package`没有 peer 依赖（peer dependencies），不过它的依赖项有 peer 依赖，这些依赖会在更高的依赖图中解析*, 则这个传递`package`便可在项目中有几组不同的依赖项。例如，`a@1.0.0` 具有单个依赖项 `b@1.0.0`。 `b@1.0.0` 有一个 peer 依赖为 `c@^1`。 `a@1.0.0` 永远不会解析`b@1.0.0`的 peer, 所以它也会依赖于 `b@1.0.0` 的 peer 。如果需要解决peerDep引入的多实例问题，可以通过 [`.pnpmfile.cjs`](https://pnpm.io/zh/pnpmfile)文件更改依赖项的依赖关系。

pnpm和npm、yarn的功能差异

下面图表摘自官网，感兴趣的同学可以自行查阅。 | 功能 | pnpm | Yarn | npm | | ------------------ | --------------------- | ------------------- | ------------------------ | | 工作空间支持（monorepo） | ✔️ | ✔️ | ✔️ | | 隔离的 `node_modules` | ✔️ - 默认 | ✔️ | ✔️ | | 提升的 `node_modules` | ✔️ | ✔️ | ✔️ - 默认 | | Plug'n'Play | ✔️ | ✔️ - 默认 | ❌ | | 零安装 | ❌ | ✔️ | ❌ | | 修补依赖项 | ❌ | ✔️ | ❌ | | `管理 Node.js 版本`（pnpm独有） | ✔️ | ❌ | ❌ | | 有锁文件 | ✔️ - `pnpm-lock.yaml` | ✔️ - `yarn.lock` | ✔️ - `package-lock.json` | | 支持覆盖 | ✔️ | ✔️ - 通过 resolutions | ✔️ | |`内容可寻址存储(CAS)`（pnpm独有） | ✔️ | ❌ | ❌ | | 动态包执行 | ✔️ - 通过 `pnpm dlx` | ✔️ - 通过 `yarn dlx` | ✔️ - 通过 `npx` | 从图表可以看到有两个是`pnpm`独有的实现：`管理 Node.js 版本`和`内容可寻址存储(CAS)` 其中CAS前面已经介绍过了，我们讲一下`管理 Node.js 版本`。这个在`.npmrc`文件中，Node模块设置中使用`use-node-version`进行配置（[其它配置信息](https://pnpm.io/zh/npmrc)） `use-node-version`用于指定应用于项目运行时的确切 Node.js 版本，支持**semver**版本设置。设置后， pnpm 将自动安装指定版本的 Node.js 并将其用于执行 `pnpm run` 命令或 `pnpm node` 命令。 ```json // 指定版本16.x use-node-version=^16.x ``` 当前安装的是14.x，使用上述配置后，在执行时会有一个warning：` WARN Unsupported engine: wanted: {"node":">=14.0.0"} (current: {"node":"^16.x","pnpm":"6.22.2"})` 但不影响执行结果

workspace

`pnpm`跟`npm`、`yarn`一样，也内置了对monorepo的支持，使用起来比较简单，在项目根目录中新建`pnpm-workspace.yaml`文件，并声明对应的工作区就好。 ```yaml packages: # 所有在 packages/ 子目录下的 package - 'packages/**' ```

workspace 工作空间协议

默认情况下，如果可用的`packages`与已声明的可用范围相匹配，pnpm 将从工作区链接这些`packages`。例如，如果 `bar` 中有 `"foo"："^1.0.0"` 的这个依赖项，则 `foo@1.0.0` 链接到 `bar` 。但是，如果 `bar` 的依赖项中有`"foo": "2.0.0"` ，而`foo@2.0.0` 在工作空间中并不存在，则将从npm registry安装`foo@2.0.0` 。这种行为带来了一些不确定性。幸运的是，`pnpm`从版本 **3.7** 开始支持工作区协议`workspace:` 。当使用此协议时，pnpm 将拒绝解析除本地工作区 `package` 之外的任何内容。因此，如果您设置为 `"foo": "workspace:2.0.0"` 时，安装将会失败，因为 `"foo@2.0.0"` 不存在于工作空间中。这个特性在monorepo当中特别有用。可以通过修改配置`link-workspace-packages`来改变包的使用方式（远端下载 or 本地）。 `link-workspace-packages`有三个值 - **true** 默认，使用本地可用的packages; - **false** 禁用后，将从registry 下载安装到本地，并被使用（类似yarn\npm 安装） - **deep** 自 v5 版本起可用，本地packages当中的依赖项（sub package）也可以被链接到并使用它支持两种引用方式：**别名引用**和**相对引用**。

别名引用

假如工作区有一个名为 `local-package` 的包，可以通过这样引用 `"local-package": "workspace:"`。如果是其它别名，可以这么引用： "ref-package": "workspace:local-package@*"

相对引用

假如packages下有同层级的`repoA`、`repoB`，其中`repoA`依赖于`repoB`，则可以写作`"repoA": "workspace:../repoB"`。发布前，这两种引用方式，都会被替换为常规的版本规范。

filter 过滤

通过该参数，允许我们将命令运用到指定的包上面，类似于`jQuery`跟`Dom`的选择器，写法如下 ```node pnpm --filter ``` 同时它也支持链式调用，可以一次写多个调用，如下所示， ```node pnpm --filter selector1 --filter selector2 -- filter=!selector3 ``` > Lerna中也支持选择器，参数是`scope`，下面的文章对比了`Lerna`和`pnpm`的选择器，感兴趣的同学可以看一下
> [Lerna 与 pnpm 选择器](https://medium.com/pnpm/pnpm-vs-lerna-filtering-in-a-multi-package-repository-1f68bc644d6a)

matching 匹配

匹配规则支持三种维度匹配：`packageName（包名）`、`dirName （目录名）`、`git commit/branch（git提交或分支名）` `packageName（包名）`支持包名通配符匹配、包和依赖项(直接和间接依赖)匹配、依赖项(直接和间接依赖)匹配、包被依赖项(直接和间接依赖)匹配、被依赖项(直接和间接依赖)匹配 ```js // 包名通配符匹配，其中scope是可选的，当单个scope时：`--filter=core` 将选择 `@babel/core`;多scope不生效 pnpm test --filter "@babel/core"\ pnpm test --filter "@babel/*"\ pnpm test --filter "*core" // 包和依赖项(直接和间接依赖)匹配，要选择一个软件包及其依赖项 (直接和非直接) 在包名称后加上省略号： `...` pnpm test --filter foo... pnpm test --filter "@babel/preset-*..." // 可选择一组根目录包 // 依赖项(直接和间接依赖)匹配，要选择一个软件包及其依赖项 (直接和非直接)，在包名前添加一个山形符号加上上面提到的省略号 pnpm test --filter foo^... pnpm test --filter "@babel/preset-*^..." // 可选择一组根目录包 // 包被依赖项(直接和间接依赖)匹配，在包名前添加一个省略号: `...`。 pnpm test --filter ...foo // 将运行 `foo` 以及依赖于它的所有包的测试： // 被依赖项(直接和间接依赖)匹配 pnpm test --filter "...^foo" // 将运行所有依赖于 `foo` 的包的测试 ``` ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/149d228b9c59405b8f3f2b63439a55a0~tplv-k3u1fbpfcp-watermark.image?) 细心的小伙伴可能发现了，核心就是：**一个元素`packageName` + 两个操作（`...`和`^`）的排列组合** - `packageName` 名称，支持通配符 - `...` 选择包及其依赖项，需要放在包名前或包名后。 - `...packageName` **被** 依赖项匹配 - `packageName...` 依赖项匹配 - `^` 排除当前包，可以单独使用，但是推荐和`...`（依赖项）搭配使用 > packageName、 ...packageName、packageName...、...packageName...、...^packageName、packageName^...、...^packageName^...、...^packageName...、...packageName^... 这样看的话会清晰很多。 `dirName （目录名）`支持相对路径引用（通常是POSIX格式）、指定目录项目的形式（可以搭配操作一起使用） ```js // 相对路径引用 pnpm --filter ./packages // 搭配操作符（`...`和`^`） pnpm --filter ...{} pnpm --filter {}... pnpm --filter ...{}... ``` `git commit/branch（git提交或分支名）`，这个和`packageName`的用法类似，但是它可以和前面两者搭配使用 ```js // 运行自 `master` 以来所有变动过的包以及被其依赖的包的测试 pnpm test --filter "...[origin/master]" // 和`package-name`搭配使用 pnpm --filter "...@babel/*{components}[origin/master]" // 和`dir-name`搭配使用 pnpm --filter "...{packages}[origin/master]..." ```

excluding 排除

只要在开头添加一个`!`，过滤规则选择器都会变为排除项。 > 在 `gitbash`、 `zsh`等shell中, "!" 应转义: `\!`. 否则会报 `bash: !{packageName}: event not > found` 错误

multiplicity 混合

因为`filter`支持链式调用，所以这两种场景可以混合使用。例如：有个组织`@fe`，里面存在包A、B、C、D，我们需要选中不含B包的其它包来执行build命令，可以这么写 ``` pnpm build --filter @fe/* --filter=!@fe/B ``` 混合的情况下（Filter1、Filter2、...、FilterN），Filter1会先生效，然后是Filter2，直到N，跟`ECMAScript`类似，当然真实业务中可能会更复杂，具体还需要按场景分析。 > 一开始Filtering区分不明显，后来本文作者发了个PR重新修改了文档结构，方便理解

command 命令

参照官网，按照使用场景进行分类，列举出**部分**命令的用法，所有命令请前往 [官网](url) 查看

manage depencies 管理依赖

pnpm add

`add`命令是老朋友了，跟`yarn add`类似，安装package以及依赖的package，默认是安装到`dependencies`中。注意的是在workspace中，如果想要安装在root workspace中需要添加`-w`或者`--ignore-workspace-root-check`，安装到packages中需要使用`--filter`，否则会安装失败 5种安装姿势： - **npm**（默认）： workspace中会先确认改包是否被引用，是的话根据使用版本来安装；非workspace中，默认会从 `npm registry`安装最新的package。例如：`pnpm add express@nightly`(tag)、`pnpm add express@1.0.0`（version）、`pnpm add express@2 react@">=0.1.0 <0.2.0"`（semantic versioning）。 - **workspace**： workspace安装依赖时, 会从已配置的源处进行安装，当然取决于是否设置了 [`link-workspace-packages`](https://pnpm.io/zh/workspaces#link-workspace-packages),以及是否使用了 [`workspace: range protocol`](https://pnpm.io/zh/workspaces#workspace-ranges-workspace)。 - **local file system**：本地安装有两种安装方式，源文件和本地目录。 - **reomote tarball**：远端安装必须钥匙一个可访问的**URL**。 - **git repository**：git安装通过git clone从git 作者处安装。常用的参数选项 - `--save-prod, -P`：安装到**dependencies** - `--save-dev, -D`：安装到**devDependencies** - `--save-optional, -O`：安装到**optionalDependencies** - `--save-peer`：安装到**peerDependencies**和**devDependencies**中 - `--global`：安装全局依赖。 - `--workspace`：仅添加在 workspace 找到的依赖项。

pnpm remove

别名: **rm, uninstall, un** 从 `node_modules` 和项目的 `package.json` 中移除包。参数跟`add`类似，不展开说了

pnpm install

别名: **i** `pnpm install` 用于安装项目所有依赖。在CI环境中, 如果存在需要更新的 lockfile 会安装失败，所以每次版本更新后，本地一定要install后再提交，否则会导致版本发布失败。这里讲一下`--fix-lockfile`和`--shamefully-hoist`。 - `--fix-lockfile` 参数自动修复损坏的 lock 文件入口，首次安装时候特别有用，如果遇到某个包找不到，可能是幻影依赖的问题，需要手动添加依赖或者排查原因。 - `--shamefully-hoist`创建一个扁平`node_modules` 目录结构, 类似于`npm` 或 `yarn`。这是**非常不推荐**的，但是确实某些场景下可以解决迁移后无法使用额问题

pnpm import

`import`命令支持从其它格式的lock文件生成`pnpm-lock.yaml`文件，目前支持三种格式源文件 - `package-lock.json` - `npm-shrinkwrap.json` - `yarn.lock` (v6.14.0 起) 个人认为这个命令跟`lerna import`搭配起来使用更好，`lerna import`导入git提交历史（[了解更多](https://juejin.cn/post/7043998041786810398)），一个负责生成`pnpm-lock.yaml`文件，这样可以完全还原项目的提交历史和版本依赖。

pnpm prune

`prune`移除项目中不需要的依赖包，配置项支持 `--prod`(删除在 `devDependencies` 中指定的包)和 `--no-optional`(删除在 `optionalDependencies` 中指定的包。). 当全局或者单例模式下使用`store-dir`时会尤其有用，可以用脚本周期性的删除历史版本依赖。 > WARNING > prune 命令目前不支持在 `monorepo`中递归执行。可以删除一个只安装 production 依赖的`monorepo` 的几个` node_modules` 文件夹，然后重新再用 `pnpm install --prod` 安装。

review dependencies 查看依赖

pnpm list

别名: `ls`。此命令会以一个树形结构输出所有的已安装`package`的版本及其依赖。添加参数`--json`后会输出JSON格式的日志。

run scripts运行脚本

pnpm run

别名: `run-script`。运行一个在 `package`的 manifest 文件中定义的脚本。假如您有个 `start` 脚本配置在了`package.json `中，像这样： ```json "scripts": { "start": "start-storybook -s ./assets -p 23762 -c __storybook" } ``` 您现在可以使用 `pnpm run start`运行该脚本！很简单吧？对于那些不喜欢敲键盘而浪费时间的人要注意的另一件事是，所有脚本都会有 pnpm 命令的别名，所以最终 `pnpm run start` 的简写是 `pnpm start` （**仅适用于**那些不与已有的pnpm 命令相同名字的脚本）。注意不要命令里面嵌套`pnpm run command`，否则会造成循环执行。

总结

文章写到这里基本结束了，简单回顾下文章的内容。 - `node_modules`随着设计的变化，出现了嵌套安装和扁平安装两种方式，当然它们都有各自的优缺点 - `pnpm`是如何通过非扁平化的安装方式解决现有`node_modules`出现的问题 - 特有的功能集：`管理 Node.js 版本`和`内容可寻址存储(CAS)` - 常用的命令：`install`、`add`、`remove`、`update`、`publish`等 - `workspace`如何使用 - `filter`过滤选择器的一些常见用法：`matching` 匹配、`excluding` 排除和 `multiplicity` 混合 ![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ea38cad1c5e64850b8c4f47fb3b9580e~tplv-k3u1fbpfcp-watermark.image?) # 参考资料 - [扁平的 node_modules 不是唯一的方法](https://pnpm.io/zh/blog/2020/05/27/flat-node-modules-is-not-the-only-way) - [Hard links and Symbolic links](https://juejin.cn/post/7032116303737389086/) - - -