pnpm 12.1 прискорює monorepo: граф задач, resume та перевірені артефакти

pnpm 12.1 перетворює рекурсивні команди monorepo на повноцінний планувальник задач: робота стартує одразу після завершення залежностей, для окремих задач можна встановлювати власну паралельність, а перерваний запуск — продовжувати з реально виконаного місця. Паралельно менеджер пакетів посилює перевірку вмісту store, розширює підтримку спільних build-артефактів і додає branch-specific lock-файли у новому Rust-рушії.

Monorepo більше не чекає на весь топологічний шар

Раніше pnpm -r run і pnpm -r exec виконували проєкти топологічними групами. Швидка бібліотека могла завершити build, але залежний застосунок усе одно чекав, поки закінчиться інший, не пов’язаний із ним пакет у тому самому шарі. У 12.1 планування відбувається на рівні задач: щойно всі конкретні залежності готові, наступна задача може стартувати.

Новий розділ tasks у pnpm-workspace.yaml описує граф явно. Запис ^build означає build у workspace-залежностях, а звичайний build — задачу в тому самому проєкті. Порожній список дозволяє позначити незалежну роботу. Якщо опису немає, зберігається сумісна поведінка: задача залежить від однойменних задач у залежностях пакета.

Для важких або ліцензійно обмежених інструментів можна вказати tasks.<name>.concurrency. Це корисно, коли десятки пакетів запускають браузерні тести, компілятор нативних модулів або інтеграційні стенди, але runner має обмежену пам’ять. Цикли тепер не приховуються: pnpm повертає ERR_PNPM_TASK_CYCLE. Опція ignoreWorkspaceCycles лишається аварійним виходом, однак тоді порядок задач усередині циклу не визначений.

Продовження після збою та прозорий dry-run

Стан завершених recursive tasks зберігається, тому --resume-from пропускає саме ту роботу, яка успішно завершилася в сумісному попередньому запуску. Це важлива різниця для CI: повторний запуск після збою в кінці pipeline не мусить компілювати весь monorepo заново. Якщо сумісного стану немає, менеджер повертається до графового правила продовження.

Команда pnpm -r run --dry-run показує план без запуску scripts, а --json віддає задачі та їхні resolved edges у машиночитному вигляді. Перед увімкненням нового scheduler варто зберегти цей граф як CI artifact: він допоможе пояснити, чому задача стартувала раніше або була пропущена після падіння залежності.

Безпечніше сховище та віддалені build-артефакти

Verified remote artifacts тепер потрапляють у shared store разом із підписаними метаданими походження. Під час повторного використання pnpm знову перевіряє довіру, політику, платформу та джерело, а непридатний варіант ізолює. Підтримка поширена на macOS і Windows для x64 та arm64. Водночас протокол експериментальний: сервер pnpr і клієнти повинні мати сумісні версії.

Новий strictStorePkgContentCheck ловить ситуацію, коли ім’я або версія у package.json усередині tarball не збігається з ключем store. За замовчуванням інсталяція завершується помилкою ERR_PNPM_UNEXPECTED_PKG_CONTENT_IN_STORE. Перетворювати це на warning варто лише після розслідування registry proxy або пошкодженого lock-файлу.

Lock-файли гілок і налаштування сумісності

Rust-рушій отримав gitBranchLockfile: кожна гілка може мати власний pnpm-lock.<branch>.yaml. mergeGitBranchLockfiles збирає їх назад у головний lock-файл і видаляє branch-файли. Це зменшує конфлікти у великих командах, але вимагає домовленості: CI, release automation і локальні hooks мають однаково розуміти, який файл є джерелом істини.

Також з’явився lockfileDir, додано shell emulator для однакової POSIX-поведінки scripts на різних ОС, а login/adduser зберігають token у глобальному config. Важлива захисна зміна: scope із repository-owned workspace config ігнорується з попередженням, щоб репозиторій не перенаправляв приватний scope користувача після звичайного login.

Практичний висновок: оновлюйте pnpm в окремій гілці, спочатку зніміть JSON dry-run граф, потім проганяйте build/test із обмеженою паралельністю. Не вмикайте remote artifacts і branch lockfiles одночасно з першою міграцією — так легше відокремити причину регресії.

Що перевірити перед production

• Чи всі внутрішні scripts мають коректні залежності й не покладаються на випадковий порядок.
• Чи вистачає CPU, RAM і ліцензій зовнішніх інструментів при ранньому старті задач.
• Чи не містить workspace config застарілий scope, який тепер ігнорується.
• Чи сумісні клієнти та pnpr server, якщо використовуються remote build artifacts.
• Чи відтворюються install і recursive run на Linux, macOS та Windows runner.

Джерело та права

Матеріал є самостійним українським перекладом-переказом release notes pnpm 12.1.0, опублікованих 29 серпня 2026 року командою pnpm. Текст release notes, код і документація офіційного репозиторію поширюються за MIT License. Перекладено, адаптовано й доповнено редакцією «Бібліотеки програміста». Обкладинка створена редакцією за допомогою AI і не входить до першоджерела.