Nub – Bun-ähnliches All-in-One-Toolkit für Node.js

 (github.com/nubjs)
2 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Ein All-in-One-Toolkit, das Node.js nicht ersetzt, sondern ergänzt, in Rust geschrieben und auf dem standardmäßigen node aufbauend, um eine Bun-ähnliche Developer Experience zu bieten
  • Vereint Datei-/Skriptausführung, Abhängigkeitsinstallation und Node-Versionsverwaltung in einem einzigen Tool, ohne neue Runtime, herstellerspezifische APIs oder Lock-in
  • File Runner nub <file> — führt .ts, .tsx usw. ohne Build-Schritt aus, flag-for-flag und var-for-var kompatibel mit node, mit 2,9× schnellerem Startup als tsx
    • Vollständige TypeScript-Unterstützung (enum, namespace), JSX/TSX, Decorators, automatisches Laden von .env*, integrierte Loader für .yaml, .toml, .json5 usw.
    • Automatische Erkennung und Installation der vom Projekt erwarteten Node-Version (unter Bezug auf .node-version, .nvmrc, package.json#engines usw.)
  • Script Runner nub run — Drop-in für npm/pnpm run, mit einem Rust-Binary ohne eigenen JS-Startup und dadurch beim Dispatch etwa 24× schneller als pnpm run (14.7ms vs 442.7ms)
    • Volle Unterstützung für pre-/post-Hooks sowie pnpm-Workspace-Optionen wie --filter und --parallel
  • Package Runner nubx — Drop-in für npx und pnpm dlx, entfernt den Double-Node-Spawn-Overhead und ist dadurch bei der Ausführung etwa 19× schneller als npx (11ms vs 226ms)
  • Package Manager nub install — basiert auf der Aube-Engine, flag-kompatibel mit pnpm, 2,5× schneller als pnpm und 3,7× schneller als npm
    • Integrierte Standardsicherheitsrichtlinien — blockiert postinstall, prüft bösartige Pakete über osv.dev, lehnt Provenance-Downgrades ab und setzt minimumReleaseAge auf 24 Stunden
    • Compat-Mode zur automatischen Erkennung von Lockfiles und Konfigurationen aus npm, pnpm, Yarn und Bun
  • Node Version Manager nub node — bietet manuelle Verwaltungsbefehle wie Versions-install, ls, uninstall und pin
  • Package Meta-Manager nub pm — übernimmt die Rolle von Corepack in nativem Rust und registriert globale Shims für npm, yarn und pnpm
  • MIT-Lizenz

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Meinungen auf Hacker News

  • Die Idee ist sehr gut und ergibt Sinn. Bun bietet zwar mehr Dinge wie DB-Treiber, aber die Developer Experience ist definitiv ein großer Teil des Reizes.
    Nebenbei: Der Hauptautor von Nub ist Colin McDonnell, der Zod entwickelt hat und früher auch bei Bun gearbeitet hat.

    • Genau. Nub baut absichtlich überhaupt keine Nub-spezifischen APIs ein: kein globales Nub-Objekt, keine eingebauten Module mit nub:-Präfix, keine Konfigurations-/Lock-Dateien mit Nub-Namen, kein nub-Feld in package.json und keine NUB_-Umgebungsvariablen.
      Ich finde, die meisten Dinge, die Bun hinzugefügt hat, sind besser als echte Dependencies aufgehoben.

  • Überraschend, dass es einen --require-Hook statt --import verwendet. Vielleicht hat sich seit der Zeit, als ich mir so etwas für eine ähnliche Funktion angesehen habe, einiges geändert, aber ich vermute, dass es bei der ESM-Unterstützung von Nub ein paar subtile Ecken gibt.
    Damals war --import in Node noch sehr früh, und beim üblichen ESM-to-CJS-Ansatz gab es mehrere Ausnahmen, die ich behandeln wollte. Die meisten davon waren wohl sehr spezielle Fälle, aber Top-Level await dürfte für einen relevanten Teil der Nutzer Auswirkungen haben.

    • Das wird rein aus Performance-Gründen für die Preload-Registrierung verwendet. In diesem und vielen anderen Fällen ist CommonJS immer noch schneller als ESM. --require hat etwa 0,5 ms Overhead, während --import auf einem M1 MacBook Pro etwa 4,6 ms braucht.
      In diesem Zusammenhang hat Node.js kürzlich, 2025, module.registerHooks() eingeführt, eine synchrone Version der API zur Registrierung von Resolver-Hooks, um die Performance gegenüber der alten asynchronen module.register()-API zu verbessern. Für Nub war das ein großes Hindernis, das damit aus dem Weg geräumt wurde. Für Interessierte: Die asynchrone API hatte einen festen Registrierungs-Overhead von 19 ms plus etwa 130 µs zusätzlichen Overhead pro Import.
      Welche Flags Nub hier verwendet, hat keinerlei Einfluss auf User-Code, und Top-Level await wird überall dort unterstützt, wo Node.js selbst es unterstützt.

  • Wir haben gerade einen PR gemergt, der unser gesamtes Monorepo auf nub migriert.
    Null Probleme, und es ist absurd schnell.

    • Ihr habt innerhalb einer Stunde nach Veröffentlichung einen PR gemergt, der ein gemeinsames Monorepo darauf migriert?

  • Konnte Node nicht schon seit ein paar Versionen TypeScript ausführen? Warum braucht man einen Transformer?

    • Nodes eingebaute TypeScript-Unterstützung macht nur Type Stripping. Das funktioniert für sehr viele Teile der TypeScript-Syntax, aber nicht für alle. Es prüft die Typen auch nicht wirklich, sondern entfernt sie nur, damit der Code läuft. Dinge wie tsconfig gehen dabei ebenfalls verloren.
      Das hier scheint sowohl die eingebaute Stripping-Variante als auch echte TypeScript-Verarbeitung zu unterstützen.
    • Das Node.js-Team hat --experimental-transform-types in Node.js v26 entfernt. Damit ist native vollständige TypeScript-Unterstützung unmöglich.
      https://github.com/nodejs/typescript/issues/51#issuecomment-...
    • Es heißt, dass bei Bedarf Polyfills injiziert werden, etwa für APIs wie Worker oder Temporal.

  • Im README steht, WebSocket-Unterstützung sei ab Node 22 nativ, aber Node hat keine native WebSocket-Bibliothek. Der Link zum WebSocket-Standard führt zu MDN, wo nur das WHATWG-User-Interface erklärt wird, nicht das Protokoll oder die Funktionsweise von WebSockets.
    Es fühlt sich so an, als fehle etwas oder als würde im Hintergrund eine nicht-native Bibliothek verwendet.

    • Node unterstützt ab Version 22 einen eingebauten WebSocket-Client, aber keinen Server.

  • Es ist respektabel, dass bestehende Technik angenommen wird, statt eine schlechtere Version davon neu zu bauen. Ich frage mich, wo Node heute unter guter Führung stünde, wenn all die Energie, die in Alternativen geflossen ist, in Node gegangen wäre.

    • Vielleicht erinnerst du dich an den io.js-Fork von Node.js aus dem Jahr 2014. Als Node stagnierte, haben mehrere Leute zu io.js geforkt; am Ende wurde es wieder in Node zurückgeführt und brachte Node wieder auf Kurs. Wenn man noch weiter zurückgeht: Auch CoffeeScript, ein „Fork“ von JS, hatte seine besten Ideen später in ES5 wiedergefunden.
      Kleine, bewegliche Teams können gute Ideen beweisen, weil ein Scheitern für sie kein existenzielles Risiko ist. Kurz gesagt: Forks sind Teil eines gesunden Ökosystems.
    • Es gibt vieles, was sich mit diesem Ansatz grundsätzlich nicht beheben lässt.
      Ein einfaches Beispiel: Node ist die einzige ernstzunehmende Open-Source-Software, die ich kenne, bei der es keine Möglichkeit gibt, Konfiguration direkt in der Konfigurationsdatei zu dokumentieren. Das ist absurd. Die Node-Seite hat ziemlich gedankenlos JSON übernommen und sich danach geweigert, irgendeine Alternative auch nur zu prüfen, selbst „JSON mit Kommentaren“.
      Wenn eine Organisation an schlechten Entscheidungen festhält, ist der einzige Weg zur Korrektur ein Neuanfang. Solange alle weiter auf Node aufbauen, wird das gesamte JS-Ökosystem keine Dokumentation in Konfigurationen hinterlassen können.
      Im Node-Ökosystem gibt es mehrere solche Probleme, und diese völlige Absurdität, Konfiguration nicht dokumentieren zu können, ist nur mein persönlicher wunder Punkt.

  • Ich bin Fan von Nub und dem Maskottchen nubnub. Im Ernst: ein tolles Projekt, ziemlich spannend, und ich probiere es seit letzter Woche aus, jedenfalls seit es öffentlich ist.

  • Clever. Wenn es schon in Rust geschrieben ist, verliert man nicht alle Kunden, während man per Vibe Coding die Migration nach Rust angeht ;)

    • Nach der Übernahme durch OpenAI wird das Projekt vermutlich auf Zig umgestellt.
    • Dieses Projekt besteht bereits zu einem großen Teil aus Vibe Coding. Der zweitgrößte Contributor im Repository ist Claude.
    • „Wenn es schon in Rust vibe-gecodet wurde“ wäre wohl besser. Bei Nub riecht man das insgesamt ziemlich stark. Ist okay, aber im Vergleich zu Bun ist es lustig.
      Nebenbei: Die Anti-AI-Hysterie rund um Bun ist sehr traurig und fühlt sich manchmal sogar wie eine organisierte Kampagne an.
    • Es hilft noch mehr, wenn es von Anfang an schon vibe-gecodet ist und es keine Kunden gibt.
    • Genau. Ich bin mir nicht sicher, was „in Rust geschrieben“ hier zusätzlich bringt. Ich hätte gedacht, dass dieselbe Funktionalität auch mit ein paar Shell-Skripten und package.json möglich wäre.