Die meisten Leistungsversprechen im Bereich der JavaScript-Tooling-Landschaft haben die Haltbarkeit von Milch. Jemand installiert an einem ruhigen Dienstagmorgen ein paar Pakete, erfasst die Terminalausgabe und veröffentlicht ein dramatisches Balkendiagramm. Bis zum nächsten Sprint hat eines der Tools einen Patch veröffentlicht, der das Ganze hinfällig macht. Der Beitrag bleibt jedoch in Suchmaschinen indexiert. Das Diagramm wird weiterhin geteilt. Die Zahlen hingegen lügen bereits.

Dies ist die Fäulnis, die fast alle Benchmarks von Paketmanagern befällt. Sie sind wie Event-Fotografie, während wir eigentlich einen Live-Feed benötigen.

Ein Projekt namens depjs/canary betrachtet dieses Problem als eine Aufgabe der Maschine und nicht als eine Aufgabe für den Redaktionsplan. Es ist ein lebendiger Benchmark, der npm, pnpm, Yarn und dep beobachtet und dann seine gesamte Suite genau in dem Moment erneut ausführt, in dem einer von ihnen eine neue Version veröffentlicht. Die Ergebnisse sind öffentlich, kontinuierlich und unvermeidlich. Wenn etwas kaputtgeht, bleibt das Repository rot, bis es wieder funktioniert. Es gibt kein Cherry-Picking, kein Verstecken hinter einem alten Blogpost und keine Annahme, dass der Gewinner des letzten Monats immer noch die Krone trägt.

Warum Geschwindigkeitsversprechen ein Ablaufdatum benötigen

JavaScript-Paketmanager stehen nicht still. Der Abstand zwischen Minor-Versionen kann neu geschriebene Auflösungsalgorithmen, geänderte Hoisting-Strategien oder Änderungen an der Art und Weise enthalten, wie der globale Cache indiziert wird. Ein Benchmark, der npm 10.2.1 und pnpm 8.11.0 erfasst, sagt Ihnen fast nichts darüber aus, wie sich dieselben Tools zwei Releases später verhalten. Dennoch ist das Web voll von definitiven Aussagen wie „Tool X ist dreimal schneller“, die genau auf solchen eingefrorenen Schnappschüssen basieren.

Schlimmer noch: Viele Tests ignorieren die Bedingungen, die den echten Schmerz für Entwickler definieren. Ein Paketmanager mag eine Installation in einer warmen, eingespielten Umgebung im Handumdrehen durchlaufen, aber auf einem CI-Runner, der mit einer leeren Festplatte startet, nur kriechen. Ohne beide Extreme zu testen, wird der Benchmark eher zu einer Pressemitteilung als zu nutzbaren technischen Daten.

Wie der Canary den Vergleich automatisiert

Alle zwei Stunden fragt ein Job das npm-Registry ab. Wenn eine neue Version von npm, pnpm, Yarn oder dep erscheint, erwacht der Canary. Er wartet nicht darauf, dass ein Mensch das Changelog bemerkt. Er führt sofort eine vollständige Testmatrix aus, die alle vier Manager fünf populären, realen Paketen gegenüberstellt. Die Auswahl umfasst Schwergewichte wie React, Next.js und Vite – Codebasen, die tatsächliche Entwickler jeden Tag installieren. Dies sind keine synthetischen Mikroprojekte, die darauf ausgelegt sind, ein bestimmtes Tool zu schmeicheln.

Dieser durch Releases ausgelöste Ansatz ist wichtig, weil er die Messung direkt mit der Veränderung verknüpft. Wenn der Benchmark nur nach einem nächtlichen Zeitplan liefe, würde er vielleicht einen Hotfix am Mittag übersehen oder eine Regression stundenlang verschlucken. Durch das gezielte Ausführen bei neuen Versionen stellt der Canary jedes Mal eine direkte Frage: Hat dieses Release die Dinge besser oder schlechter gemacht?

