Чому pnpm встановлює швидше, ніж npm: сховище, посилання та строгий режим node_modules

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

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

1. Сховище з адресним керуванням контентом замість дубльованих файлів

Основна перевага полягає у способі зберігання пакетів на диску. У npm кожен проект отримує власну структуру всіх залежностей у директорії node_modules. Тож десять додатків, яким потрібен lodash, зберігають по десять окремих копій цього пакету на диску.

pnpm підтримує один глобальний контент-адресований сховище для машини. Кожна версія займає там окрему позицію; проект, який її потребує, отримує жорсткі посилання (або посилання з копіюванням під час запису) з цього сховища до своїх локальних node_modules. Наслідки включають:

• Уникнення повторного завантаження, коли сховище вже містить цю версію
• Уникнення повторного запису байтів, які вже існують на диску
• Значне зменшення використаної пам’яті, коли багато проектів ділять бібліотеки

Оскільки процес встановлення значною мірою залежить від операцій введення-виведення з диска, саме усунення повторних записів призводить до значного зменшення затримок.

2. Жорсткі та символічні посилання замість копіювання

Шлях встановлення npm копіює файли пакету до node_modules. Копіювання тисяч файлів у складній структурі є дорогим процесом.

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

3. Ефективне кешування між проектами

npm також кешує завантажені дані, проте все одно розширює та копіює їх з цього кешу до кожного проекту. За моделлю сховища pnpm, як тільки версія існує де-небудь у системі, її включення до абсолютно нового проекту відбувається майже миттєво — без додаткового завантаження та з мінімальною додатковою обробкою.

Ця поведінка є особливо корисною у таких ситуаціях:

• Переході між гілками, які використовують різні набори залежностей
• Керуванні кількома репозиторіями, які спільно використовують бібліотеки
• Виконанні завдань CI, які відновлюють спільне сховище під час кожної збірки

4. Структура node_modules, яка не є плоскою та уникає додаткової роботи з обробкою

Старіші версії npm використовували метод піднесення елементів, щоб зробити node_modules плоским та уникнути дублювання, але цей підхід мав свої недоліки: потребував складної обробки для визначення місця розміщення кожного пакета без конфліктів.

pnpm зберігає сувору структуру node_modules з посиланнями, тож пакет бачить лише ті залежності, які він сам оголосив (без випадкових непотрібних імпортів). Безпечніша обробка — це не єдиний перевага: цей підхід також уникає дорогого процесу планування піднесення елементів у npm, що зменшує навантаження на процесор під час встановлення.

5. Паралельні операції

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

6. Вплив у реальному світі зростає з розміром проекту

У додатку-іграшці з кількома пакетами різниця може здаватися незначною. Перевага зростає у міру:

• Monorepos, у яких багато пакетів використовують одні й ті самі бібліотеки
• Команд, які керують кількома продуктами за допомогою спільних залежностей
• CI/CD-пайплайнів, які неодноразово встановлюються під час кожної збірки
• Великих дерев залежностей, характерних для сучасних фронтенд-систем

У таких умовах час встановлення через store-and-link, який раніше становив хвилини за допомогою npm, може скоротитися до секунд.

7. Економія місця на диску — це побічний ефект, а не просто бонус

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

Швидка аналогія

Висновок

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

Для команд, які мають кілька проєктів або monorepo, впровадження pnpm є одним із найпростіших способів покращення як часу встановлення, так і використання диска.