O pnpm 12 chega reescrito em Rust e instalando npm, Yarn e Bun por você

O pnpm 12 saiu estável em 26 de agosto de 2026 e traz uma mudança estrutural: é uma reescrita completa do gerenciador de pacotes em Rust↳Rust7 conteúdosDesmistificando Rust: a linguagem segura e rápida que você precisa conhecerDev (Back & Front) · out 2024Como criar seu primeiro Programa em Rust com Solana PlaygroundDev (Back & Front) · mai 2026Rust no ranking: a segurança de memória perdeu a guerra corporativa?Marketing Tech · abr 2026Ver tudo em Dev (Back & Front) →. Segundo Zoltan Kochan, mantenedor líder do projeto, a virada de versão foi feita de propósito para não ser uma migração. Comandos, flags, configurações e o formato do lockfile do pnpm 11 seguem valendo, e a documentação cobre as duas versões em paralelo.

Na prática, quem já usa pnpm no dia a dia pode atualizar sem reescrever scripts de CI nem tocar no pnpm-lock.yaml. A lista do que realmente se comporta diferente está concentrada na página What's different in pnpm 12, e o restante do release é adição.

Como instalar

A tag latest no npm ainda aponta para a linha do pnpm 11. Para pegar o 12, é preciso usar a tag next-12:

pnpm self-update next-12

Homebrew, winget, Scoop e Chocolatey ainda não oferecem a versão 12 no lançamento, então quem usa esses instaladores precisa esperar ou seguir pelas outras formas descritas em Installing pnpm 12.

O ganho de performance vem da reescrita em Rust

O argumento histórico do pnpm sobre os concorrentes sempre foi velocidade e economia de disco via store com hardlinks. A reescrita em Rust ataca justamente os pontos onde o resolvedor ainda era pesado.

