pnpm vs npm vs Bun для больших репозиториев: что замечают команды

Почему этот выбор превращается в ежедневное неудобство

Package manager редко создает проблемы в первый день. Боль обычно приходит через несколько недель, когда пять человек тянут разные ветки, CI работает весь день, а одно небольшое изменение в зависимости снова делает установку медленной. Вот тогда pnpm vs npm vs Bun перестает быть спором о инструментах и превращается в ежедневную проблему для команды.

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

Команды обычно сталкиваются с одними и теми же проблемами: установки, которые на одном ноутбуке выглядят нормально, но тормозят в CI; дублированные файлы, которые незаметно съедают место на SSD; команды для workspace, которые работают в одном приложении и ломаются в другом; и изменения lockfile, из-за которых pull request становится шумным.

Таблицы с бенчмарками почти не показывают ничего из этого. Они говорят только, кто победил в чистой установке на одной машине. Реальная работа устроена сложнее. Люди переключают ветки, добавляют один пакет, снова запускают тесты, пересобирают приложения и пытаются сохранить стабильность репозитория, пока сразу несколько проектов меняются одновременно.

Для большинства команд сравнение сводится к трем вещам. Первая — расход диска: сколько места занимают репозиторий и кэш после нескольких недель обычной работы. Вторая — скорость установки, включая повторные установки, переключение веток и задачи CI, а не только самый первый запуск. Третья — поведение workspace: насколько предсказуемо работают скрипты, разрешение зависимостей и границы между пакетами, когда один и тот же репозиторий трогают многие люди.

Если вы руководите командой, этот выбор быстро проявится в обращениях за помощью. Кто-то спросит, почему локальная настройка занимает полчаса. Кто-то другой — почему внезапно перестал работать общий скрипт пакета. Хороший package manager не делает репозиторий интересным. Он делает его скучным, а именно это и нужно занятым командам.

Что меняется, когда репозиторий становится большим

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

Сценарий знакомый. Команда добавляет веб-приложение, потом админ-панель, потом мобильный клиент, потом общую UI-библиотеку, потом общий API-пакет. После этого установки происходят постоянно, потому что кто-то все время тянет ветку, переключает задачу, обновляет lockfile или добавляет еще одну зависимость.

На этом этапе у репозитория обычно появляются одни и те же признаки. Десятки или даже сотни пакетов живут в одном workspace. Общий код находится в центре нескольких приложений. Свежие установки происходят каждый день, а не раз в неделю. Одно изменение lockfile затрагивает людей, которые эту фичу даже не трогали. Новые сотрудники слишком долго запускают проект.

Последний пункт важнее, чем кажется. Если локальная настройка занимает 40 минут вместо 8, цена быстро растет. Пять разработчиков, которые снова и снова проходят через переключение веток, сломанные установки и сбросы машины, могут потерять часы в неделю и даже не заметить этого. Package manager перестает быть фоновым инструментом и становится частью ежедневного настроения команды.

CI ощущает это по-своему. Ему важны чистые и повторяемые установки, попадание в кэш и возможность пересобрать репозиторий без сюрпризов. Локальные ноутбуки разработчиков чувствуют другое: медленный холодный старт, давление на диск, расход батареи и странные крайние случаи после месяцев накопления пакетов.

Это различие часто застает команды врасплох. Настройка может выглядеть нормально в CI, но раздражать каждого инженера локально. Или наоборот — казаться быстрой на хорошо настроенной машине опытного разработчика и тормозить на более новом ноутбуке с почти заполненным диском.

Когда репозиторий вырастает, pnpm vs npm vs Bun становится настоящим командным вопросом. Управление пакетами влияет на скорость онбординга, переключение веток, обновление зависимостей и на то, как часто люди ворчат на терминал перед обедом.

Как расход диска отличается в реальных проектах

Когда команды сравнивают pnpm vs npm vs Bun, расход диска часто становится первым сюрпризом. В большом репозитории место исчезает не потому, что один пакет очень тяжелый. Оно исчезает потому, что одни и те же пакеты снова и снова устанавливаются в приложениях, инструментах, ветках и старых клонах.

npm обычно со временем занимает больше всего места. Он держит полное дерево node_modules в каждом проекте, и даже с дедупликацией многие файлы все равно повторяются. Если в вашем репозитории есть веб-приложение, API, общий UI-пакет, тестовые инструменты и документация, одни и те же TypeScript, ESLint, React и тестовые пакеты могут лежать сразу в нескольких местах.

