pnpm 12 ya está disponible, y su cambio más importante no es la reescritura en Rust por sí sola: es que los installs deberían ser más fáciles de reproducir entre máquinas, runners de CI y workspaces grandes.
La versión llegó el 26 de agosto de 2026 como v12.0.0. El proyecto presenta pnpm 12 como estable, con el mismo modelo general de comandos, configuración y lockfile que pnpm 11, pero con varios cambios de comportamiento que importan para equipos que cuidan la determinación de sus builds.
La versión corta: las dependencias git se canonicalizan, los ciclos de peer dependencies se resuelven de forma determinista, los settings desconocidos del workspace pueden fallar en lugar de ignorarse en silencio, los shims globales pueden seguir los pins del proyecto, y pnpm puede provisionar otros gestores de paquetes en vez de asumir que ya existen en la máquina.
Eso no es una release cosmética de un gestor de paquetes. Toca reproducibilidad en CI.
¿Qué es pnpm 12?
pnpm 12 es la nueva versión mayor estable de pnpm, reescrita en Rust pero diseñada para mantener familiar el flujo diario de pnpm.
Eso importa porque “reescrito en Rust” puede sonar como advertencia de migración. En este caso, la historia práctica es más acotada. Las notas de la release dicen que el formato del lockfile y el uso normal se mantienen lo suficientemente compatibles como para que los lockfiles existentes sigan funcionando, incluidos los installs congelados.
Los cambios interesantes están alrededor del comportamiento de resolución: cómo pnpm registra dependencias git, cómo maneja ciclos de peers, cómo valida settings de workspace y cómo elige binarios de runtimes o gestores de paquetes dentro de un proyecto.
Para una app pequeña, pnpm 12 puede sentirse como una actualización normal. Para un monorepo, una flota de CI o un equipo que fija versiones de Node, Yarn, Bun o pnpm por proyecto, merece una revisión cuidadosa.
¿Cómo instalar pnpm 12?
Puedes instalar pnpm 12 con las rutas oficiales de instalación de pnpm, pero al 29 de agosto de 2026 el canal todavía importa.
La documentación de instalación de pnpm dice que latest en npm todavía apunta a la línea de pnpm 11, así que pnpm 12 se instala desde el tag next-12. Si ya tienes pnpm v11.10.0 o superior, la ruta documentada es:
pnpm self-update next-12
Si todavía no tienes pnpm instalado, la documentación muestra:
npx get-pnpm next-12
Para el instalador standalone en sistemas POSIX, la documentación muestra:
curl -fsSL https://get.pnpm.io/install.sh | env PNPM_VERSION=next-12 sh -
Esta es la primera advertencia práctica: no copies un comando genérico antiguo de instalación y asumas que te da pnpm 12. Al momento de escribir esta nota, Homebrew, winget, Scoop y Chocolatey también aparecen documentados como canales que todavía no ofrecen pnpm 12.
Eso va a envejecer rápido, así que trata el canal de instalación como una afirmación fechada. Antes de cambiar imágenes de CI o documentación de onboarding, revisa otra vez la página oficial de instalación.
¿Qué cambia en los lockfiles de pnpm 12?
pnpm 12 hace que los lockfiles sean más deterministas cuando los grafos de dependencias contienen ciclos de peer dependencies.
Las notas de la release describen una fuente anterior de ruido: cuando los paquetes formaban ciclos durante la resolución de peers, el lockfile final podía depender del orden en que pnpm recorría el grafo. Eso significaba que el mismo grafo de dependencias podía producir lockfiles distintos después de cambiar el orden de importers, dependencias o resolución.
En pnpm 12, los miembros de cada ciclo se ordenan de forma canónica por package id, y la arista que cierra el ciclo se corta siempre en el mismo lugar.
La frase de la release que conviene recordar es esta: “lockfile is a pure function of the dependency graph”.
Eso es exactamente el tipo de frase que los equipos de CI quieren escuchar. Si dos desarrolladores resuelven el mismo grafo de dependencias, o si un runner de CI re-resuelve después de un cambio de dependencias, el lockfile no debería cambiar solo porque el orden de recorrido fue distinto.
Hay una nota práctica: los lockfiles existentes siguen funcionando. Los installs congelados los consumen sin cambios. El primer install que realmente re-resuelva puede volver a indexar variantes de peers que antes dependían del orden de recorrido.
Entonces la pregunta de migración no es “¿mi lockfile se rompe de inmediato?”. Es “cuando volvamos a resolver dependencias, ¿estamos listos para revisar una normalización de lockfile de una sola vez?”.
¿Qué cambia con las dependencias git?
pnpm 12 trata las dependencias git en hosts conocidos como identidades de repositorio, no como elecciones de transporte.
Para GitHub, GitLab y Bitbucket, distintas formas de nombrar el mismo repositorio ahora se resuelven mediante la URL HTTPS canónica del host. Eso incluye formas abreviadas, formas HTTPS y especificadores estilo SSH. El lockfile ya no debería registrar URLs SSH para esos hosts conocidos.
La razón es práctica: pnpm antes podía probar la red y registrar un transporte que funcionaba en una máquina, pero fallaba en otra. Una laptop de desarrollo con acceso SSH podía producir una entrada de lockfile que luego rompía en un runner de CI sin la misma configuración de claves.
pnpm 12 elimina esa clase de resolución accidentalmente local a una máquina.
Si necesitas SSH para repositorios privados alojados en esos hosts, las notas de la release apuntan a configurar git a nivel de máquina con reescritura de URLs. Así el lockfile del proyecto queda canónico, mientras la máquina decide cómo tiene permitido llegar al repositorio.
Es un buen tradeoff para proyectos compartidos. El lockfile dice qué dependencia hace falta. La máquina decide cómo puede obtenerla.
¿Qué pasa con settings desconocidos en pnpm-workspace.yaml?
pnpm 12 puede fallar cuando pnpm-workspace.yaml contiene un setting que pnpm no reconoce.
Este es uno de los cambios discretos pero importantes. En el comportamiento anterior, un typo en un setting de workspace podía ignorarse en silencio. Las notas de la release usan minimumReleaseAge como ejemplo del tipo de política donde un error de escritura sería peligroso: el equipo cree que un control de supply chain está activo, pero pnpm no lo está aplicando.
pnpm 12 reporta settings de workspace desconocidos y, cuando el proyecto fija una versión de pnpm que la versión en ejecución satisface, falla con ERR_PNPM_UNRECOGNIZED_WORKSPACE_SETTINGS.
Eso es un poco menos permisivo, pero bastante más seguro.
Antes de actualizar un workspace, revisa pnpm-workspace.yaml en busca de settings antiguos, errores de escritura o configuración que pertenecía a otra versión de pnpm. Esto es especialmente importante en monorepos donde la configuración del gestor de paquetes suele acumularse sin mucho ruido.
¿Cómo cambian los shims para Node, Deno, Bun y Yarn?
pnpm 12 permite que bins instalados globalmente sigan el proyecto en el que estás parado.
El nuevo setting globalShims controla qué paquetes instalados globalmente reciben shims conscientes del proyecto. El valor por defecto incluye node, deno y bun.
En la práctica, eso significa que un proyecto que fija Node.js mediante campos de runtime soportados por pnpm puede descargar la versión estable fijada de Node en el primer uso y ejecutarla cuando escribes node dentro del proyecto. Las notas de la release dicen que las versiones estables de Node se autentican contra firmas del equipo de releases de Node.js. Otros candidatos, como Deno, Bun, prereleases de Node.js o bins ordinarios que actives explícitamente, pueden pedir confianza en el proyecto.
Esto importa porque los proyectos JavaScript cada vez fijan no solo dependencias, sino también toolchains. pnpm 12 mueve más de esa selección de toolchain hacia comportamiento consciente del proyecto, en lugar de depender de hooks de shell, convenciones locales o el binario que casualmente aparece primero en PATH.
También hay salidas de emergencia: globalShims: false desactiva la función, y PNPM_SHIM_BYPASS=1 la evita en una invocación.
Para equipos, lo importante es la política. Decide si desarrollo local, CI y agentes de build deberían honrar estos shims, y deja esa decisión explícita.
¿Qué cambia con los package-manager pins?
pnpm 12 puede provisionar otros gestores de paquetes, no solo pnpm.
Las notas de la release dicen que pnpm ahora maneja npm, Yarn Classic, Yarn Berry, Yarn 6 y Bun mediante registros confiables de gestores de paquetes, con verificación de firma cuando aplica para gestores publicados en npm.
Esto aparece en tres lugares.
Primero, una dependencia alojada en git puede prepararse con el gestor de paquetes que pide. Si una dependencia fija Yarn, pnpm puede proveer la versión requerida de Yarn en lugar de asumir que la máquina ya la tiene.
Segundo, pnpm dlx puede ejecutar directamente un gestor de paquetes. Las notas de la release muestran ejemplos como:
pnx yarn@4 install
pnx npm@11 ci
pnx bun@1.3.0 install
Tercero, pnpm shim add yarn puede crear un comando que ejecuta la versión fijada por el proyecto actual.
Esto es un cambio de comportamiento frente a tratar nombres como yarn o node como paquetes ordinarios de npm. En pnpm 12, esos nombres pueden referirse al gestor de paquetes o runtime real.
Es útil, pero puede sorprender a scripts que dependían del significado anterior. Audita instalaciones globales, scripts de bootstrap y documentación de setup antes de asumir que pnpm add -g yarn o pnx node significan lo mismo que en pnpm 11.
¿Qué deberías revisar antes de actualizar CI?
Antes de actualizar CI a pnpm 12, revisa los lugares donde el comportamiento de instalación cruza límites entre máquinas.
Empieza por la ruta de instalación del gestor de paquetes. Si tu imagen de CI usa npm latest, Homebrew, winget, Scoop o Chocolatey, verifica si esos canales realmente entregan pnpm 12 al momento de hacer el cambio.
Después revisa dependencias git. Si tu lockfile actualmente registra URLs SSH para dependencias de GitHub, GitLab o Bitbucket, espera una ruta de re-resolución hacia una identidad HTTPS canónica. Para repositorios privados, configura reescritura de git a nivel de máquina en lugar de codificar el transporte SSH dentro del proyecto.
Luego revisa pnpm-workspace.yaml. Un setting con typo que antes quedaba escondido en silencio ahora puede hacer fallar un comando, que es exactamente lo que quieres de un archivo de políticas, pero conviene detectarlo antes de un build productivo.
Después, revisa scripts que mencionan gestores de paquetes y runtimes por nombre. yarn, npm, bun, node y deno pueden participar ahora en el comportamiento de provisioning y shims de pnpm. Eso es una ventaja cuando quieres hacer cumplir pins de proyecto, y una fuente de confusión si tu CI espera que los binarios globales ignoren el proyecto.
Por último, prepárate para una normalización de lockfile de una sola vez cuando un cambio de dependencias dispare una re-resolución. Los installs congelados deberían seguir funcionando con lockfiles existentes, pero la siguiente actualización real de dependencias puede producir un lockfile más limpio y determinista.
¿Por qué pnpm 12 importa para desarrolladores en Iberoamerica?
pnpm 12 importa porque los installs reproducibles ya no son una preocupación abstracta. Deciden si un equipo puede confiar en CI, incorporar desarrolladores rápido y moverse entre máquinas locales, contenedores y runners sin perder horas por deriva del gestor de paquetes.
La release no se trata solo de velocidad, aunque pnpm reporta resolución de peers más rápida y menor uso de memoria en workspaces grandes con muchos ciclos. La historia más importante es control.
Un lockfile no debería depender de suerte en el recorrido del grafo. Una dependencia git no debería depender de la configuración SSH de la laptop que la resolvió por primera vez. Un setting de seguridad del workspace no debería desaparecer por un typo. Un pin de proyecto debería significar lo mismo en una máquina de desarrollo y dentro de CI.
Ese es el valor práctico de pnpm 12.
Si tu proyecto es pequeño, la actualización puede ser casi aburrida. Si tu workspace es grande, antiguo o compartido entre varios entornos, pnpm 12 merece una prueba con intención: ejecútalo en una rama, re-resuelve una vez, inspecciona el diff del lockfile, revisa settings de workspace y actualiza CI solo después de entender qué cambios son limpieza determinista y cuáles afectan tus propios scripts.
El gestor de paquetes es infraestructura. pnpm 12 vuelve más explícita esa infraestructura.