Aube: Der schnellste Node.js Package Manager 2026?

Node-Installationen sind seit Jahren langsam. Man führt npm install aus, geht zur Kaffeemaschine, kommt zurück, und CI löst immer noch @types/node auf. Aube ändert diese Gleichung. Es schließt eine warme CI-Installation eines echten 1.400-Pakete-Projekts in 139 Millisekunden ab, was etwa 7,3x schneller als pnpm und 3x schneller als Bun auf derselben Testumgebung ist. Der wirklich interessante Teil: Es liest und schreibt Ihre vorhandene Lockfile, sodass Sie es am Montag ausprobieren können, ohne jemanden um eine Migration bitten zu müssen.

Dieser Leitfaden behandelt, was Aube ist, wie es diese Zahlen erreicht, wie man es installiert, wie es sich im Vergleich zu pnpm, npm, yarn und Bun schlägt und wo es passt, wenn Sie täglich APIs mit Tools wie Apidog entwickeln.

Was ist Aube?

Aube ist ein schneller Node.js-Paketmanager, der von en.dev entwickelt und unter der MIT-Lizenz veröffentlicht wurde. Der Name bedeutet im Französischen „Morgendämmerung“ und wird „ohb“ ausgesprochen. Das Projekt befindet sich in der Beta-Phase (v1.0.0-beta.10 zum Zeitpunkt der Erstellung) und strebt die Kompatibilität mit pnpm v11 als oberstes Ziel an.

Das Konzept ist einfach. Aube verwendet dasselbe On-Disk-Modell wie pnpm, einen globalen inhaltsadressierbaren Speicher plus ein isoliertes Symlink-Layout, aber die Installations-Pipeline ist in einer nativ-threaded Sprache anstatt in JavaScript geschrieben. Gleiches Layout, schnellere Engine. Diese einzige Designentscheidung ermöglicht es, Bun in mehreren Benchmark-Szenarien zu übertreffen, während immer noch pnpm-lock.yaml an seinen Platz zurückgeschrieben wird.

Wenn Sie bereits einmal zwischen Paketmanagern migriert sind, wissen Sie, dass die wahren Kosten nicht das Tool sind; es sind die sozialen Kosten, alle in Ihrem Team dazu zu bringen, zu ändern, wie sie install ausführen. Aube umgeht dies, indem es pnpm-lock.yaml, package-lock.json, npm-shrinkwrap.json, yarn.lock und bun.lock direkt liest. Sie können es lokal ausführen, während Ihr CI weiterhin pnpm verwendet, und für Teammitglieder ändert sich nichts.

Aube-Benchmarks: wie schnell ist „am schnellsten“?

Die Benchmark-Umgebung ist ein reales Projekt mit ca. 1.400 Paketen, gemessen mit hyperfine. Jedes Szenario geht von einer festgeschriebenen Lockfile aus. Die Achse, die variiert, ist die Cache-Wärme: warm löscht node_modules, behält aber den globalen Store und den Packument-Cache, kalt löscht alles.

Zahlen aus den offiziellen Benchmarks (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):

Einige Dinge stechen hervor. Die warme CI-Installation ist die Schlagzeile, weil sie den häufigsten Fall in realen Pipelines widerspiegelt, wo der Runner einen Cache wiederherstellt und Ihr globaler Store immer noch jedes Tarball gehasht enthält. In diesem Szenario ist Aube etwa 7,3x schneller als pnpm und 3x schneller als Bun.

Das Szenario install && run test misst den täglichen Entwickler-Workflow. Jedes Tool muss entscheiden: „Muss ich zuerst installieren, dann das Skript ausführen?“ Aube kann die Installationsarbeit komplett überspringen, wenn seine Installationsstatus-Datei aktuell ist, sodass der gesamte install && test-Zyklus in 21ms abgeschlossen ist. Andere Tools validieren die Lockfile immer noch neu, bevor sie das Skript ausführen, woraus der Overhead von 400ms-600ms resultiert.

Bei einem kalten Cache liegt Bun knapp vor Aube (935ms vs. 1.12s), da Buns Tarball-Abrufpfad extrem gut abgestimmt ist und kalte Installationen stark von E/A-Operationen dominiert werden. Warm ist das Szenario, das auf einem typischen Entwicklungsteam Tausende Male am Tag ausgeführt wird; kalt läuft einmal im Monat, wenn man einen Runner komplett löscht.