pnpm работает иначе. Он хранит пакеты в общем store на диске, а затем связывает их с каждым проектом. Одна копия пакета может обслуживать много workspace. В монорепозитории с большим количеством пересечений это быстро убирает лишние затраты места. Чем больше становится репозиторий, тем легче увидеть разницу.

Bun тоже использует глобальный кэш и старается переиспользовать то, что уже лежит на диске. Во многих проектах это делает его экономнее npm. Но в больших workspace-структурах команды обычно видят более предсказуемую экономию места именно у pnpm, потому что общий store встроен в саму модель работы.

У npm тоже есть кэш, но он в основном помогает с загрузками. Он не делает установленную структуру намного компактнее. node_modules все равно может разрастись до небольшого леса.

На реальных ноутбуках картина обычно довольно стабильная. npm быстрее заполняет SSD, особенно если разработчики хранят несколько клонов одного и того же репозитория. pnpm лучше контролирует повторяющиеся пакеты в workspace и проектах. Bun часто оказывается где-то посередине, а иногда приближается к pnpm.

Это важнее, чем кажется по бенчмаркам. Многие разработчики работают на SSD объемом 256 или 512 ГБ, а файлы пакетов конкурируют с Docker-образами, локальными базами данных, мобильными SDK и кэшами браузера. Сэкономить даже 10 или 15 ГБ на активных репозиториях — это очень заметно, когда машина начинает предупреждать о нехватке места.

Команды замечают и боль от очистки. С npm удаление node_modules может вернуть много места, но оно быстро снова возвращается. С pnpm и Bun общий storage означает, что лишнего дублирования изначально меньше. А значит, меньше уборки и меньше моментов, когда ноутбук начинает тормозить из-за папок с зависимостями.

Как ощущается скорость установки в обычной работе

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

В большом репозитории выбор package manager проявляется в трех моментах. Первая установка — самая медленная и дорогая. Повторные установки — то, с чем люди сталкиваются почти каждый день. Чистая установка находится посередине: вы уже знаете репозиторий, но удаляете node_modules и начинаете сначала, потому что что-то разъехалось.

Для первой установки на новом ноутбуке или чистом CI-runner скорость сети часто задает темп. Если офисный Wi‑Fi нестабилен, VPN добавляет задержку или proxy для registry медленный, самый быстрый инструмент на бумаге может ощущаться не намного быстрее. Bun часто выглядит здесь очень шустро, особенно когда может быстро скачать и связать пакеты. npm заметно улучшился, но в очень больших репозиториях он по-прежнему обычно ощущается тяжелее. pnpm тоже часто силен, хотя его главный плюс чаще заметен уже после первой установки.

Гораздо важнее для ежедневной работы результаты на теплом кэше. Когда пакеты уже есть на машине, pnpm часто ощущается особенно быстро, потому что хорошо переиспользует содержимое вместо того, чтобы снова и снова копировать те же файлы. Это экономит время, когда разработчики переключают ветки или обновляют один пакет в workspace. Bun тоже может быть быстрым, но команде стоит проверить его на собственных скриптах и postinstall-шагах. npm обычно вполне нормален для небольших проектов, но в больших монорепозиториях повторные установки все равно могут тянуться.

Больше всего люди замечают простые моменты: первое клонирование на новой машине, переключение ветки после изменения lockfile, повторную установку после удаления node_modules, задачу CI на чистом runner и patch-релиз, где поменялось только несколько пакетов.

Согласованность lockfile меняет картину сильнее, чем многие ожидают. Если все используют один и тот же инструмент и держат один lockfile стабильным, установки остаются предсказуемыми. Если разработчики смешивают инструменты, постоянно трогают lockfile или запускают полную повторную резолюцию, любое преимущество по скорости быстро исчезает.

Поэтому pnpm vs npm vs Bun — это не столько про один бенчмарк, сколько про то, как часто ваша команда ждет в обычную рабочую неделю.

Как ведут себя workspace, когда репозиторий трогают многие люди

В маленьком репозитории workspace кажутся аккуратными. В большом репозитории с веб-приложением, админкой и общими пакетами они формируют привычки на каждый день. Package manager решает, насколько просто добавить одну зависимость, запустить один скрипт и не сломать чужую часть дерева.

