Що нового в pnpm 12.18

Коротко

Версія pnpm 12.18 додає повноцінну підтримку platform variants для реєстрів із serverType: pnpr, включаючи пакування, публікацію та встановлення специфічних для платформи архівів. Також з'явилася можливість вибірково затверджувати agent skills для окремих залежностей і команда pnpm store add для офлайн-інсталяцій із заздалегідь завантажених tarball-файлів. Крім того, повторні інсталяції та перевірки залежностей перестали перечитувати файли package.json незмінених проєктів у workspace, а також було виправлено низку помилок розділення peer-залежностей.

Нові можливості

Platform variants

Функціональність вимагає реєстру, оголошеного з конфігурацією serverType: pnpr.

• Пакування варіантів: pnpm pack створює по одному архіву на кожен запис у publishConfig.variants у форматі <name>-<version>~<tag>.tgz. Прапорець pnpm pack --variant <target> обмежує збирання лише зазначеною цільовою платформою, а pnpm pack --json виводить integrity та size для кожного створеного архіву.
• Публікація варіантів: pnpm publish публікує архіви з publishConfig.variants, завантажуючи їх перед надсиланням запиту на публікацію версії. Публікація варіантів на інші типи реєстрів блокується, якщо не вказано --no-variants (який публікує лише архів для цілі any).
• Роздільне завантаження архівів: команда pnpm publish --upload-variant <target> завантажує архів у staging-зону реєстру та виводить рядок <target>=<integrity>. Наступний запуск pnpm publish --variant-integrity <target>=<integrity> публікує версію на основі вже завантажених іншими завданнями архівів (з прапорцем --recursive формат змінюється на <name>~<target>=<integrity>).
• Пакетна публікація: pnpm publish -r --batch завантажує кожен архів окремим запитом і пропускає ті, що вже є на реєстрі. Пакети з publishConfig.variants тепер підтримуються в batch-режимі. Якщо пакети посилаються на понад 256 архівів на одному реєстрі, публікація зупиняється з помилкою ERR_PNPM_BATCH_PUBLISH_TOO_MANY_ARCHIVES.
• Provenance: pnpm publish --provenance підписує єдине твердження для всіх архівів версії з publishConfig.variants, де архіви позначаються package URL із кваліфікатором variant.
• Повторний publish тієї самої версії: повторний запуск pnpm publish завершується успішно, якщо опублікована версія ідентична (pnpm порівнює архіви, provenance-твердження та dist-tag). Якщо версія відрізняється, виникає помилка ERR_PNPM_PUBLISHED_RELEASE_DIFFERS.
• Встановлення потрібного варіанта: pnpm обирає та встановлює архів із варіантом, що відповідає поточній платформі, або власний архів пакета, якщо відповідника немає. Якщо версія містить лише варіанти без загального архіву, спроба встановити її на непідтримуваній системі призведе до пропуску опціональної залежності або до помилки зі списком доступних платформ для звичайних залежностей.
• Теги у supportedArchitectures: списки платформ у supportedArchitectures приймають ті самі теги платформ, що й publishConfig.variants, включно з версіями ABI та бібліотек (наприклад, linux-x64-manylinux_2_28, darwin-arm64-macos_14_0, linux-x64-napi8, linux-x64-node127 або будь-які Node.js OS/CPU на кшталт freebsd-x64). За наявності supportedArchitectures pnpm завантажує в сховище варіанти для всіх зазначених систем.

Реєстри pnpr

• Зменшення обсягу метаданих: для реєстрів із serverType: pnpr pnpm не завантажує маніфести рідко використовуваних версій у великих документах пакетів, довантажуючи їх лише за потреби. Дані кешуються у v12/metadata-pnpr. Якщо реєстр є pnpr, але не оголошений як такий, pnpm видає попередження. Параметр minimumReleaseAge понад 30 днів для pnpr викликає помилку ERR_PNPM_UNSUPPORTED_MINIMUM_RELEASE_AGE.
• Release notes під час публікації: pnpm publish надсилає release notes (секцію поточної версії з CHANGELOG.md або нотатки, складені pnpm version -r). Їх можна перевизначити через --release-notes <file> або вимкнути через --no-release-notes. Прапорець --publication-name дає назву релізу в --batch. Нотатки можна переглянути через pnpm view <pkg>@<version> releaseNotes, pnpm outdated --notes та pnpm update --interactive.

