pnpm vs npm vs yarn vs Bun: Comparativo Completo de Gerenciadores de Pacotes 2026

Todo projeto JavaScript começa com uma escolha: qual gerenciador de pacotes? Por anos, npm era o padrão. Daí veio o yarn prometendo instalações mais rápidas. Depois o pnpm alegou economizar gigabytes de espaço em disco. E agora o gerenciador de pacotes integrado do Bun diz que vai tornar tudo obsoleto.

Mas aqui tá o que ninguém te conta: o "melhor" gerenciador de pacotes depende totalmente do seu caso de uso específico, e seguir benchmarks cegamente pode te levar pro caminho errado. Um gerenciador de pacotes perfeito pro projeto pessoal de um dev pode ser péssimo pra um monorepo de 500 pacotes—e vice-versa.

Esse guia corta o papo furado do marketing. Depois de testes extensivos em diferentes tamanhos de projetos e configurações em janeiro de 2026, aqui tá o que realmente importa pra cada gerenciador de pacotes, quando usar e como migrar se precisar.

📌 Nota de Versão: Essa comparação cobre npm 11.x, yarn 4.x (Berry), pnpm 10.x e Bun 1.3 até janeiro de 2026.

O Veredito Rápido

Se você tá com pressa, aqui vai a versão curta:

Agora vamos ver por quê.

Os Competidores: Estado Atual 2026

npm 11.x

• Status: Ainda é o padrão, vem com o Node.js
• Última versão: npm 11.7.0 (dezembro 2025)
• Filosofia: Compatibilidade acima de inovação
• Força principal: Funciona em todo lugar, sempre

O npm evoluiu bastante. A estrutura de node_modules agora tá mais otimizada, e recursos como npm audit viraram padrão da indústria. Mas a abordagem conservadora do npm significa que raramente é o mais rápido ou eficiente—só é o mais confiável.

yarn 4.x (Berry)

• Status: Reescrita completa do yarn 1.x
• Última versão: yarn 4.12.0 (janeiro 2026)
• Filosofia: Inovação através do Plug'n'Play (PnP)
• Força principal: Zero-installs, arquitetura de plugins

Yarn Berry é essencialmente um produto diferente do yarn 1. O recurso Plug'n'Play elimina completamente o node_modules, usando em vez disso um arquivo .pnp.cjs que mapeia imports diretamente pra arquivos zip. É radical—e divisivo.

pnpm 10.x

• Status: A alternativa "inteligente"
• Última versão: pnpm 10.27.0 (dezembro 2025)
• Filosofia: Eficiência sem quebrar compatibilidade
• Força principal: Armazenamento endereçável por conteúdo, deduplicação real

A abordagem do pnpm é elegante: armazena todos os pacotes uma vez num store global endereçável por conteúdo, depois usa hard links pra fazer eles aparecerem no node_modules de cada projeto. Você ganha a compatibilidade da estrutura tradicional node_modules com economia massiva de disco.

Gerenciador de Pacotes Bun 1.3

• Status: O novo desafiante
• Última versão: Bun 1.3.0 (1 de janeiro de 2026)
• Filosofia: Velocidade acima de tudo
• Força principal: Velocidade nativa, zero configuração, capacidades full-stack

Bun não é só um gerenciador de pacotes—é um runtime JavaScript completo. O Bun 1.3 trouxe recursos de desenvolvimento full-stack, APIs de banco de dados unificadas, e melhorias de performance adicionais. Seu comando bun install é frequentemente 10-30x mais rápido que npm pra instalações cold.

Resultados de Benchmark: Performance de Instalação Cold

Vamos começar com o que todo mundo quer saber—velocidade pura. Testamos cada gerenciador nos mesmos projetos com caches limpas:

Projeto Pequeno (50 dependências)

Projeto: Starter típico React + TypeScript
Dependências: 50 diretas, ~400 total