A mudança mais concreta está na resolução de peers em grafos com ciclos de dependência. O pnpm 12 quebra os ciclos de forma canônica: os membros de cada ciclo são ordenados por id de pacote e as arestas que fecham o ciclo são sempre cortadas no mesmo ponto, não importa por onde a instalação entra no ciclo. O resultado é que o lockfile vira uma função pura do grafo de dependências: importadores reordenados, dependências reordenadas e instalações repetidas produzem lockfiles byte a byte idênticos, o que antes não acontecia (#13846, #13865).

Em workspaces grandes e cheios de ciclos, a resolução de peers ficou 2 a 3 vezes mais rápida, usa cerca de 25% menos memória e gera um lockfile substancialmente menor. Lockfiles existentes continuam funcionando: --frozen-lockfile os consome sem alteração.

No Linux↳Linux34 conteúdosKali Linux em um Servidor VPS: como, quando e por que usar?DevSecOps · dez 2024Construindo um Windows Service ou Linux Daemon com Worker Service & .NET Core – Parte 2Dev (Back & Front) · jul 2020Criando uma WebApi utilizando .NET, Linux e VSCodeDev (Back & Front) · ago 2019Ver tudo em DevSecOps →, o packageImportMethod: auto agora tenta o hardlink antes do reflink. Segundo o release, num sistema de arquivos btrfs isso praticamente reduz pela metade o tempo que a instalação gasta materializando node_modules a partir de um store aquecido. O ext4 não muda (clonagem nunca foi suportada ali) e o macOS mantém clone-first via APFS clonefile.

pnpm agora instala npm, Yarn e Bun

A novidade que mais mexe com a rotina de quem lida com repositórios variados: o pnpm 12 passa a provisionar os outros gerenciadores (npm, Yarn Classic, Yarn Berry, Yarn 6 e Bun), buscando cada um pelos registries confiáveis e verificando a assinatura npm da versão exata antes de rodar.

Isso destrava três coisas:

• Uma dependência hospedada em git é preparada com o gerenciador que ela pede, então um repositório construído com Yarn instala numa máquina que só tem pnpm.
• O comando pnx roda um gerenciador para uma única operação: pnx yarn@4 install, pnx npm@11 ci, pnx node@22.
• pnpm shim add yarn cria um yarn que roda o que o projeto atual fixa.

Há uma sutileza de nomenclatura importante: nomear um gerenciador passa a significar a ferramenta, não o pacote npm de mesmo nome. pnpm add -g yarn@4 instala o Yarn Berry, e dentro de um projeto pnpm add yarn@4 grava "packageManager": "yarn@4.18.0" (o campo que o Corepack lê). Para instalar o pacote npm chamado yarn, é preciso ser explícito: pnpm add yarn@npm:yarn@1.22.22.

Global bins com consciência do projeto

Um node, deno ou bun instalado globalmente passa a seguir a versão que o projeto atual fixa, sem shell hooks nem comandos no estilo use. A configuração globalShims escolhe quais pacotes globais ganham esse shim e vem com { node: true, deno: true, bun: true } por padrão.

Release estável do Node.js é autenticada contra as assinaturas do time de release e troca sem perguntar. Deno, Bun, prereleases e bins comuns perguntam Do you trust this project? uma vez por projeto e por candidato, guardando a resposta localmente. PNPM_SHIM_BYPASS=1 ignora o recurso numa invocação.

Segurança e reprodutibilidade

Várias mudanças endurecem a operação, num momento em que ataques à cadeia de suprimentos do npm são preocupação recorrente para quem constrói software no Brasil:

• Comandos globais recusam rodar sob sudo, falhando com ERR_PNPM_SUDO_NOT_SUPPORTED em vez de operar silenciosamente na home do root.
• Configuração desconhecida no pnpm-workspace.yaml é reportada. Antes, um minimumReleaseAge digitado errado sumia em silêncio, derrubando a política que deveria aplicar. Agora sugere o nome mais próximo e, quando o projeto fixa uma versão de pnpm que a que roda satisfaz, falha com ERR_PNPM_UNRECOGNIZED_WORKSPACE_SETTINGS.
• Revisões de registry: um registry pode servir um artefato de substituição para uma versão já publicada (um rebuild com vulnerabilidade corrigida) sem mudar o número da versão. O pnpm endereça o artefato pelo digest SHA-512 completo e o registra no lockfile como uma linha extra (revision: 1). Um lockfile que não adotou substituições fica byte a byte idêntico ao de hoje.
• Dependências git viram identidades: github:owner/repo, owner/repo e as variantes git+https/git+ssh resolvem todas pela URL HTTPS canônica do host, e o lockfile nunca grava URL SSH para esses hosts.

Correção que evita quebra com TypeScript 7

Uma correção merece atenção de quem já testa o TypeScript 7: o banco de compatibilidade embutido deixou de adicionar dependências detectadas por análise estática de pacotes publicados. Essas entradas nomeavam pacotes que um dependente só importa para tipos, e instalá-las podia quebrar tudo. O exemplo citado: @typescript-eslint/types ganhava uma dependência de typescript resolvida para a release mais nova, colocando TypeScript 7 sob versões antigas do @typescript-eslint e fazendo o ESLint falhar com Cannot read properties of undefined (reading 'Intrinsic').

Outros recursos como o cache remoto de side-effects (prova de conceito, restaurando só em Linux/glibc x64 e arm64 por enquanto), a aprovação em lote para publicação em stage (pnpm stage approve) e o audit.ignorePrune também chegam. Vale notar que alguns deles (registry revisions, cache remoto, audit.ignorePrune, aprovação em lote e o pin do pnpm init) já foram entregues também no pnpm 11.25; o resto é exclusivo do 12 por depender da reescrita em Rust.

O que fica em aberto

O release não traz números de benchmark comparando o pnpm 12 diretamente com npm e Yarn no cenário completo de instalação, apenas os ganhos internos de resolução de peers. Também não há data para a tag latest migrar do pnpm 11 para o 12, nem para os instaladores de sistema (Homebrew, winget, Scoop, Chocolatey) passarem a oferecer a versão. Para times brasileiros que rodam CI com esses gerenciadores, isso significa continuar fixando a tag next-12 explicitamente por enquanto. O projeto pede que problemas sejam reportados no repositório.

Fonte: Hacker News