O pnpm 12 tornou-se estável em 26 de agosto de 2026 com o motor principal de instalação reescrito em Rust, uma mudança que atinge diretamente a rotina de quem baixa dependências pelo terminal. A atualização preserva a compatibilidade com comandos, sinalizadores e formatos de lockfile usados na versão 11, enquanto os testes registraram quedas expressivas no tempo de instalação. Em termos práticos, a equipe trocou uma parte central da implementação sem exigir que os projetos abandonassem os arquivos e hábitos que já utilizavam. A história é conhecida para quem acompanha sistemas críticos: modernizar o motor sem interromper o serviço costuma ser mais difícil do que simplesmente construir uma ferramenta nova.

A reescrita por trás do comando

A composição técnica do novo pacote ajuda a entender o tamanho da intervenção. A versão 12 é formada por 65,9% de Rust e 33,5% de TypeScript, linguagem que fazia parte da implementação anterior, e também remove o launcher do Node.js, a camada que iniciava o processo antes da execução do gerenciador. O resultado é um binário nativo, isto é, um programa compilado para ser executado diretamente pelo sistema operacional, com menos etapas de preparação antes da instalação. A análise publicada pela Morello.dev descreve justamente essa retirada do launcher como uma forma de reduzir o custo de execução, o que leva a discussão para além da simples troca de linguagem.

Essa decisão também revela a razão prática apresentada pela equipe. Zoltan Kochan, mantenedor do pnpm, afirmou que reescrever o motor em Rust foi mais rápido do que migrar a base para ESM, o formato de módulos usado em projetos JavaScript. A escolha, portanto, não foi apresentada como uma rejeição ao código existente, mas como uma alternativa de desenvolvimento para chegar a um motor de instalação mais veloz sem reconstruir a base seguindo outro modelo de módulos. O ponto que interessa aos usuários aparece na camada de compatibilidade: comandos, sinalizadores e formatos de lockfile da versão 11 continuam reconhecidos pelo pnpm 12, preservando a ponte entre a implementação antiga e a nova.

Velocidade medida no terminal

Quando a instalação começa sem reaproveitar os resultados de uma execução anterior, o ganho aparece na comparação mais direta divulgada pelos testes. Uma instalação limpa caiu de 8,2 segundos no pnpm 11 para 5 segundos no pnpm 12. Nesse tipo de medição, o objetivo é observar o tempo necessário para montar a instalação sem contar com o benefício de arquivos já preparados em execuções passadas. O número não transforma toda instalação em uma operação instantânea, mas mostra que a troca do motor reduziu uma etapa que se repete em projetos novos, ambientes de integração e máquinas que ainda não têm os pacotes disponíveis localmente. A diferença fica ainda mais acentuada quando o terminal trabalha com dados já armazenados.

Nas instalações repetidas, o resultado foi de 472 milissegundos para 15 milissegundos, de acordo com os benchmarks divulgados sobre o pnpm 12. Esse é o chamado cache quente, situação em que os arquivos e informações necessários já estão disponíveis e o gerenciador não precisa refazer todo o trabalho de busca e preparação. Em instalações frias, nas quais esse reaproveitamento ainda não existe, a redução informada foi de aproximadamente 1,6 vez. A distinção importa porque um projeto pode alternar entre os dois tipos de execução: a primeira instalação de uma máquina mede uma coisa, enquanto os comandos repetidos durante o desenvolvimento medem outra. É nessa segunda rotina que a remoção do launcher Node.js tende a aparecer com mais clareza.

O efeito em projetos maiores

Essa diferença ganha peso em um monorepo, estrutura que reúne vários projetos relacionados dentro de um mesmo repositório. A Vercel informou reduções de tempo entre 64,4% e 90,5% em seu monorepo com 21 projetos, uma medição que aproxima a promessa do pnpm 12 da rotina de equipes que instalam dependências repetidamente em várias partes do mesmo código. A quantidade de projetos é relevante porque cada instalação pode repetir tarefas de resolução e preparação, ampliando o tempo acumulado ao longo do dia. O dado também desloca a conversa do terminal individual para o trabalho compartilhado, em que uma melhoria por execução pode aparecer muitas vezes em testes e atualizações.

