新一代包管理工具 pnpm

文章首发于公众号? 青梅主码,欢迎关注

背景

如果你从事过前端方面的工作和开发,相信你对 npmyarn 这样的工具已经再熟悉不过了。作为包管理工具,npm 已经有了长足的历史。一个项目初始化过程都需要通过 npm install 命令安装相关的依赖到 node_modules 目录下,对于较大型的前端项目,node_modules 的大小很多时候是超乎我们想象的。而 npm 在版本更新迭代的过程中,也一直在优化这个问题,下面我们就简要聊聊 npm 的发展历程。

npm 发展

npm2

npm2 发展阶段,安装依赖是相对比较直接的,它会直接按照配置文件 package.json 中的依赖项去下载相关依赖包,而依赖包的组织形式则是按照树形结构去排列的。由于不同的包的依赖关系在版本上差异较大,依赖关系相对复杂,所以 npm2 直接按照配置去下载并组织依赖的方式,是简单明晰的做法,保证了各个依赖的独立性,在依赖变更时,相互并不影响,其关系可以通过下图来描述:

从上图中,我们可以看到

  1. ABC 包相互独立
  2. ABC 包可能会依赖相同的包,比如 D@1.0
  3. ABC 包可能会存在较深的依赖层级,比如 C package

其中 23 这两点的负面影响会随着项目复杂度而上升,可能会导致的几个问题

Note: 通过 npm ls --depth=n 查看项目相关依赖层级深度

npm3

为解决 npm2 中存在的冗余和依赖树问题,npm3 对依赖项进行了依赖扁平化讨论和处理

扁平化具体来讲就是依赖不在按照树型进行安装,而是安装将依赖安装在同级目录下,npm install 安装依赖时,会按照配置文件 package.json 里的依赖顺序进行解析,遇到新包就把它放在第一层级的目录(如 D@1.0E@1.0F@1.0),后面如果遇到第一级目录已有的包,会先进行依赖版本判断,如果版本一样则忽略,否则会按照 npm2 的方式依次挂在依赖包目录下,这样处理的原理遵循了Nodejs的依赖解析规则当前目录下没有找到node_modules,它将递归解析父目录下的node_modules

使用 npm3 安装依赖后如下图:

这种扁平化处理方式一定程度上缓解了冗余和依赖树问题,同时 npm3 还支持动态安装更新包,如果依赖有更新,可以通过 npm dedupe 命令对依赖树进行优化。

但是 npm3 也存在部分问题,比如:

  • phantom_deps(幻影依赖)npm3不会以确定的方式安装依赖项。举例来说:我们在 NodeJSrequire() 的函数,不需要考虑配置文件 package.json 中是否有该依赖项。这可能会导致依赖版本不兼容,并且开发者不容易发现;另外,由于Nodejs的依赖解析规则,这还会导致幻影 node_modules ,即依赖向上查找,可能会越过代码目录自身的 node_modules 。如下:
- my-monorepo/
  - package.json
  - node_modules/
    - semver/
    - ...
  - my-monorepo/my-library/
    - package.json
    - lib/
      - index.js
    - node_modules/
      - brace-expansion
      - minimatch
      - ...

my-monorepo/my-library/lib/index.js 可能使用的是my-monorepo/node_modules 中的依赖,而非自身目录 my-monorepo/my-library/node_modules

  • npm doppelgangers(npm 分身)。简单来讲,npm 分身是指同一个依赖的不同版本会出现在 node_modules 中,比如项目中同时依赖了 A@1.0.0A@2.0.0,无论是扁平化处理A@1.0.0A@2.0.0,另一个依赖还是会被重复,如果这样的分身较多,就会导致一些潜在问题,比如扩展包大小变大、相关类型校验交叉等

npm5

npm5 通过添加 lock 文件来记录依赖树信息,进行依赖锁定,从而唯一确定 node_modules 的结构,这样处理可以保证团队成员使用同一份node_modules依赖结构。但是,我们前文提到的平铺式的算法的复杂性、幻影依赖和分身问题仍然没有解决。

pnpm 简介

前文我们大致梳理了 npm 的发展和遗留问题。而 pnpm 比较巧妙地解决了它们,并且极大地提升了依赖包管理的效率。

