pnpm 12.13.0: профили реестра, токены и защита общего хранилища на NFS

Если ты настраивал пайплайны CI/CD для крупного монорепозитория, то наверняка знаешь проверенный лайфхак: смонтировать единое сетевое хранилище (Shared Store) на сетевой диск NFS или SMB, чтобы десяток воркеров сборки переиспользовали уже скачанные пакеты. Зачем гонять терабайты сетевого трафика и дублировать зависимости, если контентно-адресуемое хранилище pnpm создано для экономии места? Совсем недавно мы обсуждали ускорение сборки через удаленный кэш Turborepo в pnpm, но у разделяемого хранилища на сетевых дисках годами оставалась одна крайне неприятная уязвимость.

Речь идет о блокировках SQLite. По умолчанию pnpm хранит индекс метаданных пакетов в монолитном файле index.db. На локальном SSD архитектура SQLite работает безупречно — мы подробно разбирали ее преимущества в статье про архитектуру SQLite. Однако сетевые файловые системы (NFS, SMB, AWS EFS) имеют печальную репутацию плохой поддержки POSIX-блокировок при параллельном доступе. Когда несколько раннеров одновременно запускали pnpm install, база блокировалась, повреждалась и пайплайны падали с фатальной ошибкой database disk image is malformed.

Свежий минорный релиз pnpm 12.13.0 под руководством Золтана Кочана (Zoltan Kochan) наконец-то закрывает эту застарелую инфраструктурную боль.

Параметр storeIndexFormat: files — спасение для NFS

Главное архитектурное новшество релиза — директива storeIndexFormat: files. При ее включении pnpm полностью отказывается от монолитной базы index.db. Вместо нее индекс метаданных раскладывается на отдельные изолированные файлы — ровно по одному файлу на каждый установленный пакет.

Нет общей базы — нет проблемы с конкурирующими блокировками на сетевой шаре. Теперь параллельные сборки в Kubernetes или раннерах GitLab могут безопасно писать в общий стор без риска коррупции данных.

Настройка задается в конфигурационном файле .npmrc или через pnpm-workspace.yaml:

# .npmrc — Безопасный формат хранения индекса на сетевых дисках NFS/SMB
store-index-format=files

# Оптимизация сетевых хранилищ без задержки перед скачиванием
enable-modules-dir=false

А вот как выглядит пример обновленной конфигурации карты пакетов в монорепозитории:

# pnpm-workspace.yaml — Настройка генерации карты пакетов
packages:
  - 'packages/*'
  - 'apps/*'

nodePackageMap:
  mode: write-only
  type: loose

Режим mode: write-only аккуратно генерирует карту node_modules/.package-map.json для внешних анализаторов кода и линтеров, не заставляя сам рантайм Node.js принудительно переключаться на экспериментальный режим загрузки.

Управление токенами и профилем прямо из консоли

Вторым заметным новшеством стала интеграция команд администрирования реестра. Разработчикам больше не нужно вручную переходить в веб-интерфейс npmjs.com или открывать конфигурационный файл .npmrc для манипуляций с секретами.

В pnpm 12.13.0 появились нативные интерфейсы pnpm profile и pnpm token:

# Просмотр информации текущего профиля на npm-реестре
pnpm profile get

# Создание гранулярного токена только для чтения с ограничением по CIDR
pnpm token create --read-only --cidr=192.168.1.0/24

# Аудит и отзыв скомпрометированного токена доступа
pnpm token list
pnpm token revoke 01234567-89ab-cdef-0123-456789abcdef

Ускорение Python и прогретый кэш

Релиз также принес 10-кратное ускорение резолвинга Python-зависимостей при сборке нативных модулей. Благодаря реализации стандарта PEP 658 менеджер пакетов скачивает только легковесные метаданные пакетов без вытягивания тяжелых бинарных wheel-архивов: время разрешения десяти зависимостей сократилось с 40 до 4 секунд.

Кроме того, при повторных запусках инсталляции с актуальным pnpm-lock.yaml менеджер больше не шлет пустые проверочные запросы метаданных в сеть для пакетов, которые уже присутствуют в прогретом локальном хранилище.

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