npm, pnpm и Bun все поддерживают многопакетные репозитории, но ощущаются по-разному. npm использует workspaces в корневом package.json, и это упрощает настройку. pnpm обычно добавляет pnpm-workspace.yaml, и этот дополнительный файл делает структуру workspace более явной. Bun тоже читает workspaces из корня и внешне похож на npm, но некоторые команды все же считают его скрипты и совместимость с инструментами менее предсказуемыми.

Первое место, где появляется трение, — это добавление пакета в одно приложение, а не во весь репозиторий. Новые участники команды часто запускают установку из корня и случайно меняют не тот package.json. npm поддерживает установку в конкретный workspace, но людям нужно рано освоить этот флаг. pnpm дает такой же контроль, и многим командам нравится его модель фильтрации, когда они к ней привыкают. Bun тоже умеет работать с одним workspace, но команды часто в итоге запускают команды из папки пакета, потому что так спокойнее.

Следующий тест — запуск скриптов сразу во многих пакетах. Именно здесь ежедневная работа либо остается спокойной, либо превращается в шум. npm умеет запускать скрипты в workspaces, но команды могут казаться неуклюжими, когда нужен тонкий контроль. pnpm обычно удобнее всего в больших репозиториях, потому что его фильтрация понятная и быстрая для сценариев вроде «запусти это в app A и в общем package B». Bun быстрый, и это приятно, но команде стоит проверить, как его существующие скрипты, shell-обвязка и build-инструменты ведут себя до того, как доверять ему весь репозиторий.

Самый большой сюрприз для новичков часто связан с видимостью зависимостей. pnpm строже, поэтому он раньше показывает пропущенные или не объявленные зависимости. Это может раздражать день или два, зато потом экономит время, потому что пакеты перестают полагаться на вещи, которые никогда не были объявлены. Hoisting в npm может скрывать такую проблему дольше. Сюрпризы Bun чаще связаны с отличиями в командах и меньшими пробелами в совместимости с инструментами.

Для занятых команд это важнее, чем таблица с бенчмарками. Если десять человек трогают репозиторий каждую неделю, лучшая настройка workspace — та, где правильное действие очевидно, а неправильное сделать сложно.

Как протестировать все три варианта в своем репозитории

Честный тест package manager должен быть скучным — и это хорошо. Используйте одну ветку, зафиксируйте версию Node и заморозьте версии зависимостей до начала. Если кто-то обновит пакеты посреди теста, цифры быстро потеряют смысл.

Оставьте код приложения одинаковым для всех прогонов. Меняйте только package manager и его lockfile. После каждого теста возвращайте репозиторий к одному и тому же чистому коммиту, чтобы pnpm, npm и Bun стартовали с одинаковой точки.

Для простого сравнения обычно нужны пять прогонов для каждого инструмента:

1. Свежая установка на чистом checkout.
2. Повторная установка, когда кэши уже прогреты.
3. Добавление одного нового пакета в workspace, который команда использует часто.
4. Запуск workspace-команд, которые люди используют каждый день.
5. Та же установка в CI.

Измеряйте каждый шаг секундомером или через timing в shell, но не останавливайтесь только на времени. Измеряйте и расход диска. Проверьте размер node_modules внутри репозитория, а потом размер кэша или store package manager после прогона. Это важно в больших репозиториях, потому что pnpm часто экономит место за счет общего store, тогда как npm и Bun могут вести себя по-разному в зависимости от того, сколько они кэшируют вне проекта.

Поведение workspace нужно тестировать отдельно, потому что одна только скорость не показывает всей картины. Используйте те команды, которые ваша команда уже запускает: установка из корня репозитория, добавление зависимости в один пакет, тесты для одного workspace и фильтрованную сборку. Если разработчики работают в монорепозитории с множеством пакетов, небольшие различия в командах каждый день отнимают время.

Используйте две машины разработчика, а не одну. Быстрый ноутбук с теплым SSD может скрыть проблемы, которые видны на более старой машине. Потом повторите те же шаги в CI, где холодные кэши и новые контейнеры часто меняют результат.

Запишите результаты в небольшую таблицу. Отслеживайте время свежей установки, время повторной установки, время добавления одного пакета, размер node_modules в репозитории, размер глобального cache, а также любую команду, которая показалась неудобной или упала.

Последний столбец важнее, чем многие признают. В реальной команде лучший результат — не тот package manager, который выиграл один бенчмарк. Лучший — тот, который остается предсказуемым на ноутбуках, в CI и в workspace-командах, которые люди запускают каждую неделю.

Простой командный сценарий