pnpmperformant npm(高性能的 npm),如 pnpm 官网所言,它是快速的,节省磁盘空间的包管理工具,同时,它也较好地支持了 workspacemonorepos

举例来说,如果项目中,你使用了某个依赖项的多个版本,那么 pnpm 只会将有差异的文件添加到仓库。如果某个依赖包有 100 个文件,而它的新版本只改变了其中 1 个文件。那么 pnpm update 时只会添加 1 个新文件,而不会复制整个新版本的所有包。此外。所有文件都会存储在硬盘上的某一位置。 当依赖包被被安装时,其中的文件会硬链接到这一位置,而不会占用额外的磁盘空间。同时,项目中允许共享同一版本的依赖。接下来我们先了解下 pnpm 的使用效果

pnpm 效果

与 npm、yarn、yarn pnp 工具链效果对比,来自 pnpm benchmarks

action cache lockfile node_modules npm pnpm Yarn Yarn PnP
install 1m 9.5s 15.3s 16.6s 23.6s
install 2.4s 1.3s 2.3s n/a
install 14.8s 4s 6.8s 1.5s
install 21.8s 8.9s 11.2s 6.2s
install 35.4s 13.4s 12s 17.9s
install 3.1s 1.9s 7s n/a
install 2.4s 1.3s 7.6s n/a
install 3s 6.1s 11.8s n/a
update n/a n/a n/a 2.3s 11.8s 15.5s 28.3s

从上表数据我们可以看出,pnpm 的各项性能均比其它包管理工具有优势,那你可能会想,为什么 pnpm 有如此优越的表现?,接下来我们聊聊 pnpm 的主要原理

pnpm 的原理

pnpm 主要有两个不同与其包管理工具的特性:

基于硬链接的 node_modules

pnpm 创建从全局存储到项目中 node_modules 文件夹的硬链接,而硬链接指向磁盘上原始文件所在的同一位置,具体来说就是 node_modules 中每个包的每个文件都是来自内容可寻址存储的硬链接,简言之,就是特定版本和名称的包全局只有一份。举例来看:

node_modules
└── .pnpm
    ├── bar@1.0.0
    │   └── node_modules
    │       └── bar -> <store>/bar
    │           ├── index.js
    │           └── package.json
    └── foo@1.0.0
        └── node_modules
            └── foo -> <store>/foo
                ├── index.js
                └── package.json

node_modules 下面的唯一文件夹叫做 .pnpm, .pnpm 下面是一个 <PACKAGE_NAME@VERSION> 文件夹,而在其下面 <PACKAGE_NAME> 的文件夹是一个基于内容可寻址存储的硬链接。同时,我们也可以通过 pnpm root 命令来打印当前项目中存放模块(modules)的有效目录

基于依赖解析的软链接 symlinks

观察以下依赖包结构

node_modules
├── foo -> ./.pnpm/foo@1.0.0/node_modules/foo
└── .pnpm
    ├── bar@1.0.0
    │   └── node_modules
    │       └── bar -> <store>/bar
    └── foo@1.0.0
        └── node_modules
            ├── foo -> <store>/foo
            └── bar -> ../../bar@1.0.0/node_modules/bar

我们可以看到在 foo@1.0.0/node_modules/bar 内引用了 bar 的软链接 ../../bar@1.0.0/node_modules/bar,而在项目里引用 foo 的软链接 ./.pnpm/foo@1.0.0/node_modules/foo,如果项目内新增一个依赖包 qar@2.0.0,则其引用结构如下:

node_modules
├── foo -> ./.pnpm/foo@1.0.0/node_modules/foo
└── .pnpm
    ├── bar@1.0.0
    │   └── node_modules
    │       ├── bar -> <store>/bar
    │       └── qar -> ../../qar@2.0.0/node_modules/qar
    ├── foo@1.0.0
    │   └── node_modules
    │       ├── foo -> <store>/foo
    │       ├── bar -> ../../bar@1.0.0/node_modules/bar
    │       └── qar -> ../../qar@2.0.0/node_modules/qar
    └── qar@2.0.0
        └── node_modules
            └── qar -> <store>/qar

根据前文我们介绍到的Nodejs的依赖解析规则foo@1.0.0/node_modules/foo/index.js 中所需的依赖包 bar,实际上使用的是bar@1.0.0/node_modules/bar中的内容,因此,只有真正在依赖项中的包才能被访问到。而对于不同的 peer dependencies 的依赖解析原理,可以参考这里 How peers are resolved

