[Engenharia] O gerenciador de pacotes de maior desempenho - pnpm

Continue a criar, acelere o crescimento! Este é o segundo dia da minha participação no "Nuggets Daily New Plan · June Update Challenge", clique para ver os detalhes do evento

conceito

desempenho npm. Npm de alto desempenho. Seu lema é:

Gerenciador de pacotes rápido e eficiente em espaço em disco。

Ferramenta de gerenciamento de pacotes rápida e com economia de espaço em disco.

Características

velozes. pnpm é 2x mais rápido que a alternativa

Fontes de dados

Eficiente. Os arquivos em Node_modules são vinculados a partir de um único armazenamento endereçável por conteúdo. Pode ser entendido como a obtenção em uma loja global, que será mencionada em detalhes posteriormente
Monorepos são suportados. O pnpm tem suporte integrado para vários pacotes em um único warehouse. Semelhante a --filter seguido do nome do subpacote, o que significa que apenas os pacotes recém-instalados estão incluídos neste pacote. Referência prática simples
rigoroso. O pnpm cria um node_modules não lado a lado por padrão, portanto, o código não pode acessar pacotes arbitrários

mecanismo de gerenciamento de pacotes npm e yarn

Antes de npm@3

Adota um método de instalação aninhado. Como mostrado abaixo:

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

deficiência:

Os pacotes geralmente criam árvores de dependência muito profundas, o que pode levar a longos caminhos de diretório no Windows
Quando um pacote é necessário em diferentes dependências, ele é copiado e colado várias vezes e vários arquivos são gerados

npm@3+ e Fios

Nivele a inclinação de dependência:

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

deficiência:

Dependências fantasmas. Dependências fantasmas referem-se a dependências em node_modules que usam dependências de outros pacotes sem serem declaradas em package.json
Incerteza da estrutura dependente. Por que [email protected] é impulsionado aqui, não [email protected] ?

Todos são possíveis, dependendo da ordem de instalação. Para detalhes, consulte . Solução para evitar este problema: arquivo de bloqueio

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
O [email protected] do qual o [email protected] depende será instalado no mesmo nível que ele. O design aqui, pelo que entendi, é baseado no mecanismo de exigência do nó. Quando require('foo') em bar, foo será encontrado primeiro [email protected] em vez de procurar, o que evita o problema de versões inconsistentes de pacotes dependentes. .pnpm/[email protected]/node_modules/[email protected]. E aponte para [email protected] no próximo nível de .pnpm por meio de um soft link
.pnpm/[email protected]O mesmo que apontar para a Loja através de um link físico

Migração e problemas

Podemos estar usando npm ou yarn agora, então como podemos fazer a melhor transição para o pnpm?Ou haverá algum problema?

migrar:

Migrar arquivos de bloqueio. pnpm importcaminho através . referir-se
Apenas pnpm é permitido. referir-se
resolver conflitos. O mesmo que npm e fios. Apenas resolva o conflito no package.json e reinstale-o
mais...

pergunta:

Problemas com armazenamento global em CI/CD. Pode atingir máquinas diferentes e pode haver problemas de permissões
Comparado com npm e fios. A comunidade ainda não é tão ativa
Links físicos têm problemas de compatibilidade com o Windows
mais…

Resumir

O pnpm realiza totalmente os node_modules da estrutura da árvore de dependências através da combinação de hard links e soft links engenhosos, e segue rigorosamente o padrão de resolução de módulos do Node.js, que resolve o problema de dependências fantasmas e avatares npm. E salvando apenas uma cópia em ~/.pnpm-store globalmente, a velocidade de instalação em diferentes projetos também se tornará mais rápida, e o problema de ocupação de espaço em disco também será resolvido.