Представьте команду из восьми человек, которая работает в одном репозитории. У них веб-приложение в apps/web, API в apps/api и несколько общих пакетов для UI, типов и auth-хелперов. Никто не спорит о package manager в первый день. Спор начинается, когда новый сотрудник открывает репозиторий на свежем ноутбуке и ждет, пока все установится.

С npm онбординг выглядит знакомо. Большинство разработчиков уже знают команды, поэтому никто не останавливается на базовых вопросах настройки. Но минус становится заметен быстро: установка на чистой машине обычно самая долгая, а локальный объем node_modules растет быстро, когда в репозитории несколько приложений и общих пакетов.

pnpm часто производит лучшее первое впечатление по расходу диска. Новый разработчик клонирует репозиторий, один раз запускает установку, и общий store убирает много дублирующихся файлов. В большом сравнении package manager для репозитория это важнее, чем кажется, потому что каждое переключение ветки, чистая установка и восстановление CI-кэша повторяют одну и ту же цену.

Bun часто выигрывает гонку по сырой скорости холодной установки. Новый сотрудник может поднять web-приложение и API быстрее, и это приятно в понедельник утром. Но проблема в том, что большие команды живут не только на скорости установки. Если один скрипт workspace, postinstall-шаг или старый пакет ведет себя странно, время, сэкономленное на установке, может вернуться временем на отладку.

Обычная неделя делает различия еще заметнее. Два разработчика обновляют frontend-пакеты, один человек меняет зависимость API, а CI запускается на каждый pull request. Lockfile меняется почти каждый день.

pnpm обычно экономит время на протяжении всей недели, потому что аккуратно работает с workspace и держит расход диска под контролем. Он также может показать пропущенные объявления зависимостей, которые npm может пропустить. Эта строгость полезна, но может сбить с толку команды, которые месяцами полагались на случайный hoisting.

npm поначалу вызывает меньше всего вопросов, потому что его все знают. Но в занятом монорепозитории это спокойствие быстро исчезает, когда установки остаются медленными, а CI-кэши разрастаются.

Bun — это темная лошадка в pnpm vs npm vs Bun. Он ощущается быстрым, и некоторым командам это очень нравится. Для большого репозитория с множеством участников я бы выбрал его только после нескольких недель реальных прогонов CI, churn lockfile и переключения веток. Инструмент, который экономит 40 секунд на установке, но добавляет одну странную проблему workspace каждые несколько дней, на самом деле не экономит время.

Ошибки, которые искажают сравнение

Честный тест pnpm vs npm vs Bun сложнее, чем кажется. Команды часто пробуют каждый package manager по десять минут, смотрят на время установки и считают, что этого достаточно. Обычно это измеряет настройку теста, а не package manager.

Самая частая ошибка — несоответствие кэшей. Если один прогон использует теплый локальный кэш, а другой стартует с нуля, результат говорит больше об истории вашего ноутбука, чем о реальной скорости установки. Запускайте каждый package manager больше одного раза и четко подписывайте прогоны. Холодная установка, теплая установка и повторная установка — это разные ситуации.

Переключение веток тоже может исказить картину. В занятом репозитории разработчики прыгают между ветками весь день. Если lockfile меняется и один package manager аккуратно проходит этот переход, а другой оставляет старые модули, люди быстро почувствуют эту боль. Package manager, который выглядит быстрым на чистом клоне, может ощущаться грязным уже через неделю реальной работы с ветками.

Поведение workspace легко неправильно понять, если тестовый репозиторий слишком маленький. Небольшой демо-пример с тремя пакетами не показывает, что происходит, когда вместе двигаются десятки приложений и общих библиотек. Hoisting, linking, запуск скриптов и границы между зависимостями начинают иметь значение, когда один и тот же репозиторий трогают многие люди. Именно тогда мелкие странности превращаются в обращения в поддержку.

Скопированные бенчмарки — еще одна ловушка. Утверждение из чужого проекта может относиться к другой операционной системе, другой сети, другому CI-кэшу, другому графу зависимостей или другой форме workspace. Если в вашем репозитории есть нативные модули, приватные пакеты или много внутренних библиотек, внешние цифры могут ввести в заблуждение.

Еще одна ошибка — менять инструмент до проверки остального workflow. Плагины редактора, CI-runner, Docker-сборки, настройка кэша и скрипты деплоя тоже влияют на ежедневное использование.

