Пакетный менеджер pnpm давно заслужил репутацию самого бережного к диску и быстрого инструмента в экосистеме Node.js благодаря жестким ссылкам и глобальному хранилищу пакетов. Однако по мере роста функциональности проект столкнулся с вызовами зрелости: раздуванием веса основных пакетов и шероховатостями при сборке изолированных контейнеров. Синхронные релизы веток 12.9.1 и 11.28.4 решают обе проблемы: мажорная ветка сбросила лишние десятки мегабайтов благодаря модульной изоляции WebAssembly, а версия с долгосрочной поддержкой закрыла неприятные утечки токенов и стабилизировала работу в многоэтапных сборках Docker.
Диета для дистрибутива: почему WebAssembly вынесли в отдельный пакет
Главным архитектурным событием ветки 12.9.1 стало радикальное сокращение объема основного пакета pnpm: в распакованном виде он похудел с 55 МБ до скромных 4 МБ, а автономный бинарный файл для платформы macOS на процессорах Apple Silicon сократился с 45,1 МБ до 40,3 МБ.
Причиной прежнего внушительного веса была поддержка технологии WebContainers от платформы StackBlitz, позволяющей выполнять рантайм Node.js и инструменты сборки прямо в браузере. Ранее скомпилированные байткод-модули WebAssembly поставлялись непосредственно внутри базового дистрибутива pnpm. В итоге миллионы инженеров скачивали тяжелые бинарники ради функциональности, необходимой лишь небольшому числу браузерных песочниц. Начиная с версии 12.9.1 браузерная сборка вынесена в независимый пакет @pnpm/wasm. Разработчикам, запускающим менеджер внутри WebContainers, теперь достаточно выполнить разовую установку этого модуля, тогда как обычные пользователи и серверы автоматизации получают мгновенную установку без лишних мегабайтов.
Закрытие утечек: безопасная авторизация и чистые логи сборки
Ветка pnpm 11.28.4 сосредоточена на информационной безопасности и защите корпоративных секретов. Разработчики устранили уязвимость в процедуре авторизации: при выполнении команды входа в приватный реестр менеджер раньше мог случайно отправить секретный токен стороннему серверу, если реестр возвращал HTTP-редирект на другой адрес. Теперь учетные данные надежно изолированы и пересылаются исключительно целевому хосту.
Второе важное исправление касается журналов ошибок. При несовпадении контрольных сумм скачиваемого архива pnpm выводил в консоль подробное сообщение, которое в некоторых конфигурациях содержало заголовки авторизации, токены доступа и конфиденциальные параметры строки запроса. Если сборка падала в публичном CI-пайплайне, эти токены рисковали попасть в открытый доступ. В свежих патчах форматирование ошибок очищено от любых приватных данных.
Стабилизация Docker-образов и строгого режима frozen-lockfile
Вторая волна улучшений касается сборки контейнеров и работы монорепозиториев. Режим строгой фиксации версий --frozen-lockfile требует, чтобы зависимости на сервере точно совпадали с зафиксированными в манифесте, предотвращая несанкционированные обновления. Однако при создании компактных Docker-образов разработчики часто используют многоэтапные сборки, копируя в контейнер только бэкенд и намеренно исключая директорию фронтенда.
Раньше pnpm, обнаружив в файле блокировки описание отсутствующего проекта, немедленно прерывал сборку с критической ошибкой. Инженерам приходилось создавать фиктивные пустые папки, чтобы обойти проверку. Обновления 12.9.1 и 11.28.4 научили резолвер корректно пропускать отсутствующие в текущем контексте директории монорепозитория, сохраняя строгий контроль версий для всех присутствующих компонентов. Заодно разработчики устранили ложную ошибку устаревшего файла блокировки в проектах с внутренними ссылками workspace: и стабилизировали обработку каталогов версий.
Адаптивная сеть и правила обновления рабочих веток
Помимо оптимизации файловой системы, pnpm переработал сетевое поведение. При проверке свежести метаданных пакетов клиент теперь отправляет условные HTTP-запросы с заголовком ETag. Если реестр подтверждает статус 304 Not Modified, трафик не расходуется повторно даже при строгой политике запрета кэширования. При возникновении сетевых задержек у конкретного хоста клиент автоматически снижает число параллельных потоков скачивания до одного, предотвращая лавинообразный сбой соединений.
Команда также устранила конфликты окружения: команда встроенного обновления определяет установку через менеджер Homebrew на macOS и вместо создания теневой копии советует воспользоваться системным пакетным менеджером. Пользователям обеих веток рекомендуется обновиться: ветка 11 гарантирует безопасность закрытых репозиториев, а ветка 12 возвращает pnpm былую легкость без ущерба для скорости.