Most performance claims in the JavaScript tooling space have the shelf life of milk. Someone installs a few packages on a quiet Tuesday morning, captures the terminal output, and publishes a dramatic bar chart. By the next sprint, one of the tools has shipped a patch that invalidates the whole thing. The post remains indexed by search engines. The chart keeps getting shared. The numbers, however, are already lying to you.

This is the rot that infects nearly all package manager benchmarks. They are event photography when what we need is a live feed.

A project called depjs/canary treats this problem as a machine responsibility rather than a content calendar task. It is a living benchmark that watches npm, pnpm, Yarn, and dep, then re-runs its entire suite the moment any of them publishes a new version. The results are public, continuous, and unavoidable. When something breaks, the repository stays red until it heals. There is no cherry-picking, no hiding behind an old blog post, and no assumption that last month’s winner still holds the crown.

Why Speed Claims Need an Expiration Date

JavaScript package managers do not stand still. The gap between minor versions can include rewritten resolution algorithms, altered hoisting strategies, or changes to how the global cache is keyed. A benchmark that captures npm 10.2.1 and pnpm 8.11.0 tells you almost nothing about how those same tools behave two releases later. Yet the web is full of definitive statements like “Tool X is three times faster” based on exactly that kind of frozen snapshot.

Worse, many tests ignore the conditions that define real developer pain. A package manager might blaze through an install in a warm, well-rehearsed environment and then crawl on a CI runner that starts with an empty disk. Without testing both extremes, the benchmark becomes a press release rather than usable engineering data.

How the Canary Automates Comparison

Every two hours, a job polls the npm registry. If a new version of npm, pnpm, Yarn, or dep appears, the canary wakes up. It does not wait for a human to notice the changelog. It immediately executes a full test matrix that pits all four managers against five popular, real-world packages. The selection includes heavy hitters like React, Next.js, and Vite, codebases that actual developers install every day. These are not synthetic micro-projects designed to flatter one particular tool.

This release-triggered approach matters because it ties measurement directly to change. If the benchmark only ran on a nightly schedule, it might miss a mid-day hotfix or swallow a regression for hours. By running specifically on new versions, the canary asks a direct question each time: did this release make things better or worse?

The Four Scenarios That Stress Different Muscles

The test matrix is built around four distinct setups that map directly to workflows you will recognize.

  • Cold cache, no lockfile. This is the fresh clone on a new laptop, or the first install after deleting node_modules. Nothing is cached. Nothing is pinned. The package manager has to resolve, fetch, and write everything from scratch.
  • Warm cache, with lockfile. This is the happy path for continuous integration when things go right. The lockfile exists locally, and the cache still holds the tarballs from a previous run. The tool should move fast because most decisions are already made.
  • Cold cache, with lockfile. Here the lockfile is present, but the cache has been wiped. The manager can skip dependency resolution, yet it still has to download every byte across the network. This isolates network speed from resolution speed.
  • Warm cache, no lockfile. The cache is hot, but the lockfile is gone. The package manager must re-resolve the dependency tree before it can even begin extracting files. This tests the efficiency of the solver and the metadata parser under ideal network conditions.

Each scenario is executed five times, and the canary keeps the median result. That single choice kills a lot of noise. One transient network hiccup or a brief spike in registry latency cannot hijack the narrative. The outlier gets ignored; the typical experience gets recorded.

Smoke Tests Beat Empty Timers

La vitesse brute est facile à simuler si l'on ne vérifie pas le résultat. Un gestionnaire de paquets pourrait sauter les étapes de post-installation, corrompre quelques liens symboliques ou installer les mauvaises versions, tout en affichant un horodatage impressionnant. Le canary refuse de s'arrêter au simple chronomètre. Une fois l'installation terminée, il teste réellement le code installé.

Par exemple, il lance une application Express et confirme que le serveur commence à écouter sur le port attendu. Si le code ne s'exécute pas, le benchmark échoue immédiatement. Le test de fumée (smoke test) transforme la suite, passant d'une course à un audit. Il répond à la question que la vitesse seule ne peut résoudre : l'installation fonctionne-t-elle réellement ?

L'honnêteté radicale comme fonctionnalité

L'auteur du canary a intégré trois règles au processus que la plupart des auteurs de benchmarks considèrent comme facultatives.

Un terrain de jeu équitable. Des drapeaux (flags) sont utilisés pour normaliser le comportement entre les outils. Si un gestionnaire de paquets dissimule un défaut de performance derrière un paramètre par défaut, le benchmark l'expose plutôt que de laisser l'outil paraître performant par accident.

De véritables démarrages à froid. Avant chaque répétition, et pas seulement la première, le cache npm et le store pnpm sont vidés. Ce mot « chaque » est crucial. De nombreux benchmarks vident le cache une seule fois, puis lancent cinq installations consécutives. Les deuxième à cinquième exécutions ne sont pas réellement à froid, et les chiffres s'en trouvent gonflés. Le canary repart de zéro à chaque fois.

Des états d'échec publics. Lorsqu'une nouvelle version casse quelque chose, le dépôt reste dans un état d'échec « rouge ». Il reste affiché sur la page d'accueil, moche et non résolu, jusqu'à ce qu'un correctif soit déployé. Il n'y a pas de suppression silencieuse pour maintenir le tableau de bord au vert. Cette politique impose la visibilité. Un utilisateur évaluant des outils peut voir non seulement lequel est le plus rapide, mais lequel est resté fiable dans le temps.

L'inspectabilité est non négociable

Un benchmark que l'on ne peut pas reproduire n'est qu'un slogan de campagne. Le canary répond à ce problème avec un simple script bash qui permet à n'importe qui d'exécuter n'importe quelle partie de la suite localement. Vous n'avez pas besoin de faire confiance au réseau d'un fournisseur cloud ou à l'environnement ajusté à la main par un mainteneur. Si vous soupçonnez que les chiffres sont erronés, vous pouvez générer les vôtres.

Cette transparence rend également le projet utile pour les mainteneurs. Lorsqu'une régression survient, un développeur en aval peut récupérer le script, effectuer un bisection sur les versions de l'outil et remettre à l'équipe en amont un