pnpm 11.7 додає налаштування frozenStore для встановлення з режимом сховища пакунків лише для читання, прапорець --batch для публікації всього робочого простору в одному запиті, токени автентифікації для конкретних областей видимості, а також делегує повне вирішення залежностей під час встановлення до pacquet. Крім того, у ній посилено контроль за використанням псевдонімів файлів блокування, декілька шляхів інсталяції тепер є детермінованими, а також включено низку виправлень, пов’язаних з публікацією та роботою в середовищі Windows.

pnpm used to expand ${ENV_VAR} placeholders everywhere it found them — including in the .npmrc and pnpm-workspace.yaml files that live inside the repository you just cloned. That turned out to be a way for a malicious repository to steal the secrets in your environment. As of v10.34.2 and v11.5.3, pnpm stops expanding environment variables in repository-controlled registry and credential settings.

This was a security fix (GHSA-3qhv-2rgh-x77r), and it is a breaking change for some setups. This post explains the attack, what exactly changed, and how to migrate.

pnpm 11.6 додає спосіб надання автентифікації в реєстрі без використання файлів через змінні середовища npm_config_//… та pnpm_config_//…, збільшує стандартну кількість одночасних мережевих запитів, а також пропускає повне повторне вирішення залежностей, якщо відсутній лише файл pnpm-lock.yaml. Вона також автоматично визначає поля платформи для необовʼязкових залежностей, тому бінарні файли для інших платформ ніколи не завантажуються.

pnpm 11.5 додає налаштування hoistingLimits для контролю того, наскільки високо піднімаються залежності під час встановлення з конфігурацією nodeLinker: hoisted, замінює бібліотеку інтерактивних підказок для виправлення прокручування у довгих списках вибору, розпізнає поетапні публікації у шкалі довіри, а також містить кілька виправлень для встановлення та dist-tag.

pnpm 11.4 закриває низку вразливостей у ланцюжку постачання, повʼязаних із цілісністю lockfile, обмеженням видимості облікових даних, вирішенням git-залежностей, файлами патчів і псевдонімами залежностей, робить невідповідність хешів цілісності архівів стандартною критичною помилкою встановлення (із можливістю вибору вузькоспрямованого прапорця --update-checksums), а також змінює поведінку pnpm runtime set так, що зазвичай запис відбувається в devEngines.runtime замість engines.runtime.

pnpm 11.3 додає підтримку поетапної публікації npm (pnpm stage), нове налаштування trustLockfile для пропуску перевірки ланцюжка постачання для вже довірених файлів lockfile, а також нативні реалізації pnpm pkg, pnpm repo та pnpm set-script. Крім того, додано прапорець --skip-manifest-obfuscation для команд pack та publish, що дозволяє зменшити обсяг пам’яті, який займає перевірка параметрів minimumReleaseAge та trustPolicy у великих робочих просторах.

У версії pnpm 11.2 реалізовано експериментальну опцію, яка дозволяє використовувати pacquet (портування pnpm на Rust) як бекенд для встановлення, розширює залежності конфігурації для встановлення одного рівня optionalDependencies (тож шаблон платформних бінарних файлів esbuild/swc працює також для залежностей конфігурації), підключає давно задокументований прапорець pnpm login --scope та виводить записи часу виконання (Node.js, Deno, Bun) у pnpm outdated та pnpm update --interactive.

pnpm 11.1 додає кілька нових команд — pnpm audit signatures, pnpm bugs та pnpm owner, разом із підтримкою встановлення з довільних іменованих реєстрів (включаючи вбудований псевдонім для реєстру npm GitHub Packages), можливістю пропускати встановлення середовища виконання в CI, а також кілька виправлень.

pnpm 11 вже тут! У цьому випуску посилено стандартні налаштування безпеки, запроваджені протягом усього циклу v10, скасовано використання npm CLI як альтернативного варіанту для публікації на користь власної реалізації, замінено індекс сховища у форматі JSON для кожного пакета на єдину базу даних SQLite, а також ізольовано глобальні інсталяції, щоб вони більше не впливали одна на одну.

Він також вимагає Node.js 22 або новішу версію — сам pnpm тепер є чистим ESM.

Оновлюєтесь з v10? Перегляньте інструкцію Міграція з v10 до v11. Більшість змін у налаштуваннях є механічними, і їх можна застосувати за допомогою кодмода pnpm-v10-to-v11.

у версії pnpm 10.32 до команди pnpm approve-builds додано параметр --all, який дозволяє затверджувати всі очікувані збірки без інтерактивних запитів.