Простой чек-лист помогает: протестируйте все три варианта с холодной и теплой установкой, переключайте ветки с реальными изменениями lockfile, прогоняйте весь workspace вместо игрушечного репозитория и сначала проверьте поддержку редактора, CI и контейнеров.

Это занимает больше времени, чем быстрый бенчмарк, но дает результаты, которым команда сможет доверять.

Короткие проверки перед выбором

Команды часто сравнивают package manager, читая таблицы с бенчмарками, а потом пропускают привычки, из-за которых возникает большая часть боли. Более быстрая установка на бумаге мало поможет, если ваша команда редко ставит все с нуля, работает на маленьких SSD или зависит от workspace-команд, которые каждый день ведут себя по-разному.

Перед выбором между pnpm vs npm vs Bun задайте несколько прямых вопросов и ответьте на них реальными цифрами из своего репозитория.

1. Как часто люди делают чистую установку? Если разработчики удаляют node_modules раз в месяц, скорость установки важна меньше, чем стабильность. Если они пересобирают проект часто, потому что переключают ветки, тестируют много приложений или подключают подрядчиков, скорость становится намного важнее.
2. Сколько свободного места на диске у людей на самом деле? Опытный инженер с большим десктопным диском и дизайнер на почти заполненном ноутбуке ощущают стоимость настройки совсем по-разному. Проверьте машины, которыми команда реально пользуется.
3. Какие workspace-команды появляются каждую неделю? Посмотрите на команды для фильтрации, bootstrap, тестов одного приложения или сборки одного пакета. Инструмент, который удобен в работе с одним пакетом, может быстро начать раздражать в занятом монорепозитории.
4. Используют ли CI-runner и локальные машины одну и ту же версию инструмента? Если локально ставится одна версия, а в CI — другая, команда теряет часы на churn lockfile и странные ошибки. Зафиксируйте версию и держите ее одинаковой везде.
5. Сколько поведения команда готова переучивать? Одни команды быстро адаптируются. Другие теряют темп, когда меняются флаги команд, правила lockfile или настройки workspace по умолчанию. Эта цена реальна, даже если никто не пишет ее в оценочную таблицу.

Простой пример помогает. Если в вашем репозитории 40 пакетов, два CI-окружения и команда, которая весь день переключает ветки, небольшие различия в поведении установки быстро накапливаются. Если в репозитории шесть пакетов и стабильные процессы, самым дешевым выбором может стать тот инструмент, который команда уже знает.

Выбирайте инструмент, который вызывает меньше всего повторяющихся неудобств, а не тот, который выиграл самый красивый демо-прогон.

Что делать дальше

Выберите инструмент, который лучше всего подходит тому, как ваша команда уже работает. Весь хайп быстро исчезает, когда десять человек трогают один и тот же репозиторий, CI работает весь день, а одна сломанная установка тормозит релиз.

Короткий пилот расскажет больше, чем неделя обсуждений. Запустите его на одной активной ветке, с теми же правилами для lockfile, теми же шагами CI и теми же людьми, которые работают как обычно. Так вы поймете, что в вашем репозитории pnpm vs npm vs Bun действительно ощущается лучше, а не в чужом бенчмарке.

Записывайте, что происходит во время теста. Держите все скучным и измеримым:

• время свежей установки на чистой машине
• время повторной установки после прогрева кэша
• расход диска для репозитория и глобального store или cache
• проблемы workspace, например путаница с linking или сломанные скрипты
• поведение CI, особенно попадания в кэш и неудачные установки

Цифры помогают, но командное трение не менее важно. Если разработчики постоянно спрашивают, почему пропал пакет, почему скрипт ведет себя иначе или почему один workspace не видит другой, эта цена реальна, даже если скорость установки на бумаге выглядит отлично.

Полезно также проверить один недавний change, который затрагивает несколько пакетов. Package manager для большого репозитория может выглядеть нормально в простом демо, а потом начать раздражать, когда люди переименовывают пакеты, обновляют общие зависимости или весь день переключают ветки.

Если вам нужен взгляд со стороны перед решением, Oleg Sotnikov на oleg.is делает такую работу в формате Fractional CTO. Он консультирует стартапы и малый или средний бизнес по архитектуре, инфраструктуре и рискам миграции, а именно в это часто и превращается смена package manager.

Через неделю или две картина обычно становится ясной. Оставьте инструмент, который создает меньше всего ежедневных сбоев, зафиксируйте правила его использования и двигайтесь дальше.