JavaScriptツールのパフォーマンスに関する主張の多くは、牛乳の賞味期限のように短い。ある火曜日の朝にパッケージをいくつかインストールし、ターミナルの出力を取得して、劇的な棒グラフを公開する。しかし次のスプリントまでには、ツールの一つがパッチをリリースし、そのすべてを無効にしてしまう。それにもかかわらず、その記事は検索エンジンにインデックスされたまま。グラフは共有され続ける。しかし、その数字はすでに嘘をついている。

これは、ほぼすべてのパッケージマネージャーのベンチマークに蔓延している腐敗です。私たちが本当に必要としているのはライブ配信であるにもかかわらず、それらはイベントの静止写真に過ぎないのです。

depjs/canary というプロジェクトは、この問題をコンテンツカレンダーのタスクではなく、機械が担うべき責任として扱っています。これは、npm、pnpm、Yarn、depを監視し、それらのいずれかが新しいバージョンを公開した瞬間にテストスイート全体を再実行する、生きたベンチマークです。結果は公開され、継続的であり、避けようのないものです。何かが壊れた場合、リポジトリは修復されるまで赤（失敗状態）のままになります。チェリーピッキングも、古いブログ記事の後ろに隠れることも、先月の勝者が今も王座を守っているという想定もありません。

なぜ速度の主張には有効期限が必要なのか

JavaScriptのパッケージマネージャーは停滞しません。マイナーバージョンの間には、解決アルゴリズムの書き換え、ホイスティング戦略の変更、あるいはグローバルキャッシュのキーの作成方法の変更などが含まれることがあります。npm 10.2.1 と pnpm 8.11.0 を捉えたベンチマークは、それらのツールが2リリース後にどのように動作するかについては、ほとんど何も教えてくれません。それにもかかわらず、ウェブ上には、まさにそのような固定されたスナップショットに基づいた「ツールXは3倍速い」といった決定的な言明が溢れています。

さらに悪いことに、多くのテストは、開発者が実際に直面する苦痛を定義する条件を無視しています。パッケージマネージャーは、準備の整った環境ではインストールを猛スピードで完了させるかもしれませんが、空のディスクから始まるCIランナーでは低速になるかもしれません。両方の極端なケースをテストしなければ、ベンチマークは実用的なエンジニアリングデータではなく、単なるプレスリリースになってしまいます。

Canaryはいかにして比較を自動化するか

2時間ごとに、ジョブがnpmレジストリをポーリングします。npm、pnpm、Yarn、またはdepの新しいバージョンが現れると、canaryが目覚めます。人間が変更履歴（changelog）に気づくのを待つことはしません。4つのマネージャーすべてを、5つの人気のある実用的なパッケージと対決させるフルテストマトリックスを即座に実行します。選択されるのは、React、Next.js、Viteといった、実際の開発者が毎日インストールする主要なパッケージです。これらは、特定のツールを喜ばせるために設計された人工的なマイクロプロジェクトではありません。

このリリース連動型のアプローチが重要なのは、測定を変化に直接結びつけているからです。もしベンチマークが夜間のスケジュールでのみ実行されるものであれば、日中のホットフィックスを見逃したり、デグレ（退行）を数時間も放置したりする可能性があります。新しいバージョンに合わせて実行することで、canaryは毎回直接的な問いを投げかけます。「このリリースによって、状況は良くなったのか、それとも悪くなったのか？」と。

異なる側面をテストする4つのシナリオ

テストマトリックスは、皆さんがよく知るワークフローに直接対応する、4つの異なるセットアップで構成されています。

  • キャッシュなし、ロックファイルなし (Cold cache, no lockfile): これは、新しいノートPCでのクローン直後や、node_modulesを削除した後の最初のインストールです。何もキャッシュされておらず、何も固定されていません。パッケージマネージャーは、すべてをゼロから解決、取得、書き込みする必要があります。
  • キャッシュあり、ロックファイルあり (Warm cache, with lockfile): これは、物事がうまく進んでいる時の継続的インテグレーション（CI）における理想的なパスです。ローカルにロックファイルが存在し、キャッシュには前回の実行時のtarballが残っています。ほとんどの決定がすでになされているため、ツールは高速に動作するはずです。
  • キャッシュなし、ロックファイルあり (Cold cache, with lockfile): ここではロックファイルは存在しますが、キャッシュは消去されています。マネージャーは依存関係の解決をスキップできますが、ネットワーク経由ですべてのバイトをダウンロードする必要があります。これにより、ネットワーク速度を解決速度から分離して測定できます。
  • キャッシュあり、ロックファイルなし (Warm cache, no lockfile): キャッシュはありますが、ロックファイルがありません。パッケージマネージャーは、ファイルの展開を開始する前に、依存関係ツリーを再解決しなければなりません。これは、理想的なネットワーク条件下でのソルバーとメタデータパーサーの効率をテストします。

各シナリオは5回実行され、canaryは中央値（median）を保持します。この一つの選択が、多くのノイズを排除します。一時的なネットワークの瞬断や、レジストリのレイテンシのわずかなスパイクが、結果を支配することはありません。外れ値は無視され、典型的な体験が記録されます。

スモークテストは空虚なタイマーに勝る

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