pnpm 12.4.1 перестав ламати інсталяції на Android, у контейнерах і файлових системах без hard link

Команда pnpm випустила версію 12.4.1 — велике patch-оновлення, зосереджене не на нових командах, а на надійності встановлення пакетів у реальних середовищах. Реліз виправляє збої на Android, у rootless-контейнерах, EdenFS, Docker і файлових системах, які забороняють hard link або copy-on-write clone. Паралельно розробники зменшили кількість файлових операцій під час повторного install і усунули сценарій, у якому імпорт пакета міг записати дані через залишений символічний лінк.

Автоматичний перехід до безпечного копіювання

pnpm економить дисковий простір завдяки content-addressable store: файли пакетів не дублюються без потреби, а потрапляють у проєкт через hard links, reflinks або копіювання. Проблема виникає там, де конкретний filesystem чи ізоляція контейнера відмовляє в операції створення лінка. Раніше така відмова могла зупинити весь pnpm install повідомленням Operation not permitted.

У 12.4.1 режими packageImportMethod: auto і clone-or-copy переходять до звичайного копіювання, якщо hard link або clone недоступні. Це важливо для EdenFS, rootless-контейнерів і мобільних файлових систем. Явно задані режими hardlink або clone і надалі повертають помилку: адміністратор, який свідомо заборонив fallback, отримує передбачувану поведінку.

Symlink більше не стає каналом для перезапису

Найсерйозніше виправлення стосується шляху, куди pnpm імпортує файл пакета. Якщо на цьому місці залишався символічний лінк, копіювання могло змінити файл, на який він указував, створити відсутню ціль або навіть додати їй ознаку виконуваного файла. Тепер інсталятор не записує package file крізь такий symlink. Для CI та систем, де робоче дерево може містити залишки попередньої збірки, це зменшує ризик небажаних змін за межами очікуваного каталогу.

Android, Docker і hoisted node_modules

На Android запити до реєстру падали, коли pnpm не знаходив системних кореневих сертифікатів. Нова версія використовує вбудований набір CA, а імпорт файлів також може перейти до копіювання. У Docker виправлено Invalid cross-device link під час збереження вкладеного node_modules, коли джерело та ціль розташовані на різних шарах або mount points.

Для конфігурації nodeLinker: hoisted повторний install більше не імпортує наново пакети, які вже відповідають lock-файлу. Раніше pnpm міг замінювати все дерево і знову запускати lifecycle scripts. Тепер повторне встановлення залишає коректні каталоги на місці, але все одно відновлює пакет, якщо каталог зник, версія не збігається, залежність походить із file: або до неї застосовано patch.

Що саме прискорили

Під час повторного install pnpm перевіряє файли store лише для пакетів, які реально потрібно зв'язати з node_modules, а не для всього lock-файлу. У тестовому workspace на 76 проєктів створення командних shim-файлів потребувало приблизно на 1500 filesystem calls менше. Також знижено використання пам'яті під час перевірки великих lock-файлів, кешується metadata checksum для Cargo workspace, а кілька пакетів з одного Git-репозиторію й commit завантажуються один раз за install.

Ці цифри не є універсальним benchmark. Виграш залежить від кількості workspace-проєктів, типу диска, антивіруса, глобального virtual store та стану кешу. Для невеликого застосунку різниця може бути непомітною, тоді як великий monorepo отримає відчутне скорочення зайвих операцій.

Зміни для monorepo та CI

ignoredOptionalDependencies тепер застосовується в install, add і dedupe: збіглі optional dependencies не потрапляють у lock-файл і не встановлюються. Команда pnpm dedupe за замовчуванням обробляє всі проєкти workspace, включно з конфігураціями з окремими lock-файлами. Водночас linkWorkspacePackages: true більше не підміняє транзитивну залежність локальним пакетом лише через звичайний version range; для глибокого зв'язування потрібно вказати deep.

Обробка Ctrl+C стала акуратнішою: сигнал передається дочірній команді, а pnpm чекає її завершення. Це важливо для dev-серверів і генераторів, які мають закрити файли або прибрати тимчасові ресурси. У Windows файлові операції тепер коротко повторюються після permission error, а постійна помилка не затримує завершення на хвилину.

Як оновлюватися без сюрпризів

• Зафіксуйте pnpm 12.4.1 через Corepack або поле packageManager і проганяйте той самий lock-файл локально та в CI.
• Окремо перевірте rootless Docker, Android/Termux, мережеві filesystem і nodeLinker: hoisted, якщо вони використовуються у вашому процесі.
• Порівняйте холодний та повторний install; не робіть висновок лише за одним запуском із прогрітим кешем.
• Перегляньте власні lifecycle scripts: після виправлення hoisted-режиму коректний пакет не буде перебудовуватися без причини.
• Якщо політика вимагає виключно hard links, залиште явний packageImportMethod: hardlink і не покладайтеся на автоматичний fallback.

Висновок

pnpm 12.4.1 вартий планового оновлення насамперед командам із великими monorepo, контейнерними збірками та нестандартними файловими системами. Реліз одночасно прибирає причини випадкових падінь, закриває небезпечну поведінку навколо symlink і скорочує зайву роботу повторного install. Це patch-реліз, але за практичним впливом він ближчий до оновлення надійності всього package pipeline.