--- title: "pnpm reescrito em Rust promete acelerar a rotina de quem vive no terminal" author: "Ignácio Afonso" date: "2026-09-06 06:15:00-03" category: "Tecnologia & Desenvolvimento" url: "http://desbugados.scale.press/portal/desbugados/post/2026/09/06/pnpm-reescrito-em-rust-promete-acelerar-a-rotina-de-quem-vive-no-terminal/md" --- ## Resumo - O pnpm 12 ficou estável em 26 de agosto de 2026 com o motor de instalação reescrito em Rust. - A versão mantém compatibilidade com comandos, sinalizadores e formatos de lockfile do pnpm 11. - Instalações limpas passaram de 8,2 segundos para 5 segundos nos benchmarks divulgados. - Instalações repetidas caíram de 472 milissegundos para 15 milissegundos com cache quente. - A Vercel registrou reduções de 64,4% a 90,5% em um monorepo com 21 projetos. - A resolução de dependências cíclicas ficou de duas a três vezes mais rápida e usou 25% menos memória. - O binário do Corepack cresceu, causando um startup inicial 11,1% mais lento em caches vazios. --- 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](https://morello.dev/blog/pnpm-v12-rust-rewrite) 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.