Tempos de Instalação Cold (cache limpa):
┌────────────┬──────────┬───────────────┐
│ Gerenciador│ Tempo    │ vs npm        │
├────────────┼──────────┼───────────────┤
│ bun        │ 0.8s     │ 18x mais rápido │
│ pnpm       │ 4.2s     │ 3.4x mais rápido│
│ yarn       │ 6.8s     │ 2.1x mais rápido│
│ npm        │ 14.3s    │ base          │
└────────────┴──────────┴───────────────┘

Projeto Médio (200 dependências)

Projeto: App Next.js 15 com libs comuns
Dependências: 200 diretas, ~1.200 total

Tempos de Instalação Cold (cache limpa):
┌────────────┬──────────┬───────────────┐
│ Gerenciador│ Tempo    │ vs npm        │
├────────────┼──────────┼───────────────┤
│ bun        │ 2.1s     │ 22x mais rápido │
│ pnpm       │ 12.4s    │ 3.7x mais rápido│
│ yarn       │ 18.2s    │ 2.5x mais rápido│
│ npm        │ 46.1s    │ base          │
└────────────┴──────────┴───────────────┘

Monorepo Grande (15 pacotes, 800 dependências)

Projeto: Monorepo Turborepo com 15 pacotes
Dependências: 800 diretas, ~3.500 total

Tempos de Instalação Cold (cache limpa):
┌────────────┬──────────┬───────────────┐
│ Gerenciador│ Tempo    │ vs npm        │
├────────────┼──────────┼───────────────┤
│ bun        │ 4.8s     │ 28x mais rápido │
│ pnpm       │ 28.6s    │ 4.7x mais rápido│
│ yarn       │ 52.3s    │ 2.6x mais rápido│
│ npm        │ 134.2s   │ base          │
└────────────┴──────────┴───────────────┘

Insight Chave: A vantagem do Bun aumenta com o tamanho do projeto. Pra monorepos, a diferença é absurda.

Performance de Instalação Warm

Mas instalações cold não são tudo. Na maioria das vezes, você tá instalando com algum nível de cache:

Instalação Warm (lockfile existe, algum cache):
┌────────────┬──────────────┬──────────────┐
│ Gerenciador│ Pequeno (50) │ Grande (800) │
├────────────┼──────────────┼──────────────┤
│ bun        │ 0.3s         │ 1.2s         │
│ pnpm       │ 1.1s         │ 8.4s         │
│ yarn (PnP) │ 0.0s*        │ 0.0s*        │
│ npm        │ 3.2s         │ 24.6s        │
└────────────┴──────────────┴──────────────┘

* Zero-installs: dependências commitadas no repo

O Truque de Zero-Installs do Yarn: Com modo PnP e zero-installs, o yarn commita suas dependências diretamente no repositório. Runs de CI/CD não precisam de tempo de instalação—só yarn e pronto. O tradeoff? O tamanho do seu repo aumenta bastante.

Uso de Disco: Onde o pnpm Brilha

Velocidade pura é uma coisa, mas e seu disco rígido?

Uso de Disco em Projeto Único

Mesmo projeto de 200 dependências:
┌────────────┬──────────────┬──────────────┐
│ Gerenciador│ node_modules │ vs npm       │
├────────────┼──────────────┼──────────────┤
│ npm        │ 487 MB       │ base         │
│ yarn       │ 502 MB       │ +3%          │
│ pnpm       │ 124 MB*      │ -75%         │
│ bun        │ 461 MB       │ -5%          │
└────────────┴──────────────┴──────────────┘

* pnpm usa hard links pro store global

Múltiplos Projetos (Mesmas Dependências)

É aqui que a arquitetura do pnpm compensa. Se você tem 10 projetos usando React 19:

10 Projetos com dependências sobrepostas:
┌────────────┬──────────────┬──────────────┐
│ Gerenciador│ Disco Total  │ vs npm       │
├────────────┼──────────────┼──────────────┤
│ npm        │ 4.87 GB      │ base         │
│ yarn       │ 5.02 GB      │ +3%          │
│ pnpm       │ 612 MB       │ -87%         │
│ bun        │ 4.61 GB      │ -5%          │
└────────────┴──────────────┴──────────────┘

O pnpm armazena cada versão única de pacote exatamente uma vez. Todo projeto linka pra aquela cópia única. Se você trabalha em muitos projetos, pnpm pode economizar dezenas de gigabytes.

A Abordagem do Bun: Bun usa um cache global mas ainda cria diretórios node_modules completos. É mais rápido que npm/yarn mas não alcança a deduplicação do pnpm.

Suporte a Monorepo Comparado

Monorepos viraram o padrão pra muitas organizações. Veja como cada gerenciador lida com eles:

Configuração de Workspace

npm (workspaces):

// package.json
{
  "workspaces": ["packages/*", "apps/*"]
}

pnpm (pnpm-workspace.yaml):

# pnpm-workspace.yaml
packages:
  - 'packages/*'
  - 'apps/*'

Comparação de Recursos de Workspace

Conclusão: pnpm e yarn são líderes claros pra gerenciamento de monorepos. O suporte de workspaces do npm é funcional mas básico. O do Bun tá melhorando rápido mas ainda correndo atrás.

Recursos de Segurança

Segurança virou preocupação de primeira classe. Veja como cada gerenciador lida:

Capacidades de Auditoria

Nota Crítica: Bun atualmente não tem auditoria de segurança integrada. Pra aplicações de produção, você vai precisar de ferramentas terceiras como Snyk ou Socket.

Segurança do Lockfile

Os quatro gerenciadores usam lockfiles pra garantir instalações reproduzíveis:

• npm: package-lock.json (JSON)
• yarn: yarn.lock (formato customizado)
• pnpm: pnpm-lock.yaml (YAML)
• Bun: bun.lockb (binário)

O Lockfile Binário do Bun: O bun.lockb do Bun é binário pra velocidade. Enquanto isso deixa instalações mais rápidas, não é legível por humanos e não dá pra fazer diff fácil em code review.

Verificação de Compatibilidade

Aqui tá o que ninguém menciona: nem todo pacote funciona perfeitamente com todo gerenciador.

Problemas de Compatibilidade Conhecidos (Janeiro 2026)

pnpm:

• Alguns pacotes quebram com a estrutura estrita de node_modules
• Solução: shamefully-hoist=true no .npmrc
• A maioria dos pacotes principais agora suporta pnpm nativamente

yarn PnP:

• Muitos pacotes ainda não suportam modo PnP
• Solução: nodeLinker: node-modules volta pra estrutura tradicional
• Adoção tá melhorando mas ainda incompleta

Bun:

• ~98% de compatibilidade com npm (subiu de 95% em 2025)
• Alguns módulos nativos ainda têm problemas
• Solução: Use --backend=copyfile pra pacotes problemáticos

Performance em CI/CD

Pra muitos times, tempo de CI/CD é onde a escolha do gerenciador de pacotes realmente importa:

Benchmark do GitHub Actions

# Mesmo workflow, diferentes gerenciadores
# Node.js 22, ubuntu-latest, cache limpo

┌────────────┬──────────────┬──────────────┬──────────────┐
│ Gerenciador│ Instalar     │ Cache Hit    │ Job Total    │
├────────────┼──────────────┼──────────────┼──────────────┤
│ npm        │ 48s          │ 12s          │ 2m 34s       │
│ yarn       │ 21s          │ 8s           │ 2m 15s       │
│ yarn (PnP) │ 18s          │ 0s*          │ 2m 02s       │
│ pnpm       │ 14s          │ 4s           │ 2m 08s       │
│ bun        │ 3s           │ 1s           │ 1m 52s       │
└────────────┴──────────────┴──────────────┴──────────────┘

* Zero-installs: dependências commitadas no repo

Guias de Migração