Über den gesamten Benchmark-Satz hinweg weisen die Docs je nach Szenario Spitzen von bis zu 22x schneller als pnpm und bis zu 3x schneller als Bun aus. Sie können all dies lokal mit mise run bench aus dem Aube-Repository reproduzieren.

Warum Aube schneller als pnpm und Bun ist

Drei Designentscheidungen leisten die Hauptarbeit.

• Native, threaded Installations-Pipeline. npm, pnpm und yarn führen alle die Installations-Engine in Node.js aus. Das bedeutet, dass jeder Hash, jede Tarball-Extraktion, jeder Symlink-Aufruf die JavaScript-Dispatch-Steuer zahlt. Aube verlagert den Hot Path aus V8 in eine nativ kompilierte, nativ-threaded Laufzeitumgebung. Bun macht etwas Ähnliches, liefert aber eine vollständige JavaScript-Laufzeitumgebung zusammen mit seinem Paketmanager aus; Aube ist zweckgebunden für den Installationspfad, weshalb es Bun bei warmen Installationen schlägt.
• Globaler virtueller Store ist der Standard. pnpm v11 hat enableGlobalVirtualStore hinzugefügt, aber es ist nicht der Standard für Projektinstallationen. Aube verwendet standardmäßig einen globalen virtuellen Store, sodass wiederholte Projekte mit überlappenden Abhängigkeiten größtenteils auf Paketbäume verweisen, die bereits auf der Festplatte vorhanden sind. Wenn Sie drei Dienste haben, die alle React, Vite, TypeScript und Playwright verwenden, leben die großen Dateien an einem Ort und jedes Projekt verlinkt darauf. Die Dokumentation schätzt ~90% weniger Speicherplatz als npm in typischen Mono-Repo-Setups.
• Installations-Kurzschluss mit einer aktuellen Statusdatei. aube run test prüft zuerst eine kompakte Installationsstatus-Datei. Wenn Ihr package.json- und Lockfile-Hash mit der Statusdatei übereinstimmt, besteht die Installationsphase aus einem einzigen stat-Aufruf und der Test wird sofort ausgeführt. Dies senkt die install && test-Zahl auf 21ms.

Nichts davon ist Magie. Es ist das Ergebnis, wenn man das pnpm-Layout übernimmt, den JavaScript-Bootstrap entfernt und die CLI um die Annahme herum entwirft, dass sich bei 99 Prozent der Installationen „tatsächlich nichts geändert hat“.

Wie man Aube installiert

Der empfohlene Weg ist mise, der polyglotte Tool-Manager:

mise use -g aube

Prüfen Sie, ob es in Ihrem PATH gelandet ist:

aube --version

Wenn Sie npm bevorzugen:

npm install -g @endevco/aube

Auf macOS oder Linux mit Homebrew enthält der Endev-Tap es:

brew install endevco/tap/aube

Innerhalb eines Projekts können Sie die Aube-Version lokal festlegen:

mise use aube

Das schreibt aube als Tool in Ihre mise.toml, was bedeutet, dass jede Shell, die in den Projektordner wechselt, dieselbe Version erhält. Kein „funktioniert auf meinem Rechner, weil ich pnpm 10 letztes Jahr installiert habe“ mehr. Die Installationsdokumentation behandelt auch die Tarball- und pro-OS-Optionen.

Tägliche Befehle, die Sie tatsächlich verwenden werden

Die Befehlsoberfläche spiegelt pnpm stark wider, sodass die Muskelgedächtnisübertragung funktioniert:

aube install              # install dependencies
aube add react            # add a dependency
aube add -D vitest        # add a dev dependency
aube remove react         # remove a dependency
aube update               # update within package.json ranges
aube run build            # run a package.json script
aube test                 # run test script, installing first if stale
aube exec vitest          # run a local binary
aube dlx cowsay hi        # run a package in a throwaway env
aube ci                   # clean, frozen install for CI

Sie können die meisten davon abkürzen. Wenn das Skript in package.json existiert, ist aube dev dasselbe wie aube run dev. Es gibt auch zwei Multicall-Shims, die im selben Binärpaket enthalten sind:

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

Verwenden Sie aube ci in Pipelines. Es entfernt node_modules, bestätigt, dass die Lockfile für die aktuelle package.json aktuell ist, und installiert dann. Wenn die Lockfile abweicht, schlägt es laut fehl, was Sie in CI wünschen.

Lockfile-Kompatibilität

Dies ist die Funktion, die Aube zu einer risikoarmen Einführung macht. Sie müssen sich nicht verpflichten, das gesamte Team umzustellen.

