🚀 pnpm у 2025 році

2025 рік став переломним для pnpm. Хоча нашою основною метою було переосмислення моделі безпеки управління пакунками, ми також досягли значного поліпшення продуктивності та зручності роботи розробників.

Від стандартного блокування скриптів життєвого циклу до впровадження глобального віртуального сховища — ось огляд основних функцій, реалізованих у 2025 році.

Використання

Згідно зі статистикою завантажень, pnpm було завантажено вдвічі більше, ніж у 2024 році!

Редизайн головної сторінки

Ви, можливо, помітили, що ми змінили дизайн нашої головної сторінки! Цей редизайн став можливим завдяки нашому найвидатнішому спонсору, Bit.cloud.

Нова головна сторінка тепер створена за допомогою компонентів Bit, і значна частина роботи була виконана за допомогою агента штучного інтелекту Bit: Hope AI. У нас навіть є власна система дизайну тепер.

інформація

Я працюю повний робочий день у Bit над управлінням залежностями. Під капотом Bit використовує pnpm для встановлення.

Презентація на JSNation

Цей рік став для мене важливим етапом, оскільки я вперше виступив з доповіддю на великій міжнародній конференції: JSNation, яка відбулася в червні в Амстердамі. Я хотів би подякувати команді JSNation за цю чудову можливість!

Я був приємно здивований, наскільки добре відомий pnpm у спільноті та скільки людей використовують його в роботі!

Моя презентація була про залежності конфігурації, і ви можете переглянути запис тут.

Основні функції

Тепер заглибмось в найважливіші зміни, що з'явилися в pnpm v10 протягом 2025 року.

Безпека як стандарт

Найзначнішим зрушенням цього року став перехід pnpm до «Безпеки як стандарт». У pnpm версії 10.0 ми перестали неявно довіряти встановленим пакункам.

Блокування скриптів життєвого циклу (v10.0)

Протягом багатьох років команда pnpm install означала довіру до всього дерева залежностей для виконання довільного коду. У версії 10 цю функцію було вимкнено. pnpm більше стандартно не запускає скрипти preinstall або postinstall, що усуває величезну кількість векторів атак на ланцюжок постачання.

Щоб удосконалити цей контроль, ми ввели allowBuilds у v10.26, замінивши попередній onlyBuiltDependencies більш гнучкою конфігурацією:

allowBuilds:
  esbuild: true
  # Дозволити лише конкретні версії
  nx@21.6.4: true

Ешелонований захист (v10.16 та v10.21)

Але ми не зупинилися лише на скриптах. Ми додали рівні захисту, щоб виловлювати шкідливі пакунки ще до того, як вони досягнуть вашого диска:

• minimumReleaseAge: Блокує релізи "zero-day" (наприклад, пакунки, випущені менше ніж 24 години тому), даючи спільноті час позначити шкідливі оновлення.
• trustPolicy: no-downgrade: Запобігає встановленню оновлень, які мають гіршу репутацію, ніж попередні версії (наприклад, версія, опублікована без перевірки CI/CD).
• blockExoticSubdeps: Запобігає завантаженню перехідних залежностей з ненадійних джерел довіреними залежностями.

Глобальне віртуальне сховище (v10.12)

Одним з оригінальних нововведень pnpm було сховище з адресацією контенту, яке заощаджує місце на диску шляхом дедуплікації файлів. У версії 10.12 ми пішли далі з Global Virtual Store.

Раніше проєкти мали власну структуру node_modules. Завдяки enableGlobalVirtualStore: true, pnpm тепер може безпосередньо повʼязувати залежності з центрального розташування на диску з вашим проєктом. Це означає:

1. Значна економія місця на диску: однакові графи залежностей використовуються в усіх проєктах.
2. Швидше встановлення: Якщо у вас є 10 проєктів, що використовують react@19, pnpm потрібно лише один раз глобально підключити їх.

Нативна підтримка JSR (v10.9)

Ми взяли на озброєння новий реєстр JSR з нативною підтримкою. Тепер ви можете встановлювати пакунки безпосередньо з JSR, використовуючи протокол jsr::

pnpm add jsr:@std/collections

Це коректно відображається в package.json та безперешкодно обробляє унікальні правила розвʼязання JSR-пакунків разом із вашими залежностями npm.

Конфігураційні залежності (v10.0)

Для монорепозиторіїв та складних налаштувань ми ввели Конфігураційні залежності. Ця функція дозволяє ділитися та консолідувати конфігурацію pnpm, таку як хуки, патчі та дозволи на збірку, між декількома проєктами.

Конфігураційні залежності встановлюються в node_modules/.pnpm-config до обробки основного графа залежностей. Це означає, що ви можете використовувати їх для:

• Спільне використання хуків .pnpmfile.cjs між репозиторіями.
• Централізувати файли патчів для patchedDependencies.
• Підтримувати спільний список пакунків, яким дозволено виконувати скрипти збірки для allowBuilds.

pnpm-workspace.yaml

configDependencies:
  pnpm-plugin-my-company: "1.0.0+sha512-..."

Це гарантує, що ваша конфігурація pnpm має версії, є узгодженою та доступною саме тоді, коли це потрібно менеджеру пакунків.

Автоматичне управління JavaScript Runtime (v10.14 & v10.21)

Ми вже деякий час підтримуємо керування середовищем виконання Node.js. У 2025 році ми розширили цю функцію, щоб підтримати інші середовища виконання, такі як Deno та Bun.

Тепер ви можете вказати потрібне середовище виконання в package.json через devEngines.runtime:

package.json

{
  "devEngines": {
    "runtime": {
      "name": "node",
      "version": "24.6.0"
    }
  }
}

pnpm автоматично завантажить та використовуватиме цю конкретну версію середовища виконання для запуску скриптів у цьому проєкті. Це робить фразу «Працює на моїй машині» реліктом минулого — всі члени команди використовують однакове середовище виконання, яке повністю управляється pnpm.

Що далі

Ми вже почали працювати над pnpm v11.0, яка має деякі помітні покращення продуктивності. Глобальне віртуальне сховище ще не є стандартно увімкненим. Ми працюватимемо над виправленнями помилок та відсутніми функціями, щоб потенційно зробити його стандартно увімкненим у майбутньому основному випуску.