pnpm виходить за межі JavaScript: один менеджер пакетів тепер працює з Python і Rust

Менеджер пакетів pnpm, відомий насамперед у світі JavaScript, зробив великий крок до універсального інструмента для змішаних проєктів. У версії 12.5 він отримав повноцінні механізми роботи з Python, навчився приймати стандартні Package URL для пакетів npm, PyPI та Cargo й додав загальносистемні ліміти для паралельних задач. Для звичайного користувача це майже непомітна зміна, але для команд, які поєднують вебінтерфейс, Python-сервіси та модулі на Rust, вона може прибрати частину окремих скриптів і ручних налаштувань.

Python став повноцінною частиною робочого простору

Найпомітніша зміна pnpm 12.5 — менеджер тепер підбирає інтерпретатор Python окремо для кожного проєкту відповідно до requires-python і враховує файл .python-version. Якщо сумісного Python на комп’ютері немає, pnpm може встановити збірку python-build-standalone та повторно використовувати її для інших проєктів.

Віртуальні середовища зберігаються у спільному сховищі, а в каталозі проєкту лишається посилання .venv. За задумом розробників це зменшує дублювання файлів. Підтримуються Python-проєкти з pyproject.toml, робочі простори uv, групи залежностей, extras, Git-залежності та збирання пакетів із вихідних архівів. Один lock-файл може фіксувати колеса одразу для кількох платформ і версій Python.

Одна адреса для різних екосистем

Команда додала підтримку Package URL — стандартизованого запису, який однозначно вказує тип екосистеми, ім’я та версію пакета. Наприклад, команда з адресою pkg:npm/express@4.18.2 додає Express у package.json, pkg:pypi/requests@2.31.0 — Requests у pyproject.toml, а pkg:cargo/serde@1.0.188 — Serde у Cargo.toml.

Практичний сенс: автоматизація отримує однаковий формат ідентифікатора незалежно від мови. Це може бути зручно для внутрішніх каталогів компонентів, генераторів проєктів і систем обліку залежностей. Водночас сама поява єдиного синтаксису не робить npm, PyPI та Cargo однією екосистемою: їхні правила версій, метадані й способи збирання залишаються різними.

Менше конфліктів у великих збірках

У робочому просторі тепер можна об’єднувати задачі у групи конкуренції та задавати ліміт для кожної групи. Обмеження діє на рівні машини й враховує різні процеси pnpm. Наприклад, команда може дозволити лише два одночасні завдання Cargo, навіть якщо кілька конвеєрів запущено паралельно. Це корисно, коли компіляція забирає багато оперативної пам’яті або кілька тестів одночасно звертаються до одного обмеженого ресурсу.

Також supportedArchitectures тепер може містити готовий список платформ на кшталт linux-x64, darwin-arm64 чи win32-x64. Старі окремі поля для операційної системи, процесора та libc продовжують працювати, тому негайно переписувати чинні конфігурації не потрібно.

Оновлення містить важливе виправлення

У release notes окремо зазначено виправлення помилки завантаження: раніше інсталятор міг повторно використати архів одного пакета для іншого, якщо різні залежності вказували на ту саму URL-адресу, але мали різні контрольні суми. Тепер такі випадки розрізняються. Крім того, pnpm навчився зливати Git-конфлікти у lock-файлі, покращив роботу Cargo-залежностей і пришвидшив встановлення у великих Python-workspace.

Чи варто переходити зараз

• Для звичайного JavaScript-проєкту оновлення не вимагає переходу на Python-функції. Спершу варто прогнати CI й перевірити lock-файл у тестовій гілці.
• Для monorepo з кількома мовами нові можливості краще випробувати на одному сервісі, перш ніж замінювати окремі інструменти всієї команди.
• Для захищених середовищ потрібно явно визначити, чи дозволено автоматичне завантаження інтерпретатора та збирання Python-пакетів із вихідних кодів.
• Для відтворюваних збірок слід закріпити версію pnpm, зберігати lock-файли в репозиторії та перевіряти контрольні суми артефактів.

Головне обмеження

pnpm не скасовує uv, pip або Cargo і не обіцяє, що будь-який складний проєкт мігрує без змін. Версія 12.5 передусім створює спільний керівний шар для робочого простору. Командам із нестандартними індексами, власними build-backend або суворою політикою постачання потрібно перевірити нову поведінку на копії проєкту.

Висновок: новий pnpm цікавий не кількістю доданих команд, а зміною масштабу. Інструмент, що починався як економний менеджер пакетів для Node.js, тепер намагається керувати залежностями й задачами багатомовного репозиторію. Для веброзробників це може означати менше розрізнених сценаріїв, але лише після обережної перевірки сумісності.

Перекладено й адаптовано за офіційними release notes pnpm 12.5.0 від 18 вересня 2026 року. Практичні пояснення та застереження додано редакцією. Текст першоджерела охоплений MIT License. Обкладинка: Markus Spiske / Wikimedia Commons, CC0.