Agent skills

• Формат посилань: посилання на навичку агента тепер називається тільки за іменем самої навички (наприклад, .claude/skills/auth замість .claude/skills/pnpm-@acme+kit-auth). Попередні назви замінюються під час наступного встановлення. Перелік додається у блок # pnpm файлу .gitignore відповідної директорії.
• Вирішення колізій: якщо дві навички мають однакове ім'я або назва вже зайнята, використовується формат pnpm-<package>-<skill> замість аварійного завершення команди.
• Вибіркове затвердження: pnpm approve запитує, які саме навички зв'язувати, якщо пакет містить декілька, і записує вибір у конфігурацію виду permissions.<pkg>.skills: [guide, migrate]. Під час першого схвалення також запитуються цільові директорії агентів (зберігаються в skills.dirs).
• Вкладені директорії: підтримуються навички, вкладені в підпапки категорій (наприклад, skills/engineering/implement/SKILL.md) на глибину до трьох рівнів нижче skills/.

Сховище та хуки

• Команда pnpm store add: підготовлює сховище до роботи без мережі за допомогою локальних архівів. Після виконання pnpm store add ./tarballs/*.tgz команда pnpm install --offline --frozen-lockfile встановлює пакети, зафіксовані в lockfile на ці архіви.
• Власні fetcher-хуки: для кастомних pnpmfile стали доступні fetchers.gitHostedTarball, fetchers.git та fetchers.binary.

Виправлення та покращення

• Швидкодія та перевірки: pnpm install, а також pnpm run та pnpm exec з увімкненим verifyDepsBeforeRun, більше не зчитують package.json проєктів workspace, чиї файли не змінювалися після останнього встановлення. У воркспейсі на 300 проєктів із sharedWorkspaceLockfile: false час виконання pnpm -r exec true скоротився з 490 мс до 42 мс.
• Підготовка середовища: усунуто зависання node або pnpm install під час завантаження ще не завантаженої версії Node.js у конфігураціях з globalPnpmfile.
• Global virtual store: виправлено помилки ERR_PNPM_CMD_SHIM_SYMLINK_BIN під час паралельних інсталяцій на етапі створення посилань на виконувані файли; виправлено роботу інсталяцій на Windows для залежностей з іменованих реєстрів (gh:, npmjs:); знову запускаються build-скрипти залежностей (наприклад, інсталятори git-хуків), якщо слот у глобальному сховищі вже був зібраний іншим проєктом.
• Робота з lockfile: ключі залежностей за замовчуванням залишаються чистими навіть при використанні префіксів на кшталт npmjs; pnpm install --frozen-lockfile коректно обробляє залежності *, що резолвляться в пререлізний latest, зв'язки через catalog: при excludeLinksFromLockfile, а також конфігурацію з addMissingPeerTypes.
• Локальні шляхи: відносні шляхи в кореневих overrides та каталогах коректно резолвляться від кореня workspace за наявності ізольованих lockfile для кожного проєкту.
• Дедуплікація: pnpm dedupe --check не змінює pnpm-lock.yaml під час аналізу та не падає, якщо відмінність полягає лише в оновленому алгоритмі integrity (наприклад, sha512 замість sha1).
• Peer-залежності: виправлено помилки дедуплікації та прив'язки варіантів peer-залежностей до інших проєктів за відсутності провайдера або наявності вкладених peer-пакетів. Додано попередження в pnpm peers check, якщо обов'язковий peer резолвиться без провайдера при autoInstallPeers: false та dedupePeerDependents: true.
• Розгортання та CLI: pnpm deploy зберігає symlink, ціль якого зникла з джерела (наприклад, посилання на видалену node_modules); виправлено пошук команд у директоріях bin із надлишковими відносними сегментами (наприклад, ../dist/cli.js); шел-шипи POSIX тепер екранують шляхи лапками.