O Que é Aube, o Gerenciador de Pacotes Node.js Mais Rápido em 2026?

As instalações do Node têm sido lentas por anos. Você executa npm install, vai até a máquina de café, volta, e o CI ainda está resolvendo @types/node. Aube muda essa equação. Ele conclui uma instalação quente de CI de um projeto real com 1.400 pacotes em 139 milissegundos, o que é cerca de 7,3 vezes mais rápido que o pnpm e 3 vezes mais rápido que o Bun no mesmo cenário. A parte realmente interessante: ele lê e grava seu lockfile existente, então você pode experimentá-lo na segunda-feira sem pedir a ninguém para migrar.

Este guia aborda o que é o Aube, como ele atinge esses números, como instalá-lo, como ele se compara ao pnpm, npm, yarn e Bun, e onde ele se encaixa se você cria APIs com ferramentas como o Apidog todos os dias.

O que é o Aube?

Aube é um gerenciador de pacotes Node.js rápido, construído pela en.dev e lançado sob a licença MIT. O nome significa “amanhecer” em francês e é pronunciado “ôb”. O projeto está em beta (v1.0.0-beta.10 no momento da escrita) e tem como objetivo principal a compatibilidade com o pnpm v11.

A proposta é direta. O Aube utiliza o mesmo modelo em disco que o pnpm, um armazenamento global endereçável por conteúdo mais um layout de symlink isolado, mas o pipeline de instalação é escrito em uma linguagem com threads nativas em vez de JavaScript. Mesmo layout, motor mais rápido. Essa única escolha de design é o que permite que ele se posicione acima do Bun em vários cenários de benchmark, enquanto ainda grava pnpm-lock.yaml de volta no lugar.

Se você já migrou entre gerenciadores de pacotes uma vez, sabe que o custo real não é a ferramenta; é o custo social de fazer com que todos em sua equipe mudem a forma como executam install. O Aube contorna isso lendo pnpm-lock.yaml, package-lock.json, npm-shrinkwrap.json, yarn.lock e bun.lock diretamente. Você pode executá-lo localmente enquanto seu CI ainda usa pnpm, e nada muda para os colegas de equipe.

Benchmarks do Aube: quão rápido é o “mais rápido”?

O cenário de benchmark é um projeto real com cerca de 1.400 pacotes, cronometrado com hyperfine. Cada cenário assume um lockfile commitado. O eixo que varia é o aquecimento do cache: quente limpa node_modules mas mantém o armazenamento global e o cache de pacotes, frio apaga tudo.

Números dos benchmarks oficiais (aube 1.0.0-beta.3, bun 1.3.12, pnpm 10.33.0, npm 11.12.1, yarn 1.22.22, node 24.15.0):

Alguns pontos se destacam. A instalação quente de CI é o número principal porque reflete o caso mais comum em pipelines reais, onde o executor restaura um cache e seu armazenamento global ainda tem cada tarball hashado. Nesse cenário, o Aube é cerca de 7,3 vezes mais rápido que o pnpm e 3 vezes mais rápido que o Bun.

O cenário install && run test mede o ciclo diário do desenvolvedor. Toda ferramenta precisa decidir 'preciso instalar primeiro e depois executar o script?'. O Aube pode pular o trabalho de instalação inteiramente quando seu arquivo de estado de instalação está atualizado, então todo o ciclo install && test retorna em 21ms. Outras ferramentas ainda revalidam o lockfile antes de despachar o script, o que gera o overhead de 400ms-600ms.

Em um cache frio, o Bun supera o Aube (935ms vs 1.12s) porque o caminho de busca de tarball do Bun é extremamente otimizado e as instalações frias são dominadas por E/S. O cenário quente é o que ocorre milhares de vezes ao dia em uma equipe de desenvolvimento típica; o frio ocorre uma vez por mês quando você apaga um executor.

Em todo o conjunto de cenários, a documentação aponta picos de até 22 vezes mais rápido que o pnpm e até 3 vezes mais rápido que o Bun, dependendo do cenário. Você pode reproduzir tudo isso localmente com mise run bench do repositório Aube.

Por que o Aube é mais rápido que o pnpm e o Bun

Três escolhas de design realizam o trabalho pesado.

Pipeline de instalação nativo e com threads. npm, pnpm e yarn executam o motor de instalação em Node.js. Isso significa que cada hash, cada extração de tarball, cada chamada de symlink paga o custo de dispatch do JavaScript. O Aube move o caminho crítico para fora do V8 e para um runtime compilado nativamente e com threads nativas. O Bun faz algo similar, mas envia um runtime JavaScript completo junto com seu gerenciador de pacotes; o Aube é construído especificamente para o caminho de instalação, o que é parte do motivo pelo qual ele supera o Bun em instalações quentes.

