Nub - toolkit tudo-em-um no estilo do Bun para Node.js

• Toolkit tudo-em-um que complementa, sem substituir, o Node.js, escrito em Rust e que oferece uma experiência de desenvolvimento semelhante ao Bun sobre o node padrão
• Integra em uma única ferramenta execução de arquivos e scripts, instalação de dependências e gerenciamento de versões do Node, sem novo runtime, APIs proprietárias dependentes de fornecedor ou lock-in
• File runner nub <file> — executa .ts, .tsx etc. sem etapa de build, com compatibilidade flag-for-flag e var-for-var com node, e startup 2,9× mais rápido que tsx
  • Suporte completo a TypeScript (enum, namespace), JSX/TSX, Decorators, carregamento automático de .env* e loader embutido para .yaml, .toml, .json5 etc.
  • Detecta e instala automaticamente a versão do Node esperada pelo projeto (consultando .node-version, .nvmrc, package.json#engines etc.)
• Script runner nub run — substituto direto de npm/pnpm run, com binário Rust sem startup próprio em JS e despacho cerca de 24× mais rápido que pnpm run (14.7ms vs 442.7ms)
  • Suporte completo a hooks pre/post, --filter e --parallel de workspaces do pnpm etc.
• Package runner nubx — substituto direto de npx e pnpm dlx, removendo a penalidade de spawn duplo do Node e executando cerca de 19× mais rápido que npx (11ms vs 226ms)
• Package manager nub install — baseado no engine Aube, compatível com as flags do pnpm, 2,5× mais rápido que pnpm e 3,7× mais rápido que npm
  • Política de segurança padrão embutida — bloqueia postinstall, verifica pacotes maliciosos via osv.dev, rejeita downgrade de provenance e aplica minimumReleaseAge de 24 horas
  • Opera em compat-mode, detectando automaticamente lockfiles e configurações de npm/pnpm/Yarn/Bun
• Node version manager nub node — fornece comandos de gerenciamento manual como install, ls, uninstall e pin de versões
• Package meta-manager nub pm — exerce o papel do Corepack em Rust nativo, registrando shims globais de npm, yarn e pnpm
• Licença MIT

[GN⁺]

Comentários no Hacker News

• A ideia é muito boa e faz sentido. O Bun oferece mais coisas, como drivers de banco de dados, mas a experiência do desenvolvedor certamente é uma grande parte do apelo
  Como referência, o autor principal do Nub é Colin McDonnell, criador do Zod, que também trabalhou no Bun por um tempo

  • Exato. O Nub deliberadamente não inclui nenhuma API específica do Nub: nada de objeto global Nub, módulos nativos com prefixo nub:, arquivos de configuração/lockfile com nome do Nub, campo nub no package.json, nem variáveis de ambiente NUB_
    Acho que a maior parte do que o Bun acrescentou seria melhor como dependências bem definidas

• É surpreendente que ele use um hook --require em vez de --import. Pode ser que muita coisa tenha mudado desde quando eu estava analisando como criar algo parecido, mas imagino que possa haver sutilezas no suporte a ESM do Nub
  Na época, o --import do Node era muito inicial, e havia várias exceções que eu queria tratar na abordagem comum de ESM para CJS. A maioria provavelmente era bem de nicho, mas acho que top-level await afetaria alguns usuários relevantes

  • Isso é usado para registrar o preload puramente por causa de desempenho. Neste caso, e em muitos outros, CommonJS ainda é mais rápido que ESM. --require tem um overhead de cerca de 0,5 ms, enquanto --import fica em torno de 4,6 ms em um MacBook Pro M1
    Relacionado a isso, em 2025 o Node.js introduziu recentemente module.registerHooks(), uma versão síncrona da API de registro de hooks do resolver, para melhorar o desempenho em relação à antiga API assíncrona module.register(). Para o Nub, isso removeu um grande obstáculo. Para quem tiver interesse: a API assíncrona adicionava um overhead fixo de registro de 19 ms, mais cerca de 130 us de overhead adicional por import
    A flag que o Nub usa aqui não afeta em nada o código do usuário, e top-level await é suportado onde o próprio Node.js o suporta

• Acabei de fazer merge de um PR que migra todo o nosso monorepo para o nub
  Zero problemas, e é absurdamente rápido

  • Você fez merge de um PR migrando um monorepo compartilhado para isso menos de uma hora depois de ele ter sido publicado?

• O Node já não consegue executar TypeScript há algumas versões? Por que é necessário um transformador?

  • O suporte nativo a TypeScript do Node só faz remoção de tipos. Funciona para uma grande parte da sintaxe do TypeScript, mas não para tudo. Ele também não verifica tipos de fato; apenas remove o necessário para executar. Você também perde coisas como tsconfig
    Isto parece oferecer suporte tanto ao modo nativo de remoção quanto ao processamento real de TypeScript
  • A equipe do Node.js removeu --experimental-transform-types no Node.js v26. Com isso, o suporte completo nativo a TypeScript se torna impossível
    https://github.com/nodejs/typescript/issues/51#issuecomment-...
  • Diz que ele injeta polyfills quando necessário para APIs como Worker e Temporal

• O README diz que o suporte a WebSocket é nativo a partir do Node 22, mas o Node não tem uma biblioteca WebSocket nativa. O link para o padrão WebSocket leva ao MDN, que descreve apenas a interface de usuário WHATWG, não o protocolo nem como o WebSocket funciona
  Parece que algo está faltando, ou que uma biblioteca não nativa é usada como suporte

  • O Node tem suporte nativo a cliente WebSocket desde a versão 22, mas não a servidor

• É respeitável o fato de adotarem a tecnologia existente em vez de recriar uma versão pior dela. Fico imaginando onde o Node estaria hoje, sob uma liderança adequada, se todo o esforço gasto em criar alternativas tivesse ido para ele

  • Talvez você se lembre do fork io.js do Node.js em 2014. Quando o Node estagnou, várias pessoas fizeram o fork io.js, que acabou sendo mesclado de volta ao Node e colocou o Node de volta nos trilhos. Indo ainda mais longe, o CoffeeScript, que foi um “fork” do JS, também teve suas melhores ideias absorvidas pelo ES5
    Equipes pequenas e ágeis conseguem validar boas ideias porque o fracasso não é um risco fatal. Em resumo, forks fazem parte de um ecossistema saudável
  • Há muita coisa que, fundamentalmente, não pode ser corrigida com essa abordagem
    Um exemplo simples: o Node é o único software open source sério que conheço em que não há como documentar a configuração dentro do arquivo de configuração. É absurdo. O pessoal do Node adotou JSON sem pensar muito e, depois disso, se recusou a considerar qualquer alternativa, até mesmo “JSON com comentários”
    Quando uma organização fica presa a uma decisão ruim, a única forma de corrigir é começar de novo. Enquanto todo mundo continuar construindo em cima do Node, todo o ecossistema JS ficará sem poder deixar documentação na configuração
    Há vários problemas assim no ecossistema Node, e o absurdo total de não poder documentar configuração é apenas um ponto que me incomoda pessoalmente

• Sou fã do Nub e do mascote nubnub. Falando sério, é um ótimo projeto e bem interessante; venho testando desde a semana passada, pelo menos desde que ficou público

• Inteligente. Se já é escrito em Rust, eles não vão perder todos os clientes tentando migrar para Rust via vibe coding ;)

  • Depois que a OpenAI comprar, provavelmente vão mudar o projeto para Zig
  • Este projeto já tem uma boa dose de vibe coding. O segundo maior contribuidor do repositório é o Claude
  • Acho que “se já foi feito por vibe coding em Rust” seria melhor. O Nub, no geral, passa bastante essa impressão. Tudo bem, mas fica engraçado quando comparado ao Bun
    Além disso, a histeria anti-IA em torno do Bun é muito triste e às vezes até parece uma campanha organizada
  • Ajuda ainda mais se ele já tiver sido feito por vibe coding desde o começo e não tiver clientes
  • Sim. Não sei bem o que “escrito em Rust” acrescenta aqui. Achei que a mesma funcionalidade provavelmente seria possível com alguns scripts shell e um package.json