Além do tempo total, o pnpm 12 modificou a resolução de dependências cíclicas, situação em que pacotes acabam dependendo uns dos outros em um ciclo. Segundo os dados divulgados, esse processo ficou de duas a três vezes mais rápido e passou a usar 25% menos memória. A melhoria ataca uma parte diferente da instalação: em vez de apenas iniciar o programa mais depressa, ela reduz o trabalho necessário para organizar relações complexas entre pacotes. Para quem mantém um monorepo com várias conexões internas, essa distinção ajuda a explicar por que os ganhos medidos pela Vercel não dependem exclusivamente do tempo de inicialização. O motor também recebeu ajustes no modo como interpreta a estrutura de dependências.

Compatibilidade e limites da troca

Há, porém, uma conta visível nessa modernização. O binário do Corepack, ferramenta usada para disponibilizar gerenciadores de pacotes, cresceu de 17,5 MB para 47,3 MB. Em máquinas com cache vazio, esse tamanho maior produziu um startup inicial 11,1% mais lento. O dado não contradiz os ganhos observados depois: ele mostra que a primeira preparação e as execuções seguintes medem etapas diferentes. O pnpm 12 começa em desvantagem quando precisa ser carregado sem nenhum dado reaproveitado, mas recupera essa diferença nos testes de repetição, nos quais a remoção do launcher e o binário nativo têm maior influência. A troca, portanto, envolve uma escolha mensurável entre custo inicial e velocidade de uso contínuo.

Os primeiros ajustes posteriores também mostram que a migração não encerrou o trabalho de manutenção. A versão pnpm 12.3.2 corrigiu o tratamento de sinalizadores booleanos, incluindo --unsafe-perm e --offline. A equipe ainda removeu benchmarks que comparavam o pnpm com Bun e Yarn depois de identificar falhas de teste na metodologia, passando a concentrar as comparações em medições internas e contra o npm. Essa decisão reduz o alcance de algumas manchetes sobre velocidade, mas melhora a leitura dos números disponíveis, porque separa os resultados que podem ser repetidos dentro do próprio projeto das comparações externas afetadas por problemas de teste. A compatibilidade declarada com a versão 11 permanece como a parte mais concreta da transição.

O próximo passo para quem usa pnpm

Para os projetos que já utilizavam o pnpm 11, a mudança foi desenhada para preservar o caminho conhecido: comandos, sinalizadores e formatos de lockfile continuam compatíveis, e o contexto consolidado da atualização informa que não há necessidade de migração manual. Isso significa que a adoção pode ser avaliada observando o comportamento real das instalações limpas e repetidas do próprio projeto, sem tratar o número máximo dos benchmarks como garantia universal. A compatibilidade reduz o trabalho de adaptação, enquanto os testes locais ajudam a mostrar se o ganho aparece mais na inicialização, no cache quente ou na resolução de dependências. O próximo passo depende, portanto, de medir o uso que o time realmente faz do terminal.

A versão estável pode ser obtida pelo comando pnpm self-update next-12, conforme a informação publicada sobre o lançamento, mas a leitura dos resultados precisa considerar os dois lados da atualização. O pnpm 12 entrega instalações repetidas muito mais rápidas e melhorias na resolução de dependências cíclicas, ao mesmo tempo que traz um binário maior e um primeiro startup mais lento quando o cache está vazio. A reescrita em Rust preservou a interface esperada pelos projetos existentes, enquanto deslocou o custo de execução para um programa nativo. Para quem vive no terminal, essa é a medida concreta da mudança: menos espera nas repetições, sem abandonar os arquivos e comandos que sustentaram a versão anterior.