Armazenamento virtual global é o padrão. O pnpm v11 adicionou enableGlobalVirtualStore, mas não é o padrão para instalações de projetos. O Aube usa um armazenamento virtual global por padrão, então projetos repetidos com dependências sobrepostas na maioria das vezes se ligam a árvores de pacotes que já existem no disco. Se você tem três serviços que usam React, Vite, TypeScript e Playwright, os arquivos pesados ficam em um só lugar e cada projeto cria symlinks para ele. A documentação estima cerca de 90% menos espaço em disco do que o npm em configurações típicas de mono-repositório.

Otimização de instalação com um arquivo de estado atualizado. aube run test primeiro verifica um arquivo de estado de instalação compacto. Se o hash do seu package.json e lockfile corresponderem ao arquivo de estado, a fase de instalação é uma única chamada stat e o teste é despachado imediatamente. Isso é o que reduz o número de install && test para 21ms.

Nada disso é mágica. É o que você obtém quando pega o layout do pnpm, remove o bootstrap JavaScript e projeta a CLI com base na suposição de que 99% das instalações são 'nada realmente mudou'.

Como instalar o Aube

O caminho recomendado é mise, o gerenciador de ferramentas poliglota:

mise use -g aube

Verifique se ele está no seu PATH:

aube --version

Se você preferir o npm:

npm install -g @endevco/aube

No macOS ou Linux com Homebrew, o tap da Endev tem:

brew install endevco/tap/aube

Dentro de um projeto, você pode fixar a versão do Aube localmente:

mise use aube

Isso grava aube como uma ferramenta no seu mise.toml, o que significa que cada shell que entra na pasta do projeto obtém a mesma versão. Chega de 'funciona na minha máquina porque instalei o pnpm 10 no ano passado'. A documentação de instalação também abrange as opções de tarball e por sistema operacional.

Comandos diários que você realmente usará

A interface de comando espelha de perto o pnpm, então a memória muscular é transferida:

aube install              # instalar dependências
aube add react            # adicionar uma dependência
aube add -D vitest        # adicionar uma dependência de desenvolvimento
aube remove react         # remover uma dependência
aube update               # atualizar dentro dos ranges do package.json
aube run build            # executar um script do package.json
aube test                 # executar script de teste, instalando primeiro se obsoleto
aube exec vitest          # executar um binário local
aube dlx cowsay hi        # executar um pacote em um ambiente temporário
aube ci                   # instalação limpa e congelada para CI

Você pode encurtar a maioria desses comandos. Se o script existir em package.json, aube dev é o mesmo que aube run dev. Há também dois shims multicall enviados no mesmo binário:

aubr build       # aube run build
aubx cowsay hi   # aube dlx cowsay hi

Use aube ci em pipelines. Ele remove node_modules, confirma que o lockfile está atualizado para o package.json atual e então instala. Se o lockfile estiver defasado, ele falha ruidosamente, o que é o desejado em CI.

Compatibilidade de Lockfile

Este é o recurso que torna o Aube uma adoção de baixo risco. Você não precisa se comprometer a mudar a equipe inteira.

O padrão prático é o seguinte. Sua equipe usa pnpm. O CI ainda executa pnpm install --frozen-lockfile. Você executa aube install localmente em sua máquina. Ele lê pnpm-lock.yaml, produz o mesmo layout node_modules e grava quaisquer atualizações de resolução de volta no mesmo pnpm-lock.yaml. Um colega de equipe puxa sua branch, executa pnpm install, e nada está errado. Com o tempo, se o Aube se provar, você migra o CI. Se não, você o remove e nada downstream saberá.

Duas ressalvas. Lockfiles antigos do pnpm v5 ou v6 precisam ser atualizados com pnpm primeiro. E projetos yarn PnP (o estilo .pnp.cjs) precisam retornar a um linker node_modules porque o Aube grava node_modules, não artefatos PnP.

Padrões seguros importam mais do que você pensa

Se você esteve perto de uma base de código JavaScript nos últimos 18 meses, viu incidentes na cadeia de suprimentos se acumularem. O guia de segurança da cadeia de suprimentos do npm aborda o padrão; o comprometimento do Axios npm foi um dos casos reais mais claros de como uma única dependência popular pode enviar um RAT multiplataforma para milhares de máquinas de desenvolvedores.

O Aube adota três padrões opinativos que tratam as instalações como uma fronteira de segurança, não como uma conveniência:

