Большинство заявлений о производительности в сфере инструментов JavaScript имеют срок годности как у молока. Кто-то устанавливает несколько пакетов тихим вторничным утром, фиксирует вывод терминала и публикует эффектную столбчатую диаграмму. К следующему спринту один из инструментов выпускает патч, который сводит все результаты на нет. Пост при этом остается в индексе поисковиков. Диаграмму продолжают репостить. Однако цифры уже лгут вам.

Это гниль, поражающая почти все бенчмарки менеджеров пакетов. Это событийная фотография там, где нам нужна прямая трансляция.

Проект под названием depjs/canary рассматривает эту проблему как задачу для машины, а не как пункт в контент-плане. Это «живой» бенчмарк, который следит за npm, pnpm, Yarn и dep, а затем перезапускает весь свой набор тестов в тот момент, когда любой из них выпускает новую версию. Результаты публичны, непрерывны и неизбежны. Если что-то ломается, статус репозитория остается красным до тех пор, пока проблема не будет исправлена. Здесь нет места выборочному представлению данных, попыткам спрятаться за старым постом в блоге или предположениям, что победитель прошлого месяца всё еще удерживает корону.

Почему заявления о скорости должны иметь срок годности

Менеджеры пакетов JavaScript не стоят на месте. Разрыв между минорными версиями может включать переписанные алгоритмы разрешения зависимостей, измененные стратегии поднятия (hoisting) или изменения в способе формирования ключей глобального кэша. Бенчмарк, зафиксировавший npm 10.2.1 и pnpm 8.11.0, почти ничего не говорит о том, как эти же инструменты поведут себя через два релиза. Тем не менее, интернет полон категоричных утверждений вроде «Инструмент X в три раза быстрее», основанных именно на таких застывших снимках.

Хуже того, многие тесты игнорируют условия, создающие реальные трудности для разработчиков. Менеджер пакетов может молниеносно выполнить установку в «теплой», хорошо подготовленной среде, а затем еле ползти на CI-раннере с пустым диском. Без тестирования обоих экстремумов бенчмарк превращается в пресс-релиз, а не в полезные инженерные данные.

Как Canary автоматизирует сравнение

Каждые два часа задача опрашивает реестр npm. Если появляется новая версия npm, pnpm, Yarn или dep, «канарейка» просыпается. Она не ждет, пока человек заметит изменения в changelog. Она немедленно запускает полную матрицу тестов, в которой все четыре менеджера соревнуются на примере пяти популярных реальных пакетов. В выборку входят такие тяжеловесы, как React, Next.js и Vite — кодовые базы, которые реальные разработчики устанавливают ежедневно. Это не синтетические микропроекты, созданные для того, чтобы льстить какому-то конкретному инструменту.

Этот подход, запускаемый релизами, важен, потому что он напрямую связывает измерения с изменениями. Если бы бенчмарк запускался только по ночному расписанию, он мог бы пропустить дневной хотфикс или на несколько часов проигнорировать регрессию. Запускаясь именно при выходе новых версий, canary каждый раз задает прямой вопрос: сделал ли этот релиз всё лучше или хуже?

Четыре сценария, нагружающие разные «мышцы»

Матрица тестов построена вокруг четырех различных конфигураций, которые напрямую соответствуют знакомым вам рабочим процессам.

  • Холодный кэш, без lockfile. Это свежий клон на новом ноутбуке или первая установка после удаления node_modules. Ничего не кэшировано. Ничего не зафиксировано. Менеджеру пакетов приходится разрешать зависимости, скачивать и записывать всё с нуля.
  • Теплый кэш, с lockfile. Это идеальный сценарий для непрерывной интеграции (CI), когда всё идет по плану. Lockfile существует локально, а в кэше всё еще хранятся tar-архивы с предыдущего запуска. Инструмент должен работать быстро, так как большинство решений уже принято.
  • Холодный кэш, с lockfile. Здесь lockfile присутствует, но кэш очищен. Менеджер может пропустить этап разрешения зависимостей, но ему всё равно придется скачивать каждый байт по сети. Это позволяет отделить скорость сети от скорости разрешения зависимостей.
  • Теплый кэш, без lockfile. Кэш прогрет, но lockfile отсутствует. Менеджер пакетов должен заново разрешить дерево зависимостей, прежде чем сможет приступить к распаковке файлов. Это проверяет эффективность алгоритма разрешения (solver) и парсера метаданных в идеальных сетевых условиях.

Каждый сценарий выполняется пять раз, и canary сохраняет медианный результат. Этот выбор отсекает массу шума. Один случайный сетевой сбой или кратковременный скачок задержки реестра не смогут исказить общую картину. Выбросы игнорируются; записывается типичный пользовательский опыт.

Дымовые тесты лучше пустых таймеров

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