Pronto pra trocar? Veja como:

npm → pnpm

1. Instalar pnpm:

npm install -g pnpm

2. Importar lockfile existente:

pnpm import

3. Deletar arquivos antigos:

rm -rf node_modules package-lock.json

4. Instalar:

pnpm install

npm → Bun

1. Instalar Bun:

curl -fsSL https://bun.sh/install | bash

2. Deletar arquivos antigos:

rm -rf node_modules package-lock.json

3. Instalar:

bun install

Plano de Rollback

Se a migração causar problemas:

# Mantenha seu lockfile antigo backupeado!
cp package-lock.json package-lock.json.backup

# Pra rollback:
rm -rf node_modules bun.lockb pnpm-lock.yaml yarn.lock
mv package-lock.json.backup package-lock.json
npm install

Quando Usar O Quê: Framework de Decisão

Use npm quando:

✅ Máxima compatibilidade é necessária
✅ Time não tá familiarizado com alternativas
✅ Projeto legacy com muitas dependências nativas
✅ Ambiente corporativo com políticas rígidas
✅ Você quer que "simplesmente funcione"

Use yarn quando:

✅ Você precisa de zero-installs do Plug'n'Play
✅ Você quer o ecossistema de plugins
✅ Seu time já são experts em yarn
✅ Você precisa de recursos avançados de workspace
✅ Desenvolvimento offline-first é importante

Use pnpm quando:

✅ Espaço em disco é preocupação
✅ Você tem muitos projetos com dependências sobrepostas
✅ Monorepo grande com dependências complexas
✅ Você quer velocidade sem sacrificar compatibilidade
✅ Isolamento estrito de dependências importa

Use Bun quando:

✅ Velocidade é a prioridade absoluta
✅ Você tá começando um projeto novo
✅ Tempo de CI/CD é um custo grande
✅ Você tá construindo APIs ou scripts Node.js
✅ Você quer um runtime + gerenciador de pacotes unificado

Os Custos Ocultos Que Ninguém Menciona

Antes de trocar, considere:

Curva de Aprendizado

• npm → pnpm: Mínima. Quase drop-in.
• npm → yarn 4: Moderada. Modo PnP requer entendimento.
• npm → Bun: Baixa pra gerenciamento de pacotes, mais alta se usar o runtime do Bun.

Onboarding do Time

O gerenciador de pacotes mais rápido não ajuda se deixar seu time mais lento:

• Quão confortável tá seu time com a nova ferramenta?
• Sua documentação e scripts estão atualizados?
• Você testou o workflow de desenvolvimento completo?

Conclusão: Não Existe Escolha Errada (Na Maioria dos Casos)

Depois de testes extensivos, aqui tá a verdade honesta: os quatro gerenciadores de pacotes funcionam bem pra maioria dos projetos. As diferenças de performance, embora mensuráveis, raramente importam pra projetos pequenos a médios.

Onde a escolha importa:

1. Monorepos: pnpm ou yarn
2. Workflows pesados em CI/CD: Bun ou pnpm
3. Sistemas com disco limitado: pnpm
4. Máxima compatibilidade: npm
5. Bleeding edge: Bun

O mais importante não é qual gerenciador de pacotes você escolhe—é que você escolha consistentemente nos seus projetos e time. Ficar trocando entre gerenciadores cria mais fricção do que qualquer diferença de velocidade poderia justificar.

Minha recomendação pra 2026:

• Projetos novos: Experimenta Bun. É rápido o suficiente pra justificar os riscos menores de compatibilidade.
• Projetos existentes: Considera pnpm se você tá sentindo dor. Senão, npm tá de boa.
• Monorepos enterprise: pnpm é a escolha segura e potente.

Benchmarks realizados em janeiro de 2026 no M3 MacBook Pro com Node.js 22.x. Resultados vão variar baseado em hardware, rede e especificidades do projeto. Sempre teste com seu próprio codebase antes de tomar decisões.