Das praktische Muster sieht so aus: Ihr Team verwendet pnpm. CI führt immer noch pnpm install --frozen-lockfile aus. Sie führen aube install lokal auf Ihrem Rechner aus. Es liest pnpm-lock.yaml, erzeugt dasselbe node_modules-Layout und schreibt alle Auflösungsaktualisierungen in dieselbe pnpm-lock.yaml zurück. Ein Teamkollege zieht Ihren Branch, führt pnpm install aus, und es gibt keine Probleme. Im Laufe der Zeit, wenn sich Aube bewährt, migrieren Sie CI. Wenn nicht, entfernen Sie es, und niemand stromabwärts weiß davon.

Zwei Vorbehalte. Alte pnpm v5 oder v6 Lockfiles müssen zuerst mit pnpm aktualisiert werden. Und Yarn PnP-Projekte (der .pnp.cjs-Stil) müssen zu einem node_modules-Linker zurückkehren, da Aube node_modules schreibt, nicht PnP-Artefakte.

Sichere Standardeinstellungen sind wichtiger, als Sie denken

Wenn Sie in den letzten 18 Monaten auch nur in der Nähe einer JavaScript-Codebasis waren, haben Sie gesehen, wie sich Lieferkettenvorfälle häufen. Der npm-Leitfaden zur Sicherheit der Lieferkette beschreibt das Muster; der Axios npm-Kompromiss war einer der klarsten realen Fälle, wie eine einzelne beliebte Abhängigkeit ein plattformübergreifendes RAT an Tausende von Entwickler-Maschinen liefern kann.

Aube nimmt drei meinungsstarke Standardeinstellungen vor, die Installationen als Sicherheitsgrenze und nicht als Bequemlichkeit behandeln:

1. Mindestalter für Releases. Neue Releases warten ein konfigurierbares Mindestalter ab, bevor Aube sie installiert. Ein frisch kompromittiertes Paket, das innerhalb von zwei Stunden entfernt wird, berührt niemals Ihre node_modules.
2. Blockierung exotischer Abhängigkeiten. Aube blockiert transiente Abhängigkeiten, deren Formen verdächtig aussehen (ungewöhnliche URLs, patch-ähnliche Einträge, Git-Refs an Stellen, die normalerweise Semver tragen). Wenn Sie eine explizit wünschen, genehmigen Sie sie.
3. Genehmigung von Lifecycle-Skripten. postinstall-Skripte von Abhängigkeiten werden standardmäßig übersprungen. Sie führen aube approve-builds aus, um bestimmte Pakete (esbuild, node-sass, was auch immer Sie lokal tatsächlich bauen müssen) zu erlauben. Pakete, deren Skripte übersprungen wurden, erscheinen in aube ignored-builds.

Diese drei Verhaltensweisen machen Sie nicht unverwundbar, aber sie wandeln „Ich wusste nicht, dass dieses Paket überhaupt Code ausführte“ in „Ich habe mich dafür entschieden, dass dieses Paket Code ausführt“ um. Das ist die Sicherheitshaltung, die Sie vor Ihrem nächsten Produktionsvorfall wünschen.

Node-Module-Layout

Aube verwendet ein isoliertes node_modules-Layout. Das oberste node_modules/ enthält die Abhängigkeiten, die Ihre package.json deklariert hat. Transitive Abhängigkeiten befinden sich hinter node_modules/.aube/. Die Paketdateien selbst werden genau einmal unter $XDG_DATA_HOME/aube/store/ gespeichert, was standardmäßig ~/.local/share/aube/store/ ist.

Drei Konsequenzen:

• Mehrere Projekte mit überlappenden Abhängigkeiten teilen sich Paketdateien auf der Festplatte. Kein „Ich habe 12 Kopien von lodash über mein Monorepo und meine Nebenprojekte verteilt“ mehr.
• Phantom-Abhängigkeiten sind schwieriger. Wenn ein Paket nicht in Ihrer package.json ist, können Sie es nicht von der obersten Ebene requiren, da es nicht in node_modules/ ist. Dies ist dieselbe Garantie, die pnpm Ihnen gibt.
• Wiederholte Installationen verwenden bereits auf der Festplatte vorhandene Dateien wieder. Die einzige verbleibende Arbeit ist das Hard-Linking vom Store in das neue node_modules/.aube/.

Wenn Sie zuvor mit einem flachen node_modules-Layout (klassisches npm oder yarn v1) gearbeitet haben, erwarten Sie, ein oder zwei fehlerhafte Pakete zu finden, die sich auf Phantom-Imports verlassen haben. Die Lösung ist immer: „Fügen Sie es Ihrer package.json hinzu.“