1. Idade mínima de lançamento. Novas versões aguardam uma idade mínima configurável antes que o Aube as instale. Um pacote recém-comprometido que é removido em duas horas nunca toca seu node_modules.
2. Bloqueio de dependências exóticas. O Aube bloqueia dependências transitórias cujas formas parecem suspeitas (URLs incomuns, entradas tipo patch, referências Git em locais que normalmente contêm semver). Se você explicitamente quiser uma, você a aprova.
3. Aprovação de scripts de ciclo de vida. Scripts postinstall de dependências são ignorados por padrão. Você executa aube approve-builds para permitir pacotes específicos (esbuild, node-sass, o que você realmente precisa construir localmente). Pacotes cujos scripts foram ignorados aparecem em aube ignored-builds.

Esses três comportamentos não o tornam invulnerável, mas convertem 'Eu não sabia que esse pacote sequer executava código' em 'Eu escolhi permitir que esse pacote executasse código'. Essa é a postura de segurança que você deseja antes do seu próximo incidente de produção.

Layout dos módulos Node

O Aube usa um layout node_modules isolado. O node_modules/ de nível superior contém as dependências declaradas no seu package.json. As dependências transitórias vivem atrás de node_modules/.aube/. Os arquivos de pacote em si são armazenados exatamente uma vez em $XDG_DATA_HOME/aube/store/, que por padrão é ~/.local/share/aube/store/.

Três consequências:

• Vários projetos com dependências sobrepostas compartilham arquivos de pacote no disco. Chega de 'Tenho 12 cópias de lodash no meu monorepo e projetos paralelos'.
• Dependências fantasmas são mais difíceis. Se um pacote não está no seu package.json, você não pode require-lo do nível superior, porque ele não está em node_modules/. Esta é a mesma garantia que o pnpm oferece.
• Instalações repetidas reutilizam arquivos já existentes no disco. O único trabalho restante é fazer hard-linking do armazenamento para o novo node_modules/.aube/.

Se você anteriormente utilizava um layout node_modules plano (npm clássico ou yarn v1), espere encontrar um ou dois pacotes quebrados que dependiam de importações fantasmas. A solução é sempre 'adicione-o ao seu package.json'.

Workspaces e monorepos

O Aube suporta workspaces e o protocolo workspace::

aube install -r
aube run test -r
aube add zod --filter @acme/api

Se o seu repositório já possui pnpm-workspace.yaml, o Aube o lê e o grava. Novos workspaces focados em Aube usam aube-workspace.yaml. As flags -r (recursivo) e --filter mapeiam para a mesma semântica que você espera do pnpm, então as configurações de turborepo e nx continuam funcionando sem alterações.

Para monorepos de API, o número de CI com cache quente é o mais importante. Se o seu pipeline executa install, build, test, publish contract em cada merge, reduzir o install de 1 segundo do pnpm para 139 milissegundos do Aube em dez pacotes resulta em minutos reais por dia.

Onde o Aube se encaixa em um fluxo de trabalho de desenvolvimento de API

Se você constrói e testa APIs, as instalações ficam no caminho crítico de cada refatoração. Você altera um esquema de requisição, regenera o cliente TypeScript, reinstala, executa testes de contrato contra seu servidor mock, e repete. Uma instalação rápida não é uma métrica de vaidade; é o intervalo entre 'Eu mudei isso' e 'Eu sei se quebrou'.

Um ciclo prático que funciona bem:

1. Projete e simule a API no Apidog. Abordagem schema-first supera code-first para qualquer coisa que se comunique com outra equipe.
2. Gere um cliente tipado (ou execute testes de contrato contra o mock do Apidog) dentro do seu projeto Node.
3. Use o Aube localmente para manter as instalações na faixa de milissegundos enquanto você itera no cliente.
4. Conecte a mesma suíte de testes no CI com aube ci.

A mudança de ferramentas longe do Postman no último ano faz parte de um padrão maior: os desenvolvedores querem ferramentas que sejam rápidas, com foco local e seguras por padrão. O Aube é a mesma história aplicada à etapa de instalação. Se você já executa o Apidog dentro do VS Code, adicionar o Aube ao lado custa uma linha de mise use e economiza segundos em cada hot reload.

Migração de cada gerenciador de pacotes

Do npm. Execute aube install no projeto. O Aube lê package-lock.json e o grava de volta. Você obtém node_modules isolados em vez de planos, então fique atento a importações fantasmas. Se uma quebrar, adicione o pacote ausente ao package.json e continue. O fluxo de trabalho completo está no guia para usuários do npm.

Do pnpm. Esta é a migração de menor atrito porque o layout em disco é o mesmo. O Aube lê pnpm-lock.yaml v9 diretamente. O protocolo workspace: funciona. Filtros funcionam. A página pnpm-users lista as poucas flags que se comportam de forma diferente.

