¿Deberías cambiar de npm a pnpm?

May 26, 2026 · 5 min read

Probablemente hayas visto pnpm mencionado en configuraciones de monorepos, archivos de CI y documentación de frameworks. Quizá algún colega lo recomienda con entusiasmo. Pero ¿realmente vale la pena la fricción de cambiar para tu trabajo diario en frontend, o está resolviendo problemas que aún no tienes?

Esto es lo que realmente necesitas saber.

Puntos Clave

pnpm utiliza un almacén direccionable por contenido con hard links y symlinks, eliminando las dependencias fantasma y reduciendo el uso de disco entre múltiples proyectos.
pnpm 11 mantiene las restricciones de scripts de ciclo de vida introducidas en pnpm 10, requiriendo aprobación explícita mediante pnpm approve-builds para reducir el riesgo en la cadena de suministro.
El filtrado de workspaces y el protocolo workspace:* hacen de pnpm una opción excelente para monorepos que usan Turborepo o Nx.
Fija tu gestor de paquetes con el campo packageManager en package.json y utiliza --frozen-lockfile en CI para instalaciones deterministas.
pnpm destaca en monorepos y configuraciones multi-proyecto; para una aplicación de un solo paquete, seguir con npm suele estar bien.

Qué hace diferente a pnpm de npm

pnpm no es solo un npm más rápido. Las diferencias reales son estructurales.

npm crea un directorio node_modules plano, lo que significa que tu código puede importar accidentalmente paquetes que nunca declaraste como dependencias — un problema conocido como dependencias fantasma. pnpm utiliza un almacén direccionable por contenido con hard links y symlinks, de modo que solo tus dependencias declaradas son accesibles en el nivel raíz. Esto hace que la resolución de dependencias sea más estricta y reproducible.

La otra gran diferencia es el uso de disco. pnpm almacena cada versión de paquete una sola vez de forma global y la enlaza con hard links a tus proyectos. Si mantienes varios proyectos de Next.js o Vite localmente, no estás duplicando cientos de megabytes por proyecto.

Para un análisis más profundo del modelo de almacenamiento y el aislamiento de dependencias, vale la pena revisar la comparación oficial de pnpm vs npm.

pnpm 11 y el giro hacia la seguridad

pnpm 11, lanzado en abril de 2026, continúa una tendencia que se ha venido consolidando en las versiones mayores recientes: priorizar la seguridad y el determinismo por encima de la velocidad pura.

El comportamiento más importante a conocer antes de cambiar: pnpm ahora bloquea los scripts de ciclo de vida de las dependencias por defecto a menos que se aprueben explícitamente. Este es el flujo de pnpm approve-builds introducido en pnpm 10. Si instalas un paquete con un script postinstall — común en paquetes que compilan binarios nativos, como sharp, esbuild o canvas — la instalación tendrá éxito, pero el script no se ejecutará hasta que lo apruebes.

Esto sorprende a desarrolladores que esperan que todo funcione sin más. Ejecuta pnpm approve-builds de forma interactiva, o configura las dependencias de build permitidas en pnpm-workspace.yaml:

onlyBuiltDependencies:
  - sharp
  - esbuild

Es una concesión deliberada: más fricción al principio, menos sorpresas en la cadena de suministro después.

Workspaces y herramientas para monorepos

Aquí es donde pnpm toma una ventaja notable. Los workspaces de npm funcionan, pero la implementación de workspaces de pnpm es más ergonómica para configuraciones más grandes.

Defines los paquetes en un archivo pnpm-workspace.yaml:

packages:
  - 'apps/*'
  - 'packages/*'

Y obtienes un potente filtrado de serie:

pnpm --filter @myapp/ui build
pnpm --filter "...^@myapp/ui" test  # ejecuta tests en paquetes que dependen de ui

Para equipos que usan Turborepo o Nx, el protocolo de workspace de pnpm (workspace:*) se integra de forma limpia y mantiene las dependencias internas explícitas.

Fijar versiones con el campo packageManager

Un paso práctico independientemente de si usas Corepack: añade un campo packageManager a tu package.json para indicar qué gestor de paquetes y versión espera tu proyecto.

{
  "packageManager": "pnpm@11.0.0"
}

Corepack puede hacer cumplir esto en entornos donde esté habilitado, pero incluso sin Corepack, comunica claramente la intención a tu equipo y a la configuración de CI.

Integración con CI mediante GitHub Actions

- uses: pnpm/action-setup@v6
  with:
    version: 11
- uses: actions/setup-node@v4
  with:
    node-version: 22
    cache: 'pnpm'
- run: pnpm install --frozen-lockfile

Usa siempre --frozen-lockfile en CI. Evita mutaciones silenciosas del lockfile y hace que las instalaciones sean deterministas.

La documentación oficial de pnpm para CI también incluye ejemplos para GitHub Actions, GitLab CI, CircleCI, Azure Pipelines y Bitbucket Pipelines.

Cuándo vale la pena cambiar

pnpm tiene más sentido si trabajas en un monorepo, gestionas muchos proyectos locales o quieres un aislamiento de dependencias más estricto por defecto. El modelo de seguridad de pnpm approve-builds es genuinamente útil para equipos que se preocupan por la higiene de la cadena de suministro.

Si mantienes una aplicación de un solo paquete y npm te funciona bien, la fricción de la migración probablemente no compense. Los workspaces de npm son lo suficientemente maduros para configuraciones sencillas, y el hecho de que sea el estándar del ecosistema aún tiene un valor real.

Conclusión

La respuesta honesta: prueba pnpm primero en un proyecto nuevo. La superficie de comandos es prácticamente idéntica, el lockfile es legible, y la mayoría de frameworks frontend — incluyendo Next.js, Vite y Astro — lo soportan sin configuración adicional. Si la estrictitud y el ahorro de disco encajan con tu flujo de trabajo, escalarlo a proyectos existentes se convierte en una decisión mucho menor.

Preguntas Frecuentes

Generalmente sí. Elimina node_modules y package-lock.json, luego ejecuta pnpm import para convertir tu lockfile, seguido de pnpm install. Mantén un ojo en las dependencias fantasma de las que tu código pudo haber dependido bajo el layout plano de npm — pnpm las mostrará como imports faltantes, que solucionas añadiéndolas explícitamente a package.json.

approve-builds es una lista de permitidos de paquetes autorizados a ejecutar scripts de ciclo de vida. Puedes desactivar la barrera por completo, pero hacerlo reintroduce el riesgo en la cadena de suministro que pnpm 11 está diseñado para mitigar. El camino recomendado es aprobar solo paquetes en los que confíes y que genuinamente necesiten pasos postinstall, como compiladores de binarios nativos.

La gran mayoría funcionan sin cambios. Los problemas aparecen mayormente con paquetes que asumen una estructura plana de node_modules o dependen de dependencias fantasma. La mayoría de las librerías populares solucionaron esto hace tiempo. Si algo se rompe, la configuración public-hoist-pattern en .npmrc puede replicar el hoisting estilo npm para paquetes específicos como vía de escape.

Para instalaciones en frío, pnpm suele ser más rápido debido a su resolución paralela y su almacén direccionable por contenido. Para instalaciones en caliente entre proyectos que comparten dependencias, la diferencia es drástica porque pnpm reutiliza paquetes ya descargados mediante hard links. En CI con una caché poblada, la brecha se reduce, pero pnpm generalmente conserva una ventaja.

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.