pnpm 12.0 reescrito en Rust: installs 2-3× más rápidas

Qué trae pnpm 12.0 y por qué importa

El gestor de dependencias pnpm lanzó su versión 12.0, una reescritura completa del núcleo en Rust que mantiene compatibilidad con los comandos, flags, ajustes y formato del lockfile de la versión 11. Según el anuncio oficial del proyecto, publicado el 27 de agosto, pnpm 12 se instala con pnpm self-update next-12 mientras el canal latest sigue apuntando a la línea 11, y los gestores de paquetes de sistema operativo (Homebrew, winget, Scoop y Chocolatey) aún no lo distribuyen.

La promesa central: los workspaces existentes siguen funcionando, pero la resolución de dependencias es ahora entre 2 y 3 veces más rápida en grafos cíclicos, consume cerca de un 25% menos de memoria y produce lockfiles canónicos byte a byte idénticos entre instalaciones, según documenta el equipo de pnpm.

Lo que cambia de verdad (breaking changes)

El release notes oficial marca cinco rupturas que un founder con un monorepo debe revisar antes de actualizar.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Dependencias Git ahora son identidades, no transportes. Para GitHub, GitLab y Bitbucket, un specifier como github:owner/repo, owner/repo, git+https://… o git+ssh://git@… resuelve siempre por la URL canónica HTTPS del host. El lockfile nunca guarda una URL SSH para esos hosts. Para acceder por SSH a repos privados hay que configurar el rewrite de URL de Git:

git config --global url."[email protected]:".insteadOf https://github.com/

Configuraciones desconocidas en pnpm-workspace.yaml ahora se reportan. Una clave mal escrita (por ejemplo, un typo en minimumReleaseAge) antes se ignoraba en silencio; ahora pnpm falla con ERR_PNPM_UNRECOGNIZED_WORKSPACE_SETTINGS cuando hay un packageManager pinneado, y emite warning en cualquier otro caso.

Lockfiles de grafos cíclicos son byte-idénticos. Los ciclos de dependencias se rompen canónicamente durante la peer resolution: los miembros se ordenan por package id y los cortes de cierre de ciclo se hacen siempre en el mismo lugar. Para workspaces grandes con muchas dependencias cíclicas, esto se traduce en la mejora de 2-3× citada.

packageImportMethod: auto prioriza hardlinks en Linux. En btrfs, un reflink copia extent bookkeeping en los metadatos del filesystem; un hardlink es una sola entrada de directorio, así que auto prueba hardlink primero en Linux. En ext4 no cambia (ya hardlinkaba) y en macOS se mantiene clone-first.

engineStrict ahora sigue la arista, no el subárbol. Bajo engineStrict, un install falla cuando un paquete incompatible se alcanza por una arista de dependencies regular, aunque ese subárbol cuelgue de un optionalDependencies. En pnpm 11 instalaba y emitía un warning.

Lo nuevo que sí aprovecha un equipo chico

Varias funciones aterrizan en pnpm 12 pensadas para el flujo diario de una startup de software.

Bins globales conscientes del proyecto. Si tienes node, deno o bun instalados globalmente, pnpm ahora sigue la versión que el proyecto actual pinnea, sin shell hooks ni comandos tipo use. El ajuste globalShims decide qué paquetes globales reciben este shim y por defecto incluye los tres runtimes.

pnpm aprovisiona otros package managers. pnpm descarga e instala npm, Yarn Classic, Yarn Berry, Yarn 6 y Bun desde los registros oficiales de cada uno, verificando la firma de npm para las versiones npm-published antes de ejecutarlos. Tres usos concretos:

Una dependencia Git-hosted se prepara con el package manager que declara, así un repo construido con Yarn funciona en una máquina que solo tiene pnpm.
pnx yarn@4 install corre un package manager para un solo comando.
pnpm shim add yarn enlaza un yarn que corre lo que el proyecto pinnee.

Nombrar un package manager significa la herramienta, no el paquete npm que comparte el nombre. pnpm add -g yarn@4 instala Yarn Berry; en un proyecto, pnpm add yarn@4 graba "packageManager": "[email protected]", lo que lee Corepack, mientras los demás managers se registran en devEngines.packageManager.