Do yarn. O Aube lê os lockfiles v1 classic e v2+ berry. Usuários do Yarn PnP precisam voltar ao modo nodeLinker: node-modules antes de tentar o Aube, porque o Aube escreve node_modules e não .pnp.cjs.

Do Bun. O Aube lê bun.lock. A principal diferença é que o gerenciador de pacotes do Bun está fortemente acoplado ao runtime JS do Bun; o Aube é uma ferramenta de instalação autônoma que funciona com qualquer versão do Node.js. Se você já usa o mise para gerenciamento de versões do Node, o Aube se encaixa da mesma forma.

Considerações do mundo real

Status Beta. Em abril de 2026, o Aube está na versão v1.0.0-beta.10. A documentação é explícita: ele visa a compatibilidade com o pnpm v11, mas ainda não foi testado em muitos projetos. Trate-o como faria com qualquer ferramenta pré-1.0. Execute-o localmente primeiro, mantenha seu lockfile existente, não aposte seu pipeline de lançamento em produção nele até vê-lo funcionar por um mês.

O que está fora do escopo. O Aube intencionalmente não duplica o que o mise já faz. O gerenciamento de runtime (env, runtime, setup, self-update) pertence a ele. Alguns helpers de conta de registro (whoami, token, owner, search, pkg, set-script) são stubs de compatibilidade que o direcionam para o comando npm. Se o seu script de CI chamar algum desses, mantenha o npm como fallback.

Suporte de plataforma. O instalador recomendado é o mise, que suporta macOS, Linux e Windows via WSL. O suporte nativo ao Windows via tarball existe, mas está em estágio inicial; verifique a página de instalação para a matriz atual.

Comunidade. O projeto tem um Discord (linkado na página inicial) e 325 estrelas no GitHub no momento da escrita. Pequeno, mas ativo. O Buildkite fornece CI para o projeto, o que você pode ver na raiz do repositório.

FAQ

O que significa “aube”? Amanhecer, em francês. Pronuncia-se “ôb”. O slogan do projeto é “um novo amanhecer para as instalações do Node”.

O Aube é um substituto direto para o pnpm? Quase. Ele visa a compatibilidade com o pnpm v11 e lê o formato de lockfile do pnpm. A maioria dos fluxos de trabalho com sabor pnpm migra sem alterações. Alguns comandos do pnpm (gerenciamento de runtime, alguns helpers de registro) estão intencionalmente fora do escopo porque pertencem a outras ferramentas.

Posso usar o Aube no CI enquanto mantenho o pnpm localmente? Sim, ambas as direções funcionam. O Aube lê e grava pnpm-lock.yaml no local, então as duas ferramentas podem compartilhar um lockfile. Equipes geralmente começam de forma inversa: Aube localmente, pnpm no CI, até que todos se sintam confortáveis.

Como o Aube se compara ao Bun? Em instalações quentes, o Aube é cerca de 3 vezes mais rápido que o Bun porque o Bun revalida mais estados antes de instalar. Em instalações frias, o Bun está ligeiramente à frente porque seu caminho de busca é extremamente otimizado. O Bun também inclui um runtime JS; o Aube é apenas para instalação. Se você já usa Node, não precisa do runtime do Bun para usar o Aube. A comparação de layout isolado estilo pnpm oferece contexto sobre por que as escolhas de layout importam.

O Aube funciona no Windows? Via WSL, sim. O Windows nativo funciona, mas está em estágio inicial. O mise é a maneira mais fácil de instalar e atualizar em todos os três sistemas operacionais.

O Aube é open source? Sim, licenciado sob MIT, código-fonte no GitHub.

O que acontece com o meu pnpm-lock.yaml existente? O Aube o lê, realiza a instalação e grava o mesmo arquivo de volta com quaisquer alterações de resolução. Seus colegas de equipe executando pnpm verão um diff de lockfile normal.

Conclusão

Para a maioria dos projetos Node em 2026, a etapa de instalação é mais lenta do que deveria ser. O Aube é o gerenciador de pacotes Node.js mais rápido nos caminhos de instalação quente e de comandos repetidos que dominam os fluxos de trabalho reais de desenvolvedores: 139ms para uma instalação CI de 1.400 pacotes, 21ms para install && test quando nada mudou, 90% menos espaço em disco em uma máquina com vários projetos. Ele lê seu lockfile existente, leva a sério os padrões de segurança e custa uma linha de mise use aube para experimentar.

Se você já testa APIs com um cliente rápido e local-first como o Apidog, o Aube é a peça que se encaixa no lado da instalação. Baixe o Apidog se ainda não o fez, combine-o com o Aube para o seu próximo serviço Node e veja o quão mais rápido o ciclo de feedback se torna.