Workspaces und Monorepos

Aube unterstützt Workspaces und das workspace:-Protokoll:

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

Wenn Ihr Repository bereits pnpm-workspace.yaml enthält, liest und schreibt Aube diese Datei. Neue Aube-first-Workspaces verwenden aube-workspace.yaml. Die Flags -r (rekursiv) und --filter bilden dieselbe Semantik ab, die Sie von pnpm erwarten, sodass Turborepo- und nx-Setups ohne Änderungen weiter funktionieren.

Für API-Monorepos ist die warm-cache CI-Zahl am wichtigsten. Wenn Ihre Pipeline bei jeder Zusammenführung install, build, test, publish contract ausführt, summiert sich die Reduzierung von `install` von pnmp's 1 Sekunde auf Aube's 139 Millisekunden über zehn Pakete zu echten Minuten pro Tag.

Wo Aube in einen API-Entwicklungs-Workflow passt

Wenn Sie APIs entwickeln und testen, liegen Installationen im Hot Path jedes Refactorings. Sie ändern ein Anforderungsschema, generieren den TypeScript-Client neu, installieren erneut, führen Vertragstests gegen Ihren Mock-Server aus, wiederholen. Eine schnelle Installation ist keine Eitelkeitsmetrik; es ist das Intervall zwischen „Ich habe dies geändert“ und „Ich weiß, ob es kaputt ist“.

Ein praktischer und gut funktionierender Ablauf:

1. Entwerfen und mocken Sie die API in Apidog. Schema-first ist besser als Code-first für alles, was mit einem anderen Team kommuniziert.
2. Generieren Sie einen typisierten Client (oder führen Sie Vertragstests gegen den Apidog-Mock aus) innerhalb Ihres Node-Projekts.
3. Verwenden Sie Aube lokal, um Installationen im Millisekundenbereich zu halten, während Sie am Client iterieren.
4. Verbinden Sie dieselbe Testsuite mit aube ci in CI.

Der Tooling-Wechsel weg von Postman im letzten Jahr ist Teil eines größeren Musters: Entwickler wünschen sich Tools, die schnell, lokal-zuerst und standardmäßig sicher sind. Aube ist dieselbe Geschichte, angewendet auf den Installationsschritt. Wenn Sie bereits Apidog in VS Code verwenden, kostet das Hinzufügen von Aube daneben eine mise use-Zeile und spart Sekunden bei jedem Hot-Reload.

Migration von jedem Paketmanager

Von npm. Führen Sie aube install im Projekt aus. Aube liest package-lock.json und schreibt es zurück. Sie erhalten isolierte node_modules anstelle eines flachen Layouts, achten Sie also auf Phantom-Imports. Wenn einer bricht, fügen Sie das fehlende Paket zu package.json hinzu und fahren Sie fort. Den vollständigen Workflow finden Sie im npm-Benutzerhandbuch.

Von pnpm. Dies ist die reibungsärmste Migration, da das On-Disk-Layout dasselbe ist. Aube liest pnpm-lock.yaml v9 direkt. Das workspace:-Protokoll funktioniert. Filter funktionieren. Die pnpm-users-Seite listet die wenigen Flags auf, die sich anders verhalten.

Von yarn. Aube liest sowohl v1 Classic als auch v2+ Berry Lockfiles. Yarn PnP-Benutzer müssen vor dem Ausprobieren von Aube auf den nodeLinker: node-modules-Modus zurückwechseln, da Aube node_modules schreibt und nicht .pnp.cjs.

Von Bun. Aube liest bun.lock. Der Hauptunterschied ist, dass Buns Paketmanager eng mit Buns JS-Laufzeitumgebung gekoppelt ist; Aube ist ein eigenständiges Installationstool, das mit jeder Node.js-Version läuft. Wenn Sie bereits mise für das Node-Versionsmanagement verwenden, fügt sich Aube auf die gleiche Weise ein.

Praktische Überlegungen

Beta-Status. Stand April 2026 ist Aube v1.0.0-beta.10. Die Dokumentation ist explizit: Es zielt auf pnpm v11-Kompatibilität ab, wurde aber noch nicht in vielen Projekten getestet. Behandeln Sie es wie jedes Tool vor Version 1.0. Führen Sie es zuerst lokal aus, behalten Sie Ihre vorhandene Lockfile und setzen Sie Ihre Produktions-Release-Pipeline nicht darauf, bevor Sie es einen Monat lang in Aktion gesehen haben.

