pnpm 12.8 попередить, якщо ви випадково публікуєте .env із ключами та паролями

pnpm 12.8 почав попереджати розробника, якщо команда пакування або публікації збирається відправити до npm файл .env чи .env.*, якого немає в явному списку files у package.json. Це невелике повідомлення закриває дуже неприємний клас помилок: у змінних середовища часто лежать API-ключі, паролі до баз, токени хмарних сервісів та інші секрети, а опублікований пакет може завантажити будь-хто.

Що змінилося у pnpm 12.8

Команди pnpm pack і pnpm publish тепер аналізують майбутній архів. Якщо до нього потрапляє .env або файл на кшталт .env.production, але автор не перелічив його в полі files, менеджер пакетів показує попередження. Шаблони на зразок .env.example не вважаються секретом і не створюють шуму.

Логіка залишає можливість свідомо опублікувати потрібний env-файл. Автор може прямо додати його до files. Якщо ж файл зайвий, його слід виключити через .npmignore або .gitignore. Це саме попередження, а не жорстка заборона, тому автоматичний pipeline не повинен вважати оновлення повним захистом.

Чому gitignore не завжди достатньо

Вміст npm-пакета формується за власними правилами. Поле files, .npmignore, службові виключення та стан каталогу можуть дати результат, який відрізняється від очікувань розробника. Файл може не бути в Git, але все одно опинитися в робочій теці під час збірки та потрапити в tarball.

Саме тому безпечна перевірка має дивитися на фінальний архів. Команда pnpm pack --dry-run або звичайний pnpm pack показує, що реально буде опубліковано. У CI варто розпакувати tarball у тимчасову теку та просканувати назви файлів і відомі формати секретів. Попередження pnpm додає ще один бар’єр, але не замінює цей контроль.

Що робити, якщо секрет уже потрапив у пакет

1. Негайно відкликати ключ. Видалення версії з npm не повертає секрет: архів могли завантажити, кешувати або скопіювати.
2. Випустити новий токен з мінімальними правами й коротким строком дії.
3. Перевірити журнали використання старого ключа з моменту першої публікації.
4. Прибрати файл із пакета та опублікувати виправлену версію, але не покладатися на це як на ротацію.
5. Додати перевірку до CI, щоб та сама помилка не повторилася в іншому пакеті монорепозиторію.

Інші помітні зміни релізу

Версія 12.8 покращила офлайн-інсталяцію: pnpm тепер шукає найновішу сумісну версію, tarball якої вже є у локальному сховищі, замість вибору версії лише за кешованими метаданими та подальшої помилки через відсутній архів. Це робить збірки без мережі передбачуванішими.

Для монорепозиторіїв зі sharedWorkspaceLockfile: false проєкти встановлюються паралельно. Виправлено конкурентні встановлення, які одночасно замінювали те саме застаріле hoisted-посилання, а також очищення пошкоджених каталогів після перерваного процесу. На Windows термінал більше не повинен залишатися у некоректному стані після Ctrl+C у скрипті.

Оновлення також коректніше працює з optional-залежностями для devDependencies, локальними file:-пакетами, npm-аліасами й складними peer dependency. Для команд це радше набір зменшень тертя, ніж причина негайно перебудовувати весь pipeline.

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

• Зафіксуйте версію менеджера пакетів через Corepack або поле packageManager.
• Оновіть pnpm в окремій гілці й порівняйте lockfile без сторонніх змін.
• Запустіть чисту інсталяцію на Linux, Windows та інших підтримуваних платформах.
• Перевірте pnpm pack для кожного публічного пакета в монорепозиторії.
• Додайте сканер секретів до архіву та забороніть публікацію при знахідці.
• Якщо використовуєте pnpr, frozen lockfile або нестандартні hooks, уважно прочитайте повний changelog.

Важливе обмеження нового захисту

Попередження шукає конкретну небезпечну ознаку — назву .env. Секрет може лежати в config.json, тестовому fixture, згенерованому JavaScript, source map або випадково вбудуватися в bundle. І навпаки, деякі env-файли містять лише публічні дефолти. Тому найкращий захист — короткоживучі ключі, мінімальні права, секрети поза деревом збірки й автоматичне сканування фінального артефакту.

Висновок: pnpm 12.8 не робить публікацію безпомилковою, але переносить перевірку ближче до моменту, коли помилку ще можна зупинити. Якщо команда підтримує npm-пакети, варто не лише оновити менеджер, а й перетворити перевірку tarball на обов’язковий крок релізу.

Перекладено й адаптовано за release notes pnpm 12.8.0 від 28 вересня 2026 року. Текст релізу та документація репозиторію доступні за MIT License. Обкладинка Lorenzo Cafaro з Wikimedia Commons передана у CC0 і не входить до першоджерела.