Двойной релиз pnpm: изоляция CI-токенов в 11.28.6 и тонкий кэш нативных пакетов в 12.14.0

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

Буквально недавно мы разбирали, как Релизы pnpm 12.10.0 и 11.28.5: экспериментальный loaded-линкер, фиксация настроек в lockfile и патчи безопасности укрепляли защиту сборок. В середине октября команда проекта под руководством Золтана Кохана (Zoltan Kochan) синхронно выпустила еще два важных обновления: сервисный релиз 11.28.6 для LTS-ветки и функциональный 12.14.0 для текущей ветки. Давай посмотрим, какие критические проблемы они закрывают.

Утечка OIDC-токенов в CI/CD: как исправили авторизацию

Главное исправление безопасности в ветке 11.28.6 касается команды публикации pnpm publish. Современные облачные пайплайны (GitHub Actions, GitLab CI) активно используют OIDC-аутентификацию для беспарольной публикации пакетов через короткоживущие токены NPM_ID_TOKEN.

В токене всегда зашита целевая аудитория — поле aud, строго указывающее, для какого именно реестра выдан сертификат (например, npm:registry.npmjs.org). Однако в предыдущих версиях pnpm при наличии в проекте нескольких настроенных приватных реестров или зеркал токен мог ошибочно отправляться в сторонний эндпоинт, где аудитория не совпадала. Это создавало риск перехвата токена сторонним прокси-сервером.

В версии 11.28.6 поведение исправили: теперь pnpm строго верифицирует соответствие aud целевому URL. Если аудитория не совпадает, токен пропускается с предупреждением в логах сборки, а клиент переключается на стандартные настроенные статические токены авторизации.

Черный список для кэша побочных эффектов: sideEffectsCache.exclude

Если ты разрабатываешь бэкенд на Node.js со сложными нативными зависимостями (криптография bcrypt, рендеринг канваса canvas или обработка графики sharp), ты наверняка сталкивался со странным поведением кэша. Функция sideEffectsCache в pnpm запоминает скомпилированные бинарные файлы пакетов после шага node-gyp build, чтобы при следующей установке не тратить время на повторную компиляцию C++.

Но если кэш расшарен между разными машинами через remoteCache или виртуальные машины в CI имеют разные версии системной библиотеки glibc или musl, подтянутый из кэша бинарник падает в рантайме с паникой Symbol not found или Segmentation fault.

В pnpm 12.14.0 появилась новая настройка sideEffectsCache.exclude, которую можно задать в .npmrc или pnpm-workspace.yaml:

# pnpm-workspace.yaml
sideEffectsCache:
  # Исключаем нативные аддоны из общего кэша сборки
  exclude:
    - 'bcrypt'
    - '@tensorflow/tfjs-node'
    - 'canvas@*'

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

Разрешение зависимостей и чистый терминал

Еще одно приятное исправление коснулось давнего бага разрешения зависимостей (issue #16901). Если пакет одновременно объявлялся в dependencies и дублировался в peerDependencies с флагом опциональности:

{
  "name": "my-shared-toolkit",
  "dependencies": {
    "ajv": "^8.12.0"
  },
  "peerDependencies": {
    "ajv": "^8.0.0"
  },
  "peerDependenciesMeta": {
    "ajv": {
      "optional": true
    }
  }
}

Раньше алгоритм резолвера pnpm мог полностью «потерять» зависимость при построении графа виртуального дерева. Теперь эта коллизия устранена. Кроме того, команды pnpm install и pnpm add больше не висят в терминале, ожидая фоновой проверки доступности обновлений сети, если установка уже успешно завершилась.

pnpm add -g pnpm@12.14.0