通过基于硬链接的node_modules基于依赖解析的软链接原理,我们了解到,当我们在相同操作系统下第二次安装同一个依赖包时,我们需要做的仅仅是创建一个该依赖包对应的硬链接,对于同一个依赖包的不同版本,也只有不同的部分会被重新保存起来,而具体有没有 pnpm 是在哪里判断的呢?全局的 pnpm 索引文件在 ~/.pnpm-store/v3/files。基于此,使用硬链接让依赖包的安装速度非常快,同时也去除了冗余,节省较大磁盘空间。

symlinks 符号连接

pnpm 使用

pnpm 的具体使用这里我们不展开介绍了,可以查看官网使用方法CLI 命令即可。这里只提几个有意思的点

CI 集成

GitHub Actions 上,你可以像这样使用 pnpm 安装和缓存依赖项,配置文件目录: .github/workflows/NAME.yml

name: pnpm Example Workflow
on:
  push:
jobs:
  build:
    runs-on: ubuntu-20.04
    strategy:
      matrix:
        node-version: [15]
    steps:
    - uses: actions/checkout@v2
    - uses: pnpm/action-setup@v2.0.1
      with:
        version: 6.20.3
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v2
      with:
        node-version: ${{ matrix.node-version }}
        cache: 'pnpm'
    - name: Install dependencies
      run: pnpm install

pnpm 除了在开发体验方面的优越表现,在项目集成方面也毫不逊色,对于较大型项目从 npm 或 yarnpnpm迁移过程后,也得到了极大的优化,结果如下:

Without cache With cache
yarn 2 (without dedupe) 6min 31s 1min 11s
yarn 3 (without dedupe) 4min 50s 57s
yarn 3 4min 1s 50s
yarn 3 (optimized) 1min 10 45s
pnpm 58s 24s

通过以上数据,我们可以 pnpm 在 CI 应用中的良好表现。

具体可以参考这篇最佳实践 A story of how we migrated to pnpm

pnpm 前置

项目中使用 pnpm 时,如果你不希望项目内其他人使用 npm iyarn这类包管理器,可以在 package.json 配置文件中添加预安装 preinstall 配置项,从而规范使用统一的包管理器。

{
    "scripts": {
        "preinstall""npx only-allow pnpm"
    }
}

管理 NodeJS 版本

在以前,如果你同时支撑了多个项目,而且需要在其中切换,你可能需要切换不同的 NodeJS 版本,也许你会用到像 nvmVolta 这样的 NodeJS 版本管理器,而 pnpmv6.12.0 版本后支持了 pnpm env 命令,你可以使用它来安装并指定使用哪个版本的 NodeJS ,是不是方便了很多。

monorepo 支持

因为pnpmmonorepos 的大力支持,像 VueVite 这些开源项目也转而使用了它。使用pnpm run 结合 --filter--recursive--parallel 选项,可以指定特定包,并高速执行相关命令。这样做的好处是之前要另外安装 lerna 这种 monorepo 管理工具的场景,现在 pnpm 可以包揽了。详细文章可以参考这里 pnpm vs Lerna: filtering in a multi-package repository

总结

本文从 pnpm 的出现背景开始,简要介绍了 npm 的发展过程及存在的问题,继而对 pnpm 及其效果进行了简介,重点讲述了 pnpm 的实现原理,并从应用侧选择了四个点展开。

pnpm 作为新一代包管理器,自身有不少优越的表现,它通过硬链接和软链接的方式,解决了 npm 幻影依赖和分身问题,并且较好地解决了依赖包复用问题,从而实现了依赖包高效快速的安装。需要特别注意的是 pnpm 严格遵循了 Nodejs 依赖解析规则,规避了之前任意依赖包的访问修改问题。

当然,pnpm 使用过程中也存在一些问题,包括 Vue 官方在迁移过程中,也处理过部分问题。另外,一些包也存在兼容性问题,由于包自己实现了模块解析,并没有遵循相关规范。但 pnpm 也提供了相关解决方法。具体参考 pnpm FAQ

综上,pnpm 是一个功能全面,性能优越的包管理器,快来体验 pnpm 吧。

发表评论

您的邮箱地址不会被公开。 必填项已用 * 标注