[Ingeniería] El administrador de paquetes de mayor rendimiento: pnpm

¡Continúe creando, acelere el crecimiento! Este es el segundo día de mi participación en el "Nuggets Daily New Plan · June Update Challenge", haz clic para ver los detalles del evento

concepto

npm de rendimiento. Npm de alto rendimiento. Su lema es:

Administrador de paquetes rápido y eficiente en el espacio en disco。

Rápida herramienta de gestión de paquetes que ahorra espacio en disco.

Características

rápido. pnpm es 2 veces más rápido que la alternativa

Fuentes de datos

Eficiente. Los archivos en Node_modules están vinculados desde un único almacén direccionable por contenido. Puede entenderse como obtener en una tienda global, que se mencionará en detalle más adelante.
Monorepos son compatibles. pnpm tiene soporte integrado para múltiples paquetes en un solo almacén. Similar a --filter seguido del nombre del subpaquete, lo que significa que solo los paquetes recién instalados se incluyen en este paquete. Referencia práctica sencilla
estricto. pnpm crea un node_modules sin mosaicos de forma predeterminada, por lo que el código no puede acceder a paquetes arbitrarios

mecanismo de gestión de paquetes de hilos y npm

Antes de npm@3

Adopta un método de instalación anidado. Como se muestra abajo:

node_modules
└─ foo
   ├─ index.js
   ├─ package.json
   └─ node_modules
      └─ bar
         ├─ index.js
         └─ package.json
复制代码

defecto:

Los paquetes a menudo crean árboles de dependencia que son demasiado profundos, lo que puede generar rutas de directorio largas en Windows
Cuando se necesita un paquete en diferentes dependencias, se copia y pega varias veces y se generan varios archivos.

npm@3+ e hilo

Aplane el sesgo de dependencia:

node_modules
├─ foo
|  ├─ index.js
|  └─ package.json
└─ bar
   ├─ index.js
   └─ package.json
复制代码

defecto:

Dependencias fantasma. Las dependencias fantasma se refieren a dependencias en node_modules que usan dependencias de otros paquetes sin declararse en package.json
Incertidumbre de la estructura dependiente. ¿Por qué se impulsa [email protected] aquí, no [email protected] ?

Todos son posibles, dependiendo del orden de instalación. Para obtener más información, consulte . Solución para evitar este problema: bloquear archivo

npm 包分身。同样的也因为打平了 node_modules 中的依赖，就会造成了相同版本的子依赖包在被不同的项目依赖所依赖时会安装两次（即上面的图，B/C 两个包都依赖了 [email protected]）
- 安装很慢。相同的包安装了两次，占用磁盘空间，相对的安装的速度也会变慢
- 非单例。当两个不同的组件调用 require("library-f") 时，它们可能会得到两个不同的库实例，这意味着可能会突然出现两个单例的实例（换言之，底层的 “global” 变量被分配到两个不同的闭包中）。会使我们的调试变得非常困难

pnpm 的解决方案

前置知识

inode

每一个文件都有一个唯一的 inode，它包含文件的元信息，在访问文件时，对应的元信息会被 copy 到内存去实现文件的访问。

可以通过 stat 命令去查看某个文件的元信息。

stat README.md
复制代码

hard link

硬链接可以理解为是一个相互的指针，创建的 hardlink 指向源文件的 inode，系统并不为它重新分配 inode。硬链接不管有多少个，都指向的是同一个 inode 节点，这意味着当你修改源文件或者链接文件的时候，都会做同步的修改。每新建一个 hardlink 会把节点连接数增加，只要节点的链接数非零，文件就一直存在，不管你删除的是源文件还是 hradlink。只要有一个存在，文件就存在。

.pnpm 中的每个文件都是来自内容可寻址存储的硬链接

soft link

软链接可以理解为是一个单向指针，是一个独立的文件且拥有独立的 inode，永远指向源文件，这就类比于 Windows 系统的快捷方式。删除源文件，软链接就会失效。

修改了软链接或硬链接的文件，另外的硬链接或软链接以及源文件都会发生变化，这里感觉是需要小心的，特别是修改文件以调试的时候，记得还原回去，否则另外一个项目用到的时候，可能会出问题

几个重点结果表现

项目根目录下的 node_modules 中

node_modules 中只有直接依赖的包，而没有间接依赖的包。通过软链接到.pnpm 目录中

.pnpm

虚拟存储目录——.pnpm，所有直接和间接依赖项都链接到此目录中。该目录通过 <package-name>@<version> 来实现相同模块不同版本之间隔离和复用。

Store

pnpm在全局通过Store来存储所有的 node_modules 依赖，并且在 .pnpm 中存储项目的hard links

在使用 pnpm 对项目安装依赖的时候，如果某个依赖在 sotre 目录中存在了话，那么就会直接从 store 目录里面去 hard-link，避免了二次安装带来的时间消耗，如果依赖在 store 目录里面不存在的话，就会去下载一次。

假如全局的包变得非常大怎么办？使用方法为 pnpm store prune ，它提供了一种用于删除一些不被全局项目所引用到的 packages 的功能，例如有个包 [email protected] 被一个项目所引用了，但是某次修改使得项目里这个包被更新到了 1.0.1 ，那么 store 里面的 1.0.0 的 axios 就就成了个不被引用的包，执行 pnpm store prune 就可以在 store 里面删掉它了。

原理分析

我们来看一张原理图：

我们项目中有一个依赖 [email protected]。[email protected]也有一个依赖 [email protected]。

node_modules 下面有 [email protected] 和 .pnpm 目录，没有 [email protected]
[email protected] 通过软链接指向 .pnpm/[email protected]/node_modules/[email protected]。.pnpm/[email protected]/node_modules/[email protected] 又通过硬链接指向 Store
El [email protected] del que depende [email protected] se instalará en el mismo nivel que él mismo. Entiendo que el diseño aquí se basa en el mecanismo require del nodo. Cuando require('foo') en bar, foo se encontrará primero [email protected] en lugar de buscar, lo que evita el problema de las versiones inconsistentes de los paquetes dependientes. .pnpm/[email protected]/node_modules/[email protected]. Y apunte a [email protected] en el siguiente nivel de .pnpm a través de un enlace suave
.pnpm/[email protected]Lo mismo que apuntar a la Tienda a través de un enlace duro

Migración y Problemas

Es posible que estemos usando npm o yarn ahora, entonces, ¿cómo podemos hacer una mejor transición a pnpm?¿O habrá algún problema?

emigrar:

Migrar archivos de bloqueo. pnpm importcamino a través Referirse a
Solo se permite pnpm. Referirse a
resolver conflictos. Igual que npm e yarn. Simplemente resuelva el conflicto en package.json y vuelva a instalarlo
más...

pregunta:

Problemas con el almacenamiento global en CI/CD. Puede afectar a diferentes máquinas y puede haber problemas de permisos.
Comparado con npm e yarn. La comunidad aún no es tan activa.
Los enlaces duros tienen problemas de compatibilidad con Windows
más…

Resumir

pnpm realiza completamente los node_modules de la estructura del árbol de dependencia a través de la combinación de ingeniosos enlaces duros y suaves, y sigue estrictamente el estándar de resolución de módulos de Node.js, que resuelve el problema de las dependencias fantasma y los avatares de npm. Y al guardar solo una copia en ~/.pnpm-store globalmente, la velocidad de instalación en diferentes proyectos también será más rápida y el problema de la ocupación del espacio en disco también se resolverá.