pnpm: Por qué deberías migrar de npm hoy mismo

El dilema del package manager moderno

Durante más de una década, npm fue el estándar indiscutible en el ecosistema JavaScript. Viene con Node, tiene el registry más grande del mundo, y «funciona». Pero en 2026, los proyectos JavaScript han escalado en complejidad, y lo que antes era aceptable hoy es un lastre.

pnpm —»Performant npm»— nació para resolver los problemas estructurales que npm arrastra desde su versión 3: el árbol de dependencias aplanado, el desperdicio masivo de disco y la ausencia de un verdadero aislamiento entre paquetes.

Si trabajas con monorepos, microfrontends o simplemente tienes más de un proyecto en tu máquina, pnpm no es una opción: es una necesidad.

El problema de npm que nadie quiere admitir

El árbol aplanado y sus consecuencias

Desde npm v3, el instalador aplana el árbol de dependencias. En teoría esto reduce duplicados; en la práctica genera problemas sutiles pero graves:

• Dependencias fantasma: Tu código puede require('express') aunque no esté en tu package.json solo porque otra dependencia lo trajo. Cuando esa dependencia deja de usarlo o lo actualiza con breaking changes, tu código explota sin razón aparente.
• Duplicación innecesaria: El algoritmo de flattening no es perfecto. Muchos paquetes terminan duplicados en distintos niveles del árbol.
• Acceso no autorizado: Cualquier paquete en tu node_modules puede acceder a cualquier otro, incluso si no lo declaraste. Es un agujero de seguridad silencioso.

Cómo pnpm resuelve el problema

El store global con content-addressable

pnpm usa un enfoque radicalmente distinto: en lugar de copiar dependencias a cada proyecto, las almacena una sola vez en un store global en disco, identificadas por su contenido (hash). Cada proyecto accede a ellas mediante hard links y symlinks.

La estructura de node_modules con pnpm se ve así:

node_modules/
├── .pnpm/           ← Hard links al store global
│   ├── express@4.18.2/
│   │   ├── node_modules/
│   │   │   ├── debug -> ../../debug@2.6.9/node_modules/debug
│   │   │   └── express -> (hard link al store)
│   └── debug@2.6.9/
└── express -> .pnpm/express@4.18.2/node_modules/express

Las ventajas de esta arquitectura son profundas.

Ahorro de disco: 50-70% menos espacio

Si tienes 10 proyectos que usan React, con npm cada uno tiene su propia copia de React, sus 23 dependencias transitorias y todo el árbol duplicado. Con pnpm, React se almacena una vez. Siempre.

En equipos grandes o con múltiples proyectos, esto se traduce directamente en decenas de gigabytes recuperados.

Instalaciones 3-7x más rápidas

Dado que las dependencias ya existen en el store global, la mayoría de las instalaciones son simples operaciones de linkeo. Los benchmarks muestran que pnpm es consistentemente más rápido que npm y compite directamente con Yarn PnP:

Aislamiento estricto de dependencias

Con pnpm, tu código solo puede acceder a lo que declaraste explícitamente en package.json. Las dependencias transitorias viven dentro del árbol interno de .pnpm y no están accesibles desde tu código. Esto elimina de raíz el problema de las dependencias fantasma y hace que los errores sean predecibles y rastreables.

Monorepos: donde pnpm realmente brilla

Si trabajas con un monorepo —ya sea con Turborepo, Nx, Lerna o pnpm Workspaces—, este es el punto donde npm se queda corto.

pnpm soporta workspaces nativos de forma impecable:

# Un solo comando instala TODO el monorepo
pnpm install

# Ejecuta un script en todos los workspaces
pnpm -r run build

# Filtra workspaces específicos
pnpm --filter @myapp/web run dev

Los workspaces con pnpm:

• No duplican dependencias compartidas entre paquetes del monorepo
• Linkean automáticamente paquetes locales entre sí
• Respetan el aislamiento entre workspaces (cada uno solo ve lo que declaró)

Seguridad: el aspecto menos discutido

El aislamiento estricto de pnpm no es solo una ventaja técnica: es una capa de seguridad. En npm, cualquier dependencia infectada puede leer y modificar cualquier archivo dentro de node_modules. pnpm limita este alcance drásticamente al mantener las dependencias en su propio territorio dentro del store.

Además, pnpm tiene un sistema de hooks de ciclo de vida que te permite auditar y bloquear scripts de instalación maliciosos, algo que npm trata como un afterthought.

Migrar es casi indoloro

Pasarse a pnpm no requiere reescribir nada. La migración se resume en:

# Instalar pnpm globalmente
npm install -g pnpm

# Importar package-lock.json a pnpm-lock.yaml
pnpm import

# Eliminar node_modules y reinstalar
rm -rf node_modules
pnpm install

Eso es todo. pnpm import analiza tu package-lock.json existente y genera el equivalente en pnpm-lock.yaml. Tus scripts de package.json funcionan igual, y los comandos más comunes (pnpm add, pnpm remove, pnpm update) son análogos a los de npm.

Posibles gotchas

• Peer dependencies: pnpm es más estricto con peer dependencies que npm. Si migras un proyecto grande, podrías encontrar algunos errores de resolución. Son fáciles de arreglar (solo debes declarar lo que realmente usas). Esto es una feature, no un bug.
• Plugins de Webpack/gulp: Muy raramente, herramientas que asumen la estructura plana de npm pueden romperse. La solución es usar node-linker=hoisted en .npmrc para emular el comportamiento de npm como parche temporal.

¿Cuándo NO usar pnpm?

Hay casos legítimos donde npm sigue siendo la opción pragmática:

• Proyectos legacy enormes con scripts de instalación altamente personalizados que dependen del árbol aplanado.
• Entornos muy restrictivos donde no puedes instalar binarios globales (aunque pnpm se puede usar via npx).
• Equipos donde npm es un requisito corporativo —pasa, pero es raro.

Para el 99% de los proyectos nuevos y el 90% de los existentes, pnpm es superior.

Conclusión

pnpm no es una moda pasajera ni una alternativa de nicho. Es la evolución natural del package manager en JavaScript. Sus ventajas son medibles y tangibles: menos disco, instalaciones más rápidas, dependencias aisladas y un modelo de seguridad superior.

El costo de migrar es bajo. El costo de no hacerlo es seguir arrastrando un node_modules inflado, instalaciones lentas y bugs que npm nunca va a resolver porque están en su arquitectura.

Migra hoy. Tus futuros npm install —quiero decir, pnpm install— te lo agradecerán.