pnpm 11.0.5: чому варто перевірити `dlx`, `create` та self-update на Intel Mac

pnpm оновився, і тепер dlx може поводитися інакше

pnpm 11.0.5 і супутній pnpm 10.33.3 — це не косметичні патчі. Вони змінюють поведінку в двох зонах, де помилки тихо ламють developer bootstrap і CI: пакети через pnpm dlx / pnpm create з транзитивними install scripts і self-update на Intel macOS. Якщо ваша команда працює на pnpm 10 або 11, краще перевірити ці сценарії заздалегідь, ніж шукати причину дивного поломки в понеділок вранці.

Що сталося

pnpm 11.0.5

Реліз 11.0.5 приніс кілька змін, які стосуються реальних workflow:

1. Зміна поведінки pnpm dlx та pnpm create — ці команди тепер інакше працюють з транзитивними install scripts. Якщо пакет, який ви запускаєте через dlx, тягне за собою залежність із postinstall / install скриптом, pnpm тепер вимагає явного дозволу через approve-builds.
2. Кращий cleanup після failed install — якщо встановлення падає, pnpm прибирає за собою чистіше. Це важливо для CI, де брудні стані node_modules призводять до хибних позитивних або негативних результатів.
3. Явний дозвіл білд-скриптів — механізм approve-builds тепер точніше фіксує, які пакети мають право запускати build scripts. Це контролюється через onlyBuiltDependencies / ignoredBuiltDependencies у package.json.

pnpm 10.33.3

Паралельний патч 10.33.3 стосується self-update на Intel macOS. Якщо хтось у команді досі користується MacBook з процесором Intel і оновлює pnpm через pnpm self-update, видалений артефакт darwin-x64 з @pnpm/exe може залишити вас без робочого пакетного менеджера.

Чому це важливо

Три типові сценарії, де можна наступити на граблі:

1. Генератори проєктів через pnpm create

Багато популярних темплейтів (create-vite, create-next-app, create-svelte та інші) використовують pnpm create. Якщо такий генератор або одна з його транзитивних залежностей має install / postinstall скрипт, pnpm 11 може зупинити його й попросити явного дозволу. На локальній машині це просто зайве повідомлення. У CI — це фейлений пайплайн.

2. Одноразові CLI-інструменти через pnpm dlx

Команди виду pnpm dlx @some/tool --init часто живуть у onboarding-скриптах або Makefile. Якщо @some/tool тягне залежність із build script, pnpm 11 може поводитися інакше, ніж pnpm 10. І це «інакше» — не завжди очевидне з помилки.

3. Intel macOS — пастка self-update

pnpm 10.33.3 офіційно підтверджує: darwin-x64 бінарний артефакт видалено з @pnpm/exe. Якщо хтось на Intel Mac використовує pnpm self-update — pnpm просто перестане знаходити нову версію для своєї архітектури. Не «зламається», а мовчки не оновиться. Це гірше, явна помилка хоча б показує, що щось не так.

Як перевірити свої скрипти за 20 хвилин

Крок 1 — Версія pnpm

pnpm -v

Якщо у вас pnpm 11.x — ви під ударом змін у dlx / create. Якщо 10.x — все одно має сенс перевірити, особливо перед планованим переходом на 11.

Крок 2 — Знайдіть усі dlx / create у кодовій базі

# Пошук у Makefile, CI-конфігах, скриптах
grep -rn "pnpm dlx\|pnpm create" Makefile .github/ scripts/ .ci/ 2>/dev/null

Не забудьте перевірити:

