Що нового в pnpm 12.19

Коротко

Реліз pnpm 12.19.0 додає команду pnpm fund, дозволяє лінкеру loaded обробляти пакети, що потребують збірки, та представляє налаштування projectScopedOptionalPeers разом із експериментальним форматом lockfile v13. Пакетний менеджер тепер перевіряє поля engines і платформи для кожного проєкту у workspace. Також реліз містить виправлення безпеки, що запобігає витоку облікових даних реєстру під час помилок встановлення в офлайн-режимі.

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

Команда pnpm fund

Додано команду pnpm fund, яка виводить список URL-адрес для фінансування, оголошених встановленими залежностями, у тому ж дереві, що й npm fund.

• Прапорець --json формує звіт у форматі npm fund --json.
• Прапорці --recursive або --filter дозволяють формувати звіти для проєктів у workspace.
• Команда pnpm fund <pkg> відкриває URL фінансування встановленого пакета, а прапорець --which дозволяє обрати одну адресу, якщо їх кілька.

Покращення лінкера loaded

У режимі nodeLinker.type: loaded пакети, які потребують збірки, більше не потрібно додавати до списку nodeLinker.excluded:

• Пакет із відповідним записом у кеші побічних ефектів завантажується зі сховища.
• Якщо читання та запис кешу побічних ефектів увімкнено, pnpm одноразово збирає підтверджений пакет, зберігає результат у кеш побічних ефектів і надалі завантажує його зі сховища. Це стосується і збірок, які не змінюють файли в пакеті, тому їхній скрипт не запускатиметься повторно в інших проєктах із тим самим сховищем.
• Якщо збірка пакета має виконуватися в кожному проєкті (наприклад, установник git-хуків), його слід додати до sideEffectsCache.exclude.
• Інші промахи повз кеш, пакети з нативними доповненнями .node та їхні залежності матеріалізуються автоматично.
• pnpm сканує JavaScript-код на наявність імпортів файлової системи, __dirname або import.meta, автоматично матеріалізуючи відповідні пакети. Оскільки сканування не розпізнає динамічні обчислювані імпорти, такі пакети потрібно вказувати в nodeLinker.excluded.

Керування peer-залежностями

Додано налаштування projectScopedOptionalPeers. Якщо значення встановлено в true, проєкт отримує відсутню опціональну peer-залежність лише тоді, коли версію встановлюють його власні залежності. Залежності іншого проєкту у workspace (наприклад, його devDependencies) більше її не надають. Водночас dedupePeerDependents продовжує дедуплікувати решту залежностей.

Експериментальний lockfile.format: v13

З конфігурацією lockfile.format: v13 pnpm записує pnpm-lock.yaml у синтаксисі, подібному до JSON, із відступами табуляцією та комою після кожного запису, зберігаючи валідність YAML:

• Замість секцій packages і snapshots файл містить один запис packages на версію пакета.
• Кожен запис фіксує версії своїх peer-залежностей як власні властивості, тому оновлення peer-залежності змінює лише рядки з її версією.
• pnpm здатний читати файли lockfile в обох форматах незалежно від поточного значення налаштування.

Робота зі сховищем і кросплатформність

• Команда pnpm store add тепер приймає каталоги з архівами (наприклад, pnpm store add ./tarballs) і рекурсивно додає всі файли .tgz, .tar.gz та .tar. Додавання великої кількості пакетів або локальних архівів стало швидшим.
• За наявності supportedArchitectures команди pnpm install та pnpm fetch додатково зберігають у сховищі (без створення лінків) залежності архівів для інших зазначених платформ. Залежності з git-репозиторіїв та опціональні залежності, які зазначена платформа не може виконати або не змогла завантажити, не зберігаються.
• Якщо supportedArchitectures визначає рівно одну платформу (відмінну від current), pnpm лінкує варіант пакета для цієї платформи разом із його залежностями. Зміна налаштування або платформи хоста призводить до повторного лінкування під час наступного встановлення навіть із замороженим lockfile.
• Додано попередньо зібраний бінарний файл для NetBSD 10 на x64.

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

Безпека

• Повідомлення про помилку відсутності архіву в сховищі в офлайн-режимі більше не виводить облікові дані чи токен з URL-адреси тарболу.

Перевірки engines та платформ

• Команди pnpm install, pnpm add, pnpm update та pnpm remove тепер перевіряють поля engines, os, cpu та libc для кожного проєкту у workspace, включаючи корінь. pnpm run -r та pnpm exec -r виконують перевірку перед запуском. Несумісний engines.pnpm зупиняє команду помилкою; несумісний engines.node виводить попередження (або помилку за умови engineStrict); непідтримувана платформа генерує попередження.
• Опціональна залежність без полів os, cpu чи libc більше не пропускається лише через наявність назви ОС у її імені (наприклад, get-windows на macOS). Платформа визначається за назвою лише тоді, коли вона також містить токен процесора або libc (наприклад, -win32-x64).
• Виправлено пропущені попередження, коли обов'язкова залежність не підтримує поточну версію Node.js.

Стабільність інсталяцій

• Команди pnpm install, pnpm ci та pnpm install-test за межами workspace тепер завершуються з помилкою ERR_PNPM_NO_PKG_MANIFEST, якщо каталог не містить package.json, package.json5 чи package.yaml.
• Виправлено зависання pnpm install, якщо одночасне завантаження архіву або читання маніфесту скасовувалося під час очікування іншими задачами.
• Запуск глобальної команди (наприклад, node) у проєкті з зафіксованою версією більше не зависає під час встановлення цієї версії pnpm.
• Плейсхолдер ${VAR} в URL реєстру всередині pnpm-workspace.yaml або .npmrc тепер призводить до помилки, оскільки змінні оточення в цих файлах не підставляються.
• Завантаження архіву пакета тепер зупиняється після кількості спроб, визначеної fetchRetries, без повторного повного циклу спроб.
• Виправлено залишення відкритих каналів процесів (pipes) після виходу pnpm на macOS.

Заморожений lockfile та лінкер hoisted

• pnpm install --frozen-lockfile тепер успішно виконується, якщо зафіксований у lockfile проєкт workspace має порожній каталог (наприклад, неініціалізований git-підмодуль).
• pnpm install --frozen-lockfile завершується помилкою ERR_PNPM_OUTDATED_LOCKFILE, якщо зв'язаний через звичайний діапазон semver пакет workspace змінив версію за межі діапазону.
• У режимі nodeLinker: hoisted пакет, який запускає скрипт життєвого циклу або має патч, тепер клонується чи копіюється в node_modules. Перезапис файлів під час збірки більше не впливає на копію у спільному сховищі.
• У режимі nodeLinker: hoisted pnpm більше не видаляє каталог за межами node_modules під час видалення пакета, каталог scope якого є символьним посиланням.