Die vier Szenarien, die unterschiedliche Muskeln beanspruchen

Die Testmatrix ist um vier verschiedene Setups herum aufgebaut, die direkt auf Workflows abgebildet sind, die Sie kennen werden.

  • Kalter Cache, keine Lockfile. Dies entspricht einem frischen Clone auf einem neuen Laptop oder der ersten Installation nach dem Löschen von node_modules. Nichts ist gecacht. Nichts ist fixiert. Der Paketmanager muss alles von Grund auf auflösen, abrufen und schreiben.
  • Warmer Cache, mit Lockfile. Dies ist der „Happy Path“ für die Continuous Integration, wenn alles glattläuft. Die Lockfile existiert lokal und der Cache enthält noch die Tarballs aus einem vorherigen Durchlauf. Das Tool sollte schnell sein, da die meisten Entscheidungen bereits getroffen wurden.
  • Kalter Cache, mit Lockfile. Hier ist die Lockfile vorhanden, aber der Cache wurde geleert. Der Manager kann die Abhängigkeitsauflösung überspringen, muss aber dennoch jedes Byte über das Netzwerk herunterladen. Dies isoliert die Netzwerkgeschwindigkeit von der Auflösungsgeschwindigkeit.
  • Warmer Cache, keine Lockfile. Der Cache ist warm, aber die Lockfile ist weg. Der Paketmanager muss den Abhängigkeitsbaum erneut auflösen, bevor er überhaupt mit dem Entpacken der Dateien beginnen kann. Dies testet die Effizienz des Solvers und des Metadaten-Parsers unter idealen Netzwerkbedingungen.

Jedes Szenario wird fünfmal ausgeführt, und der Canary behält das Median-Ergebnis bei. Diese eine Entscheidung eliminiert viel Rauschen. Ein vorübergehender Netzwerkfehler oder ein kurzer Anstieg der Latenz des Registries kann die Erzählung nicht kapern. Der Ausreißer wird ignoriert; die typische Erfahrung wird aufgezeichnet.

Smoke-Tests schlagen leere Timer

Raw speed is easy to fake if you do not verify the outcome. A package manager could skip postinstall steps, corrupt a few symlinks, or install the wrong versions and still post an impressive timestamp. The canary refuses to stop at the timer. After the installation finishes, it actually exercises the installed code.

For example, it boots up an Express application and confirms that the server starts listening on the expected port. If the code does not run, the benchmark fails outright. The smoke test transforms the suite from a race into an audit. It answers the question that speed alone cannot: does the installation actually work?

Radical Honesty as a Feature

The author of the canary wrote three rules into the process that most benchmark authors treat as optional.

Same playing field. Flags are used to normalize behavior across tools. If one package manager hides a performance flaw behind a default setting, the benchmark exposes it rather than letting the tool look good by accident.

Genuine cold starts. Before every single repetition, not just the first one, the npm cache and the pnpm store get wiped. That word "every" is doing heavy labor. Many benchmarks clear the cache once, then run five installs in a row. The second through fifth runs are not truly cold, and the numbers inflate accordingly. The canary starts from zero each time.

Public failure states. When a new release breaks something, the repository remains in a red failure state. It sits there on the front page, ugly and unresolved, until a fix ships. There is no silent suppression to keep the dashboard looking green. This policy forces visibility. A user evaluating tools can see not just which one is fastest, but which one stayed reliable over time.

Inspectability Is Non-Negotiable

A benchmark that you cannot reproduce is a campaign slogan. The canary addresses this with a single bash script that lets anyone run any slice of the suite locally. You do not need to trust a cloud provider’s networking or a maintainer’s hand-tweaked environment. If you suspect the numbers are off, you can generate your own.

That transparency also makes the project useful for maintainers. When a regression hits, a downstream developer can pull the script, bisect the tool’s releases, and hand the upstream team a