Was nicht im Umfang enthalten ist. Aube dupliziert absichtlich nicht, was mise bereits tut. Laufzeitverwaltung (env, runtime, setup, self-update) gehört dorthin. Einige Registry-Kontohelfer (whoami, token, owner, search, pkg, set-script) sind Kompatibilitäts-Stubs, die Sie stattdessen auf den npm-Befehl verweisen. Wenn Ihr CI-Skript einen dieser Befehle aufruft, behalten Sie npm als Fallback bei.

Plattformunterstützung. Der empfohlene Installer ist mise, der macOS, Linux und Windows über WSL unterstützt. Native Windows-Unterstützung über den Tarball existiert, befindet sich aber in einem früheren Stadium; überprüfen Sie die Installationsseite für die aktuelle Matrix.

Community. Das Projekt hat einen Discord (von der Homepage verlinkt) und zum Zeitpunkt der Erstellung 325 Sterne auf GitHub. Klein, aber aktiv. Buildkite stellt CI für das Projekt bereit, was Sie im Repository-Stammverzeichnis sehen können.

FAQ

Was bedeutet „aube“?Morgendämmerung, auf Französisch. Ausgesprochen „ohb“. Der Slogan des Projekts lautet „eine neue Morgendämmerung für Node-Installationen“.

Ist Aube ein Drop-in-Ersatz für pnpm?Nah dran. Es zielt auf pnpm v11-Kompatibilität ab und liest das Lockfile-Format von pnpm. Die meisten pnpm-ähnlichen Workflows können ohne Änderungen übernommen werden. Einige pnpm-Befehle (Laufzeitverwaltung, einige Registry-Helfer) sind absichtlich nicht im Umfang enthalten, da sie zu anderen Tools gehören.

Kann ich Aube in CI verwenden, während ich pnpm lokal behalte?Ja, beide Richtungen funktionieren. Aube liest und schreibt pnpm-lock.yaml an Ort und Stelle, sodass die beiden Tools eine Lockfile teilen können. Teams beginnen üblicherweise umgekehrt: Aube lokal, pnpm in CI, bis sich alle wohlfühlen.

Wie verhält sich Aube im Vergleich zu Bun?Bei warmen Installationen ist Aube etwa 3x schneller als Bun, weil Bun vor der Installation mehr Status neu validiert. Bei kalten Installationen liegt Bun leicht vorne, da sein Abrufpfad extrem optimiert ist. Bun liefert auch eine JS-Laufzeitumgebung mit; Aube ist nur zur Installation gedacht. Wenn Sie bereits Node verwenden, benötigen Sie Buns Laufzeitumgebung nicht, um Aube zu nutzen. Der Vergleich des isolierten Layouts im pnpm-Stil gibt Kontext, warum Layout-Entscheidungen wichtig sind.

Funktioniert Aube unter Windows?Über WSL, ja. Native Windows-Unterstützung funktioniert, befindet sich aber in einem früheren Stadium. `mise` ist der einfachste Weg zur Installation und Aktualisierung auf allen drei Betriebssystemen.

Ist Aube Open Source?Ja, MIT-lizenziert, Quellcode auf GitHub.

Was passiert mit meiner bestehenden pnpm-lock.yaml?Aube liest sie, führt die Installation durch und schreibt dieselbe Datei mit allen Auflösungsänderungen zurück. Ihre Teamkollegen, die pnpm verwenden, sehen einen normalen Lockfile-Diff.

Fazit

Für die meisten Node-Projekte im Jahr 2026 ist der Installationsschritt langsamer als nötig. Aube ist der schnellste Node.js-Paketmanager für warme Installationen und wiederholte Befehlspfade, die echte Entwickler-Workflows dominieren: 139 ms für eine CI-Installation mit 1.400 Paketen, 21 ms für install && test, wenn sich nichts geändert hat, 90 % weniger Speicherplatz auf einem Rechner mit mehreren Projekten. Es liest Ihre vorhandene Lockfile, nimmt Sicherheitsstandards ernst und kostet eine mise use aube-Zeile, um es auszuprobieren.

Wenn Sie APIs bereits mit einem schnellen, lokal-ersten Client wie Apidog testen, ist Aube das passende Gegenstück auf der Installationsseite. Laden Sie Apidog herunter, falls Sie es noch nicht getan haben, kombinieren Sie es mit Aube für Ihren nächsten Node-Service und sehen Sie, wie viel enger der Feedback-Loop wird.