pnpm 12 reescrito en Rust acelera las instalaciones un 90% en entornos con caché
El gestor de paquetes mantiene la compatibilidad con pnpm 11, pero el binario nativo cambia dinámicas de arranque en CI y despliegues frescos.
pnpm ha publicado la versión 12, sustituyendo su implementación en TypeScript y Node.js por una reescritura completa en Rust. El objetivo es reducir la sobrecarga del sistema de archivos y el tiempo de arranque sin obligar a los equipos a renombrar comandos, cambiar la estructura de node_modules o modificar el formato del lockfile. La intención es que el upgrade sea transparente para los flujos de trabajo existentes.
Las mejoras de rendimiento son significativas, especialmente cuando la caché está caliente. En los benchmarks internos de pnpm, una instalación limpia de su fixture pesado bajó de 8,2 segundos a 5 segundos. El cambio más drástico ocurre en instalaciones repetidas: con caché, lockfile y node_modules ya presentes, el tiempo cayó de 472 milisegundos a 15 milisegundos. Esto significa que en entornos de CI donde las dependencias suelen estar en caché, el impacto en el tiempo total del pipeline será notable.
Pruebas en producción y matices
Datos de entornos reales confirman esta tendencia. Socket reportó mediciones en el monorepo de Turborepo de Vercel, que contiene 21 proyectos y 1.670 paquetes. En seis escenarios distintos, las medianas de reducción de tiempo de instalación oscilaron entre un 64,4% y un 90,5%. Sin embargo, hay un trade-off: el artefacto nativo es más grande. Esto hace que el primer arranque sin caché sea un 11,1% más lento, aunque el arranque con caché mejora un 74,7%. Para pipelines que reinstalan la herramienta desde cero cada vez, este incremento inicial puede ser relevante.
La instalación no es automática todavía. La etiqueta latest de npm sigue apuntando a pnpm 11, y gestores como Homebrew, winget o Scoop no han actualizado sus paquetes todavía. Para probarlo, hay que ejecutar pnpm self-update next-12 o usar los scripts standalone.
Cambios técnicos importantes
Aunque la compatibilidad es alta, hay rupturas que pueden romper scripts de CI si no se revisan. Se ha eliminado el flag pnpm install --resolution-only, ahora sustituido por pnpm peers check. Las dependencias de Git en GitHub, GitLab o Bitbucket se resuelven mediante URLs HTTPS canónicas; el acceso SSH privado requiere configurar reescritura de URLs en Git. En Linux, el orden de priorización para enlaces ha cambiado: ahora intenta hardlinks antes que reflinks. Además, las claves desconocidas en pnpm-workspace.yaml ya no se ignoran en silencio, lo que obliga a limpiar configuraciones antiguas.
La versión introduce binarios globales conscientes del proyecto. Un Node.js, Deno o Bun instalado globalmente puede seguir la versión fijada por el proyecto actual. También permite provisionar npm, Yarn o Bun si los necesita una dependencia alojada en Git. La resolución de ciclos ahora es determinista, generando lockfiles byte-a-byte idénticos y acelerando la resolución de peers de dos a tres veces en espacios de trabajo con muchos ciclos, consumiendo un 25% menos de memoria.
La comunidad ha reaccionado con escepticismo controlado. Dennis Morello lo definió como "una actualización de rendimiento disfrazada de versión mayor", destacando que el flujo de trabajo sigue siendo familiar. Darcy Clarke, exmantenedor de npm CLI, señaló que mantener gestores en JavaScript facilita mejorar internals compartidos, a lo que Zoltan Kochan respondió que reescribir en Rust fue más rápido que migrar a ESM. En HackerNews, la discusión derivó hacia la seguridad: mientras algunos defienden npm por su simplicidad ("aburrido es suficientemente bueno"), otros critican su modelo de ejecución de scripts por defecto, calificándolo de peligroso comparado con la estrictura de pnpm.
pnpm se mantiene abierto y diferenciado por su tienda de contenidos direccionables. Aunque Bun sigue publicando benchmarks más rápidos en su propio entorno, pnpm retiró a Bun y Yarn de sus comparaciones públicas por problemas de fiabilidad en los harnesses de prueba.