• Makefile
• .github/workflows/*.yml
• Jenkinsfile або docker-compose-скрипти
• onboarding-діру (README.md, CONTRIBUTING.md)
• локальні alias-и в .zshrc / .bashrc командного сервера

Крок 3 — Перевірте approve-builds

Відкрийте package.json і знайдіть розділ pnpm:

{
  "pnpm": {
    "onlyBuiltDependencies": ["esbuild", "sharp"],
    "ignoredBuiltDependencies": ["bufferutil"]
  }
}

Правило: кожен пакет, який має install script і використовується (навіть транзитивно), має бути або в onlyBuiltDependencies, або в ignoredBuiltDependencies. Якщо pnpm скаржиться на неузгодженість — це сигнал.

Запустіть:

pnpm approve-builds

Ця команда інтерактивно покаже, які пакети мають build scripts, і дозволить додати їх у правильний список. Для CI можна запустити з --allow-build для кожного пакета, який ви знаєте і довіряєте.

Крок 4 — Протестуйте dlx локально

Запустіть кожен pnpm dlx / pnpm create, який ви знайшли в кроці 2:

pnpm dlx create-vite@latest test-project --template vanilla
# Перевірте, чи проходить без запитань про approve-builds
rm -rf test-project

Якщо команда зупиняється й просить дозволу — ви знайшли проблему до того, як вона впаде в CI.

Крок 5 — Intel Mac самоперевірка

Для розробників на Intel Mac:

uname -m
# Має повернути x86_64

# Перевірте, як встановлено pnpm
which pnpm
# Якщо шлях веде через ~/.local/share/pnpm або @pnpm/exe — увага

Якщо pnpm встановлено через @pnpm/exe (окремий npm-пакет з бінарником) — pnpm self-update більше не працюватиме на Intel. Рішення: перевстановити pnpm через npm глобально:

npm install -g pnpm

Це універсальний спосіб, який працює на всіх архітектурах.

Що НЕ робити (типові помилки)

Не ігноруйте approve-builds у CI

Буде спокуса пробігти через approve-builds інтерактивно, додати все в ignoredBuiltDependencies і забути. Це знімає проблему зараз, але створює security-ризику: будь-який новий пакет із install script автоматично отримає право бігати під час pnpm install.

Правильний підхід: використовуйте onlyBuiltDependencies — явний white-list, а не ігнорування всього.

Не оновлюйте pnpm у CI без локальної перевірки

Якщо ваша команда перейшла на pnpm 11.0.5 і хтось пушить — CI може зламан через нову поведінку dlx. Правило просте: оновлення pnpm = локально прогнати всі pnpm dlx / pnpm create = потім CI.

Не покладайтеся на pnpm self-update на Intel Mac

Це вже не працюватиме. Якщо хтось у команді досі на Intel — це не edge case, це реальна людина, яка завтра не зможе оновитися перед стендапом.

Не пропускайте транзитивні залежності

Навіть якщо ваш безпосередній пакет без install scripts — його транзитивна залежність може мати. І pnpm 11 це перевірятиме.

# Знайти пакети з install scripts у дереві
pnpm ls --recursive | while read pkg; do
  node -e "try{let p=require('$pkg/package.json'); if(p.scripts?.install||p.scripts?.postinstall) console.log('$pkg has install script')}catch{}"
done

Чеклист команди

Ось мінімальний чеклист, який можна додати в командну документацію або onboarding:

1. Версія: переконайтеся, що всі в команді на одній major-версії pnpm (pnpm -v).
2. dlx/create smoke test: прогоніть pnpm dlx create-vite@latest — має працювати без prompt-у.
3. approve-builds audit: перевірте package.json → pnpm.onlyBuiltDependencies.
4. Intel Mac: якщо є — перевстановіть через npm: npm install -g pnpm.
5. CI pipeline: додайте pnpm approve-builds --allow-build <пакет> у build-скрипт для кожного відомого пакета з install script.
6. README: задокументуйте версію pnpm і мінімальний smoke test для нових членів команди.

Висновок

pnpm 11.0.5 — важливе оновлення з точки зору безпеки та надійності, але воно змінює правила гри для dlx/create-workflow і self-update на Intel Mac. Перевірка займає 20–30 хвилин і зберігає ваш CI від неочікуваних падінь.

Якщо хочете глибокіший аудит — спробуйте Prompt Pack нижче, підставте свої дані, і отримайте структурований аналіз ризиків для вашої команди.