技术分享的角度讲解 pnpm

3,627 阅读5分钟

abstract:

包管理工具; 扁平化; 依赖重复安装; 幽灵依赖; Link-软硬链接;

1.pnpm介绍

Fast, disk space efficient package manager -- 快速的,节省磁盘空间的包管理工具。

ac737e5c2e3dc28235001c607e37b9a.png github地址

cdf72e3ca1abe3e84870ee387819ce8.png 官网地址

16.png NPM

15.png

小结 : pnpm 就是一个包管理器,用途与我们常用的 npm、yarn 一样;
        特点: 快、节省磁盘空间、`安全`

2.常用包管理工具

2.1 npm2 (node 4+)

5.jpg

特点:
     1.非扁平化;
     2.依赖嵌套
问题:
    1.若多个包之间有公共的依赖,会重复安装,浪费磁盘空间;
    2. 模块实例不能共享;
    (比如 React 有一些内部变量,在两个不同包引入的 React 不是同一个模块实例,因此无法共享内部变量,
    导致一些不可预知的 bug。)
    3.windows 的文件路径最长是 260 多个字符,这样嵌套是会超过 windows 路径的长度限制的。

2.1 yarn/npm3+

7.jpg

特点:
     1.扁平化;
问题:
      1.依赖结构的`不确定性`2.扁平化算法本身的`复杂性`很高,耗时较长。
      3.项目中仍然可以`非法访问(幽灵依赖)`没有声明过依赖的包;
      4.提升只有一次,对于不同版本的依赖还是会存在重复安装的问题;

2.1.1 不确定性

假如现在项目依赖两个包 foo 和 bar,这两个包的依赖又是这样的:

那么 npm/yarn install 的时候,通过扁平化处理之后,究竟是这样

还是这样?

答案是: 都有可能。取决于 foo 和 bar 在 package.json中的位置,如果 foo 声明在前面,那么就是前面的结构,否则是后面的结构。

这就是为什么会产生依赖结构的不确定问题,也是 lock 文件诞生的原因,无论是package-lock.json(npm 5.x才出现)还是yarn.lock,都是为了保证 install 之后都产生确定的node_modules结构。

尽管如此,npm/yarn 本身还是存在扁平化算法复杂package 非法访问的问题,影响性能和安全。

3.图解- pnpm

由于现有的包管理工具并没有着手去解决上述存在的问题,于是pnpm 的作者Zoltan Kochan决定另起炉灶,这便是pnpm,一个全新的包管理工具,一套全新的依赖管理机制。

3.1节省磁盘空间

8.jpg

图的上半部分揭示了npm、yarn存在的问题,我们的依赖是分散管理的,例如我们现在有一百个项目且都用到了lodash这个依赖(dependency),那么我们就会在硬盘上保存100 份该依赖的副本

而这明显不是pnpm想要的,pnpm想要的模式是,我们提供一个可配置的依赖仓库地址(可寻址的存储),相同的文件依赖在该地址只存储一份,只占用一份存储空间;所有项目的依赖通过硬链接的方式访问此仓库;

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

eg:
例如A项目的依赖列表里有lodash,此时我们的仓库`(可寻址的存储)`并没有lodash,那么就会在仓库里安装lodash,并为
A项目创建一个lodash硬链接;下一次,当我们安装B项目的依赖,B项目也需要lodash时,就不会重复的去安装lodash了,
而是直接为B项目创建一个lodash硬链接;

3.2简单介绍下软硬链接

来自维基百科的解释:「硬链接(英语:hard link)」是计算机文件系统中的多个文件平等地共享同一个文件存储单元(如MFT条目、inode)。硬链接必须在同一个文件系统中;一般用户权限下的硬链接只能用于文件,不能用于目录,因为其父目录就有歧义了。删除一个文件名字后,还可以用其它名字继续访问该文件。硬链接只能用于同一个文件系统(对于NTFS是限制于同一个分区)。不能用于不存在的文件。

概念:

  • inode : 文件夹、文件的ID ;
  • Hard-Link : 自身创建对 inode 的 link; links值加一;links值只要不为 0,就不会真正的删除文件。
  • Symbolic-Link : 自身依赖与其他文件对 inode 的link;创建软链links值不变, 如A软链接B,A可以通过B的硬链接访问对应的inode内容;若B的link失效了,A也访问不到对应内容了;(快捷方式)

点击打开一个文件,实际上是操作系统查出这个文件对应的inode值;再通过inode,获取inode信息;最后,根据inode信息,找到文件数据所在的block,读出数据

查看文件基本信息:
stat 文件名
eg: stat a.txt

查看文件 inode
ls -i 文件名 
eg: ls -i a.txt

创建硬链接:
ln 源文件名 新创建文件名
eg : ln a.txt b.txt

创建软链接(快捷方式):
eg: ln -s b.txt c.txt

10.jpg

14.png

3.3pnpm的依赖管理方式

原理图: 11.jpg eg:pnpm install express

12.png

13.png

特点: 非扁平化,所见即所得(package.json),解决幽灵依赖问题;(安全)
       依赖全局(指定磁盘路径)安装一次,具体项目通过硬链接访问,不占用额外的磁盘空间;(节省磁盘空间、快)
       项目内嵌套依赖,若存在相同的依赖,通过软连接的形式访问;(节省磁盘空间、快) 

4.使用- pnpm

特点: 学习成本不高,会使用yarn、npm几乎可以无缝切换到pnpm;

npm 命令pnpm 等效
npm installpnpm install
npm i <pkg>[pnpm add <pkg>]
npm run <cmd>[pnpm <cmd>]
npm link[pnpm link]

当然,pnpm也提供了许多功能强大的指令,详见

5.拓展

 npm link / yarn link  本质就是软连接;
 pnpm 支持 monorepo;

文章参考:

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

从pnpm了解软硬链接的应用