O pnpm 12 foi reescrito em Rust e promete install mais rápido no CI sem mudar o fluxo

O pnpm lançou a versão 12 substituindo sua implementação em TypeScript↳TypeScript23 conteúdosTypeScript: ReadonlyArrayDev (Back & Front) · jun 2019Onde usar ANY no TypeScriptDev (Back & Front) · out 2025Tudo sobre o Node rodar TypeScript nativamente!Dev (Back & Front) · jul 2025Ver tudo em Dev (Back & Front) → e Node.js por uma reescrita nativa em Rust. A jogada, segundo reportagem da InfoQ, foi feita de propósito para não obrigar ninguém a reaprender a ferramenta: comandos, flags, configurações, formato de lockfile e layout do node_modules do pnpm 11 continuam iguais. Em outras palavras, é uma troca de motor sem trocar o volante.

Para quem constrói software no Brasil e roda pnpm em pipeline de CI/CD↳CI/CD23 conteúdosCI/CD Mobile: o caos invisível que separa times comuns de times de alta performanceDev (Back & Front) · abr 2026Lambda: implementando com GitLab CI/CD e Terraform para Integração SFTP, S3 e Databricks em GoDev (Back & Front) · nov 2023Publicando sua aplicação Web Python no WebApp do Azure e configurando o CI/CD da sua aplicaçãoDevSecOps · abr 2019Ver tudo em DevSecOps →, esse é o ponto que importa: o ganho de velocidade chega sem migração dolorosa. Mas o texto que segue separa o que a fonte mede do que ainda fica em aberto.

Onde o ganho aparece de verdade

A melhora é mais pronunciada quando já existe cache ou node_modules. Nos benchmarks mantidos pelo próprio pnpm, um install limpo do fixture pesado em arquivos caiu de 8,2 segundos na implementação anterior para 5 segundos com Rust. Já um install repetido com cache, lockfile e node_modules aquecidos despencou de 472 milissegundos para 15 milissegundos.

Na prática, é o segundo cenário que costuma dominar o dia a dia: builds incrementais, jobs de CI com cache restaurado, containers que reusam camadas. É aí que a diferença deixa de ser detalhe.

Teste independente em monorepo grande

A InfoQ cita teste da Socket em produção sobre o workspace Turborepo da Vercel: 21 projetos e 1.670 pacotes. Os números medianos de redução de tempo de install ficaram entre 64,4% e 90,5% em seis cenários diferentes.

Há uma ressalva importante e honesta na própria medição: o artefato nativo do Corepack ficou maior, o que tornou o primeiro startup sem cache 11,1% mais lento. Em compensação, o startup com cache melhorou 74,7%. Ou seja, o binário nativo troca um custo inicial pontual por ganhos consistentes depois. Para pipelines que sobem do zero raramente e reusam cache com frequência, o trade-off tende a favorecer o pnpm 12.

Como instalar e o que ainda não está disponível

A instalação da nova versão é feita com:

pnpm self-update next-12

Atenção ao detalhe operacional: a tag latest do npm ainda aponta para o pnpm 11, e no lançamento Homebrew, winget, Scoop e Chocolatey não ofereciam a versão 12. O guia de instalação também traz opções via npm e via script standalone, incluindo instalação sem Node.js. Para quem automatiza provisionamento de runners, vale checar por qual canal o pnpm chega antes de assumir que latest já é o 12.

A quebra mais provável de pegar no CI

A migração é pensada para ser mínima, mas há um ponto que merece revisão antes de subir: a remoção de pnpm install --resolution-only, agora substituído por pnpm peers check. Se você tem esse comando em algum step de pipeline, ele vai quebrar. Além disso:

• Dependências Git hospedadas em GitHub, GitLab ou Bitbucket passam a resolver por URLs HTTPS canônicas; acesso privado por SSH deve ser configurado via rewriting de URL Git.
• No Linux, o pnpm agora tenta hardlinks antes de reflinks.
• Chaves desconhecidas em pnpm-workspace.yaml passam a ser reportadas em vez de silenciosamente ignoradas, o que pode transformar um typo antigo em erro visível.

O guia de compatibilidade é a leitura obrigatória antes de promover a versão em produção.

Novidades além da velocidade

O pnpm 12 também traz binários globais cientes do projeto: um Node.js, Deno ou Bun instalado globalmente pode seguir o runtime fixado pelo projeto atual. O pnpm consegue provisionar npm, Yarn e o próprio Bun, incluindo o gerenciador de pacotes pedido por uma dependência hospedada em Git.

Além disso, o tratamento determinístico de ciclos produz lockfiles byte a byte idênticos e, segundo as notas de release, torna a resolução de peers de duas a três vezes mais rápida em workspaces com muitos ciclos, usando cerca de 25% menos memória. Para monorepos grandes com dependências circulares, esse é um alívio concreto de recursos no runner.

O que a comunidade está discutindo

A reação girou em torno de performance de tooling nativo e seus trade-offs. O engenheiro frontend Dennis Morello descreveu o release como um lançamento de performance vestindo número de versão maior, destacando que o fluxo visível segue familiar.

Em discussão coberta pela Socket, o ex-mantenedor da CLI do npm Darcy Clarke argumentou que manter gerenciadores de pacotes em JavaScript facilita melhorar os internos compartilhados. A resposta do mantenedor do pnpm, Zoltan Kochan, foi direta:

Foi mais rápido reescrever o pnpm em Rust do que migrar para ESM.

Zoltan Kochan, mantenedor do pnpm

No HackerNews, um comentarista defendeu que, para ele, o npm ainda é a melhor escolha por ser estável e default, dispensando instalar outra ferramenta no CI. Outros rebateram apontando segurança: o npm roda scripts de ciclo de vida das dependências por padrão, algo que exige opt-out explícito, e por isso vários já migraram para o pnpm.

O que fica em aberto

Contra npm, Yarn e Bun, o pnpm continua se diferenciando pelo store endereçável por conteúdo, layout estrito de dependências e agora um binário nativo. O Bun ainda publica resultados mais rápidos na própria suíte de benchmark, mas o pnpm removeu Bun e Yarn de sua comparação pública após problemas no harness de benchmark tornarem rankings amplos pouco confiáveis. Ou seja: comparar velocidade entre gerenciadores segue um terreno com ressalvas, e o número que importa é o do seu próprio pipeline, com seu cache e seu monorepo.

Para equipes brasileiras que já rodam pnpm, o caminho razoável é testar o next-12 num branch de CI, medir install repetido com cache quente e conferir se algum step usa --resolution-only antes de promover.

Fonte: InfoQ