Сервис развивается: тестируем формат, собираем идеи, улучшаем сервис. Есть идеи? Написать
Дайджесты новостей
Защитный барьер пакетного менеджера с белым списком доверенных сборок и автоматическим определением среды выполнения.

Релизы pnpm 12.7 и 11.28: автоматический shim Node.js и контроль безопасности сборок

Менеджер пакетов pnpm получил синхронное обновление: вышла стабильная версия 12.7 и релиз ветки с долгосрочной поддержкой (LTS) 11.28. Мейнтейнер проекта Золтан Кочан сосредоточил внимание на защите от атак на цепочку поставок (supply chain attacks), оптимизации работы в монорепозиториях и упрощении управления версиями среды выполнения Node.js.

Одной из самых уязвимых зон экосистемы npm исторически остаются скрипты жизненного цикла пакетов (postinstall, preinstall). Вредоносные модули нередко используют эти хуки для скрытного скачивания внешних бинарников или кражи переменных окружения. Новые версии pnpm предоставляют декларативные механизмы изоляции, позволяя инженерам полностью контролировать выполнение сборочных команд.

Автоматический shim Node.js и приоритеты версий

В pnpm 12.7 существенно переработан глобальный шим (shim) рантайма node. Если проект не объявляет требуемую версию явно в полях devEngines.runtime или engines.runtime, шим начинает автоматически сканировать структуру каталогов в поисках конфигурационных файлов окружения.

Порядок разрешения версии Node.js теперь строго регламентирован:

  1. Секция devEngines.runtime в корневом манифесте package.json.
  2. Файл .node-version.
  3. Файл .nvmrc.

Благодаря этому разработчикам в большинстве проектов больше не требуется вручную выполнять команды вроде nvm use или держать в системе отдельные утилиты управления версиями (fnm или n): pnpm самостоятельно активирует нужный рантайм.

Декларативный контроль сборки: директива allowBuilds

Для предотвращения несанкционированного исполнения нативного кода pnpm внедрил флаг --allow-build и соответствующее поле манифеста pnpm.allowBuilds. Теперь команда сборки может формировать строгий белый список пакетов, которым разрешено компилировать бинарники:

{
  "name": "enterprise-monorepo",
  "version": "1.0.0",
  "private": true,
  "devEngines": {
    "runtime": {
      "name": "node",
      "version": "^22.0.0"
    },
    "packageManager": {
      "name": "pnpm",
      "version": "^12.7.0"
    }
  },
  "pnpm": {
    "allowBuilds": [
      "esbuild",
      "sharp"
    ]
  }
}

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

Изоляция платформенных зависимостей и командная строка

Еще одно важное изменение коснулось поведения при форсированной установке pnpm install --force. Ранее команда скачивала все опциональные зависимости, включая скомпилированные бинарники для других операционных систем, архитектур процессоров или сторонних версий стандартных библиотек C (glibc и musl).

В версии 12.7 по умолчанию активирована фильтрация чужих платформ, а в LTS 11.28 для этого добавлена опция forceIgnoresPlatform.

# Установка зависимостей с явным разрешением сборки доверенных пакетов
pnpm install --allow-build=esbuild --allow-build=sharp

# Обновление библиотек с синхронизацией версий в peerDependencies
pnpm update --peer react

# Запуск сборки с принудительной изоляцией платформенных бинарников
pnpm install --force --config.forceIgnoresPlatform=true

Ключ pnpm update --peer решает застарелую проблему несоответствия версий: он автоматически обновляет диапазоны в секции peerDependencies, которые стандартная процедура обновления оставляла неизменными, предотвращая конфликты зависимостей при релизах библиотек.

Особенности миграции с ветки 11.x

В pnpm 12.7 изменение поведения pnpm install --force по отношению к чужим платформам включено по умолчанию. Если легаси-скрипты развертывания рассчитывали на загрузку всех платформенных пакетов в одном окружении (например, для сборки кросс-платформенных архивов), потребуется явно передать флаг forceIgnoresPlatform: false.

Кроме того, в релизах закрыта утечка переменных среды через директиву userAgent в файле pnpm-workspace.yaml и добавлен параметр --publish-wait-timeout, задающий время ожидания доступности опубликованного пакета в реестре npm перед началом сборки зависящих модулей.

Синхронный апдейт pnpm закрепляет за инструментом репутацию наиболее защищенного и строгого пакетного менеджера в современной экосистеме JavaScript.