Nub - toolkit todo en uno similar a Bun para Node.js

• Un toolkit todo en uno que complementa Node.js sin reemplazarlo, escrito en Rust, que ofrece una experiencia de desarrollo similar a Bun sobre el node estándar
• Integra en una sola herramienta la ejecución de archivos y scripts, la instalación de dependencias y la gestión de versiones de Node, sin nuevo runtime, APIs propietarias dependientes del proveedor ni lock-in
• File runner nub <file> — ejecuta .ts, .tsx y más sin etapa de build, con compatibilidad flag-for-flag y var-for-var con node, y un startup 2.9× más rápido que tsx
  • Soporte completo de TypeScript (enum, namespace), JSX/TSX, Decorators, carga automática de .env*, y loaders integrados para .yaml, .toml, .json5, etc.
  • Detecta e instala automáticamente la versión de Node que el proyecto espera (consultando .node-version, .nvmrc, package.json#engines, etc.)
• Script runner nub run — reemplazo directo de npm/pnpm run, con binario Rust sin startup propio de JS, y un dispatch ~24× más rápido que pnpm run (14.7ms vs 442.7ms)
  • Soporte completo para hooks pre/post, y para --filter, --parallel de workspaces de pnpm, entre otros
• Package runner nubx — reemplazo directo de npx y pnpm dlx, elimina la penalización de doble ejecución de Node y logra una ejecución ~19× más rápida que npx (11ms vs 226ms)
• Package manager nub install — basado en el motor Aube, compatible en flags con pnpm, 2.5× más rápido que pnpm y 3.7× más rápido que npm
  • Política de seguridad predeterminada integrada: bloquea postinstall, revisa paquetes maliciosos con osv.dev, rechaza downgrades de provenance y aplica minimumReleaseAge de 24 horas
  • Funciona en compat-mode, detectando automáticamente lockfiles y configuraciones de npm/pnpm/Yarn/Bun
• Node version manager nub node — ofrece comandos de gestión manual como instalación de versiones, ls, uninstall, pin, etc.
• Package meta-manager nub pm — cumple el rol de Corepack en Rust nativo, registrando shims globales para npm, yarn y pnpm
• Licencia MIT

[GN⁺]

Comentarios de Hacker News

• La idea es muy buena y tiene sentido. Bun ofrece más cosas como drivers de base de datos, pero está claro que la experiencia de desarrollador también es una gran parte de su atractivo
  Como referencia, el autor principal de Nub es Colin McDonnell, creador de Zod, y en algún momento también trabajó en Bun

  • Correcto. Nub intencionalmente no agrega ninguna API exclusiva de Nub en absoluto: no hay objeto global de Nub, ni módulos integrados con prefijo nub:, ni archivo de configuración o lockfile con nombre de Nub, ni campo nub en package.json, ni variables de entorno NUB_
    Creo que la mayoría de las cosas que agregó Bun sería mejor tenerlas como dependencias normales

• Me sorprende que use el hook de --require y no --import. Puede que hayan cambiado bastante las cosas desde que revisé esto para crear algo parecido, pero sospecho que podría haber algún detalle sutil en el soporte ESM de Nub
  En ese momento, --import de Node estaba muy verde, y había varias excepciones que quería manejar en el enfoque común de ESM-a-CJS. La mayoría probablemente eran casos muy de nicho, pero creo que await de nivel superior sí afectaría a algunos usuarios de forma importante

  • Esto se usa para el registro de precarga únicamente por rendimiento. En este caso y en muchos otros, CommonJS sigue siendo más rápido que ESM. --require tiene un overhead de unos 0.5 ms, mientras que --import ronda los 4.6 ms en una Macbook Pro M1
    Relacionado con eso, Node.js introdujo recientemente en 2025 module.registerHooks(), una versión síncrona de la API de registro de hooks del resolver, para mejorar el rendimiento frente a la vieja API asíncrona module.register(). Para Nub eso eliminó un obstáculo importante. Como dato para quien tenga curiosidad, la API asíncrona añadía un costo fijo de registro de 19 ms más un overhead adicional de unos 130 us por import
    Qué flags usa Nub aquí no afecta en absoluto al código del usuario, y await de nivel superior está soportado donde Node.js mismo lo soporta

• Acabamos de hacer merge al PR para migrar todo nuestro monorepo a nub
  Cero problemas, e increíblemente rápido

  • ¿Hicieron merge a un PR para migrar un monorepo compartido a esto en menos de una hora desde que se publicó?

• ¿Node no podía ejecutar TypeScript desde hace algunas versiones? ¿Para qué hace falta un transformador entonces?

  • El soporte integrado de TypeScript en Node solo hace eliminación de tipos. Sirve para una gran parte de la sintaxis de TypeScript, pero no para toda. Tampoco verifica realmente los tipos, solo los elimina para que se pueda ejecutar. Además se pierde cosas como tsconfig
    Esto parece soportar tanto el enfoque de eliminación integrado como un procesamiento real de TypeScript
  • El equipo de Node.js quitó --experimental-transform-types en Node.js v26. Eso hace imposible un soporte nativo de TypeScript completo
    https://github.com/nodejs/typescript/issues/51#issuecomment-...
  • Dice que inyecta polyfills cuando se necesitan para APIs como Worker y Temporal

• En el README dice que el soporte de WebSocket es nativo desde Node 22, pero Node no tiene una librería WebSocket nativa. El enlace al estándar de WebSocket va a MDN, y ahí solo explican la interfaz de usuario WHATWG, no el protocolo ni cómo funciona WebSocket
  Siento que falta algo, o que usan alguna librería no nativa como apoyo

  • Node soporta un cliente WebSocket integrado desde la versión 22, pero no servidor

• Es respetable que adopten la tecnología existente y no rehagan una versión peor. Me pregunto hasta dónde habría llegado Node bajo un liderazgo adecuado si todo el esfuerzo invertido en crear alternativas se hubiera ido a Node

  • Tal vez recuerdes el fork io.js de Node.js en 2014. Cuando Node se estancó, varias personas hicieron fork hacia io.js, y al final se volvió a fusionar en Node y lo encaminó otra vez. Si retrocedes más, CoffeeScript, que era un “fork” de JS, también vio cómo sus mejores ideas fueron absorbidas por ES5
    Los equipos pequeños y ágiles pueden demostrar buenas ideas porque fracasar no es un riesgo fatal. En resumen, los forks son parte de un ecosistema sano
  • Fundamentalmente hay muchas cosas que no se pueden arreglar con este enfoque
    Como ejemplo simple, Node es el único software open source serio que conozco en el que no hay forma de documentar la configuración dentro del archivo de configuración. Es absurdo. Del lado de Node adoptaron JSON sin pensarlo mucho, y después se negaron siquiera a considerar alternativas, incluso “JSON con comentarios”
    Cuando una organización se atasca con malas decisiones, la única forma de arreglarlo es empezar de cero. Mientras todos sigan construyendo sobre Node, todo el ecosistema de JS seguirá sin poder dejar documentación en la configuración
    Hay varios problemas así en el ecosistema de Node, y esta absurdidad total de no poder documentar la configuración es simplemente mi punto personal de queja

• Soy fan de Nub y de la mascota nubnub. Hablando en serio, es un proyecto excelente y bastante interesante; lo he estado probando desde la semana pasada, o al menos desde que se hizo público

• Inteligente. Si ya está escrito en Rust, entonces no van a ponerse a migrarlo a Rust con vibe coding para luego perder a todos sus clientes ;)

  • Después de que OpenAI lo compre, seguro cambian el proyecto a Zig
  • Este proyecto ya tiene una proporción alta de vibe coding. El segundo colaborador del repositorio es Claude
  • Sonaría mejor como “si ya está vibe-codeado en Rust”. En general Nub sí tiene bastante esa vibra. Está bien, pero comparado con Bun da risa
    Y además, la histeria anti-AI de Bun es muy triste, y a veces hasta se siente como una campaña organizada
  • De hecho ayuda más si ya está vibe-codeado y además no tiene clientes
  • Sí. No me queda claro qué agrega aquí lo de “escrito en Rust”. Pensé que la misma funcionalidad podría lograrse con unos cuantos scripts de shell y package.json