Registry revisions. Un registro puede servir un artefacto de reemplazo para una versión ya publicada (un rebuild con una vulnerabilidad parcheada) sin cambiar el número de versión ni reescribir los bytes de la URL canónica. pnpm lo llama revision, lo direcciona por su SHA-512 completo y lo registra en el lockfile como una línea extra. Una dependencia puede pinear una revision explícitamente como <version>+rN y pnpm update --patches refresca los artefactos sin cambiar una sola versión.

Audit más limpio. audit.ignorePrune: true hace que pnpm audit --fix elimine los GHSA ignorados que ya no aparecen en el reporte, así la lista de advisories tolerados no acumula entradas de dependencias que ya no están.

Comandos globales rechazan sudo. pnpm setup, pnpm self-update y cualquier comando que modifique la instalación global fallan con ERR_PNPM_SUDO_NOT_SUPPORTED bajo sudo, en vez de operar silenciosamente sobre el home del root.

Contexto: por qué el ecosistema se mueve hacia Rust y hacia la seguridad por defecto

pnpm no es el único gestor de dependencias en reescribirse: la migración a Rust responde a la misma lógica que llevó a Deno y Bun a reemplazar piezas en sistemas más rápidos. En paralelo, GitHub anunció que npm v12, con fecha de release en julio de 2026, bloqueará por defecto los install scripts, exigiendo una allowlist explícita en package.json y committeada al repo, según reportó TechTimes el 13 de junio de 2026.

El movimiento responde a una escalada documentada de ataques a la cadena de suministro: 2025 fue el peor año del ecosistema npm con cerca de 455.000 paquetes maliciosos publicados, y el ataque del gusano Miasma del 1 de junio de 2026 comprometió 32 paquetes del namespace oficial @redhat-cloud-services de Red Hat antes de una segunda oleada de 57 paquetes en dos horas usando la técnica «Phantom Gyp», según la misma cobertura de TechTimes. pnpm ya había implementado esta política de bloquear lifecycle scripts por defecto con allowlist explícita en pnpm v10, en enero de 2025, unos 18 meses antes que npm.

La diferencia es relevante para una startup: pnpm 12 hereda esa postura y la refuerza con engineStrict siguiendo la arista, verificación de firmas de npm para otros package managers y un remote side-effects cache firmado y scoped por organización, todavía en prueba de concepto.

Qué significa esto para tu startup

Si tu producto es SaaS y tu stack pasa por Next.js, NestJS, Remix o cualquier framework Node, pnpm suele ser ya la opción más eficiente en disco. La pregunta no es si conviene migrar, sino cuándo.

Acciones concretas para esta semana

En tu monorepo, corre pnpm self-update next-12 en una rama de prueba y verifica que pnpm install --frozen-lockfile siga produciendo un lockfile byte-idéntico. Es la prueba más rápida de que no hay regresión.
Audita tu pnpm-workspace.yaml: cualquier clave con typo va a empezar a fallar con ERR_PNPM_UNRECOGNIZED_WORKSPACE_SETTINGS cuando el proyecto tenga un packageManager pinneado.
Si dependes de paquetes Git por SSH en CI, configura el rewrite de URL de Git en la imagen antes de actualizar, o migra a HTTPS con tokens de fine-grained access.
Revisa tu package.json para confirmar que tu pin de engine (Node, Deno, Bun) coincide con el subtree real, no solo con el root: engineStrict ahora rastrea la arista y puede romper builds que pasaban con warning.

Acciones para los próximos 30 días

Mide tiempos de pnpm install antes y después en CI. La mejora de 2-3× en peer resolution aplica sobre todo a workspaces con dependencias cíclicas (típico en monorepos con plugins compartidos). En repos simples puede no notarse.
Evalúa pnpm shim add yarn o pnpm shim add npm si tu equipo mezcla stacks: permite correr el package manager que cada repo pinnea sin instalar nada global adicional.
Si publicas paquetes, revisa si tu registry soporta revisions. La línea extra en el lockfile (revision: N) es la pieza que habilita parches silenciosos sin cambiar versiones, una ventaja concreta cuando un CVE toca una dependencia transitive.

El rewrite en Rust no es marketing: es lo que hace posible que el lockfile sea una función pura del grafo de dependencias, que los grafos cíclicos resuelvan más rápido y que la herramienta siga siendo mantenible a medida que el ecosistema crece. Para una startup construyendo sobre Node, eso se traduce en CI más rápido, builds más reproducibles y menos superficie de ataque por defecto.