pnpm 12.4 об’єднав JavaScript, Python і Rust в одному workspace
pnpm 12.4 навчився встановлювати npm-пакети, Python-залежності та Rust crates однією командою, а новий pipeline запускає кешовані задачі лише для змінених проєктів.

pnpm 12.4.0 перетворює звичний менеджер JavaScript-пакетів на координатор багатомовного monorepo. В одному workspace тепер можна керувати npm-пакетами, Python-залежностями та Rust crates, а команда pnpm install встановлює їх разом. Для команд, які мають вебінтерфейс, Python-сервіси обробки даних і модулі на Rust, це шанс скоротити кількість окремих сценаріїв підготовки середовища.

Як працюють Python і Cargo
Підтримка вмикається параметрами python.enabled або cargo.enabled у pnpm-workspace.yaml. Python-пакет додається селектором pypi:; pnpm працює з pyproject.toml, pylock.toml та керованим середовищем .venv. Заморожені й офлайн-встановлення підтримуються, а pnpm run і pnpm exec бачать виконувані файли віртуального середовища.
Для Rust застосовується селектор crate:. Підтримуються crates.io та власні sparse registry через cargo.indexUrl. Авторизація може використовувати облікові дані pnpm, змінну CARGO_REGISTRY_TOKEN або Cargo credentials. Обидві екосистеми здатні прискорювати resolution через pnprServer із локальним fallback.
Новий pnpm pipeline
Команда pnpm pipeline встановлює зафіксовані залежності та запускає граф задач, описаний у секції pipelines. Вона визначає змінені проєкти, враховує залежності між ними, кешує результати й відновлює вихідні файли разом із журналами. Попередньо перевірити план можна через --dry-run — без запуску workspace hooks і задач.
Для кожної задачі задаються inputs, outputs, env і cache. Cargo-збірки можуть повторно використовувати build state між worktree через окремий target directory. Це особливо корисно для CI, де повна перебудова великого монорепозиторію часто витрачає більше часу, ніж самі тести.
Безпека registry і build scripts
Метадані registry тепер ізольовані за повною адресою, включно зі схемою та шляхом. Це не дозволяє повторно використати версії або tarball URL з іншого registry та змішувати кеш HTTP з HTTPS. Після оновлення перше встановлення повторно завантажить metadata, хоча package store залишиться незмінним.
Патчі, які додають build script або binding.gyp, тепер запускають збірку лише після схвалення. Пакет можна наперед заборонити через --allow-build=!package. Це зменшує ризик тихої появи виконуваного коду у вже перевіреній залежності.
Інші важливі зміни
- Додано підтримку Android arm64/x64, FreeBSD x64, Linux ppc64le, s390x і RISC-V.
- Повільне завантаження більше не завершується timeout, доки дані продовжують надходити.
pnpm deployприскорено для великих workspace і виправлено роботу з.pnpmfile.mjs.- Селектори
jsr:,npm:іworkspace:приймаються командами add/install. pnpm change checkперевіряє версії пакетів відповідно до правил релізу.
Що перевірити перед міграцією
Багатомовна підтримка нова, тому її краще спочатку випробувати на одному сервісі. Потрібно порівняти lock-файли, офлайн-режим, кеш CI й поведінку приватних registry. Окремо слід зафіксувати версію pnpm у CI: розробники зі старішим клієнтом не прочитають нову конфігурацію однаково.
Практичний висновок: pnpm 12.4 не скасовує Cargo чи Python-інструменти, але дає єдину точку запуску для складного workspace. Найбільший виграш отримають команди, які сьогодні підтримують кілька інсталяторів і несумісні кеші CI.
Джерело та права
Матеріал є самостійним українським перекладом-переказом офіційних release notes pnpm 12.4.0, опублікованих 8 вересня 2026 року. Код і документація репозиторію поширюються за ліцензією MIT. Перекладено й адаптовано редакцією «Бібліотеки програміста». Обкладинка створена редакцією за допомогою AI та не входить до першоджерела.
Матеріал перекладено, переказано та доповнено редакцією українською мовою.
Читайте далі — ми вже розбираємо наступну важливу тему.


