Por qué pnpm se instala más rápido que npm: el almacén, los enlaces y node_modules estricto

Después de mover un repositorio de npm a pnpm, la duración de las instalaciones suele disminuir drásticamente. Esa diferencia no es fruto de la imaginación. pnpm fue diseñado para solucionar los problemas de rendimiento y almacenamiento que presentan las instalaciones tradicionales con npm, y como estos dos herramientas almacenan los paquetes de manera tan distinta, la diferencia en velocidad se debe a un cambio arquitectónico, no a una pequeña modificación.

Las secciones siguientes explican las razones por las cuales pnpm tiende a ser superior, especialmente a medida que las aplicaciones y los monorepos crecen en tamaño.

1. Un almacenamiento direccional en lugar de archivos duplicados

La principal ventaja radica en cómo se almacenan los paquetes en el disco. Con npm, cada proyecto recibe su propio árbol físico con todas sus dependencias dentro de node_modules. Por lo tanto, diez aplicaciones que necesiten lodash mantendrán diez copias separadas de esa versión en el disco.

pnpm mantiene un almacén global con direcciones de contenido para la máquina. Cada versión ocupa un único espacio allí; un proyecto que lo necesita recibe enlaces directos (o referencias de tipo copia al escribir) desde ese almacén hacia su node_modules local. Las consecuencias incluyen:

• Se evitan las descargas repetidas cuando el almacén ya contiene la versión
• Se evitan las reescrituras de bytes que ya existen en el disco
• Se consume mucho menos espacio cuando muchos proyectos comparten bibliotecas

Dado que el proceso de instalación depende en gran medida de las operaciones de entrada/salida del disco, eliminar las escrituras repetidas es lo que hace desaparecer la mayor parte de la latencia.

2. Enlaces directos y enlaces simbólicos en lugar de copiar

La ruta de instalación de npm copia los archivos del paquete en node_modules. Copiar miles de archivos en una estructura profunda es costoso.

pnpm prefiere los vínculos sólidos desde el almacén global hacia el proyecto, además de vínculos simbólicos que organizan la estructura anidada para que coincida con el grafo de dependencias. Un vínculo es, en efecto, gratuito en comparación con una copia: el sistema operativo registra otro puntero a los mismos bloques en lugar de duplicarlos.

3. Almacenamiento en caché eficiente entre proyectos

npm también almacena en caché las descargas, pero aún así expande y copia contenido de esa caché a cada proyecto. Según el modelo de almacén de pnpm, una vez que una versión existe en cualquier lugar de la máquina, llevarla a un proyecto completamente nuevo es casi instantáneo: no se realiza una segunda descarga ni hay mucho procesamiento adicional.

Ese comportamiento destaca cuando:

• Se pasa de una rama a otra que utiliza conjuntos diferentes de dependencias
• Se gestionan varios repositorios que comparten bibliotecas comunes
• Se ejecutan tareas de CI que restauran un almacén compartido entre compilaciones

4. Una estructura de node_modules no plana que evita trabajo adicional de resolución

Las versiones antiguas de npm elevaban los contenidos de node_modules para reducir la duplicación, pero esa estrategia conllevaba su propio costo: una resolución compleja para determinar dónde debería ubicarse cada paquete sin conflictos.

pnpm mantiene un diseño estricto de node_modules basado en enlaces simbólicos, de modo que un paquete solo ve las dependencias que ha declarado (sin importaciones accidentales). Una resolución más segura no es el único beneficio: también evita la costosa planificación de elevación de npm, lo que reduce el consumo de CPU durante las instalaciones.

5. Operaciones paralelizadas

pnpm programa las tareas de resolución, obtención y enlace de forma concurrente siempre que es posible, de manera más agresiva que el enfoque típico de npm. Al combinar esta concurrencia con operaciones de E/S tipo “enlace en lugar de copiar”, el tiempo total de ejecución disminuye aún más, especialmente en estructuras con grandes grafos de dependencias.

6. El impacto en el mundo real aumenta con el tamaño del proyecto

En una aplicación sencilla con unos pocos paquetes, la diferencia puede parecer modesta. La ventaja crece a medida que:

• Monorepos cuyos numerosos paquetes reutilizan las mismas bibliotecas
• Equipos que gestionan varios productos con dependencias compartidas
• Flujos CI/CD que se instalan repetidamente con cada compilación
• Árboles de dependencias grandes, típicos de las tecnologías frontales modernas

En esas situaciones, las instalaciones mediante almacenamiento y enlaces, que antes tardaban minutos con npm, pueden reducirse a segundos.

7. El ahorro de espacio en disco es un efecto secundario, no solo una ventaja

La velocidad es lo más importante, pero el mismo diseño también resuelve el problema del almacenamiento. Dado que los paquetes no se clonan por proyecto, los grupos suelen recuperar gigabytes de espacio. En discos más lentos, la menor cantidad de datos a procesar también aumenta el rendimiento como efecto secundario.

Una analogía rápida

Imagínese npm como una biblioteca que hace fotocopias del mismo libro para cada usuario. pnpm es una biblioteca donde todos comparten un mismo estante y cada lector recibe una marca de página hacia la copia compartida. Hacer fotocopias cuesta tiempo y papel; simplemente señalar un volumen existente es casi gratuito.

Conclusión

La ventaja de pnpm sobre npm no es algo superficial. Reconsidera el almacenamiento y los enlaces: evita descargas duplicadas, prefiere los enlaces a las copias y omite tareas de carga innecesarias. Las instalaciones, que suelen ser la etapa más lenta en los flujos de trabajo front-end, se convierten en un paso más rápido y eficiente.

Para equipos con varios proyectos o un monorepo, adoptar pnpm es una de las mejoras más sencillas disponibles tanto para reducir la latencia de instalación como el uso del disco.

Lecturas relacionadas

• Cambiando un proyecto de Node de npm a pnpm sin dañar al equipo — Compare npm y pnpm en cuanto a la estructura del disco, dependencias fantasma y archivos de bloqueo, luego realice la migración utilizando import, only-allow y los pins de packageManager.
• Driftr: un gestor de versiones de Node mantenido con shims después de que Volta se detuvo — Sustituya los flujos de trabajo silenciosos de Volta por shims en Go, pins de proyecto y la optimización del almacén compartido de pnpm, lo que evita que node_modules se dupliquen en cada repositorio.