Перейти до основного змісту
Версія: 11.x

Глобальне віртуальне сховище

Зазвичай, pnpm створює теку .pnpm всередині node_modules кожного проєкту — це створенням «віртуального сховища». Тека містить жорсткі посилання на файли у сховищі з адресованим вмістом. Кожен проєкт отримує власну копію цього віртуального сховища — pnpm створює жорсткі посилання на файли зі сховища з адресованим вмістом у структурі тек .pnpm. Фактичний вміст файлів зберігається на диску лише один раз, але структура тек відтворюється для кожного проєкту, щоб алгоритм визначення модулів Node.js міг знайти потрібні залежності для кожного пакунка.

Глобальне віртуальне сховище (enableGlobalVirtualStore: true) змінює це. Замість того, щоб кожен проєкт мав власну теку node_modules/.pnpm, pnpm підтримує єдине спільне віртуальне сховище (розташоване в теці <store-path>/links/; щоб дізнатися, де саме знаходиться <store-path>, виконайте команду pnpm store path). Тека node_modules кожного проєкту містить лише символічні посилання, що ведуть до цього спільного місця.

Стандартна поведінка та глобальне віртуальне сховище​

Стандартна поведінка (віртуальне сховище для кожного проєкту)​

project-a/
└── node_modules/
    ├── lodash → .pnpm/lodash@4.17.21/node_modules/lodash
    └── .pnpm/
        └── lodash@4.17.21/
            └── node_modules/
                └── lodash/            ← жорсткі посилання на сховище з адресацією за вмістом
project-b/
└── node_modules/
    ├── lodash → .pnpm/lodash@4.17.21/node_modules/lodash
    └── .pnpm/
        └── lodash@4.17.21/
            └── node_modules/
                └── lodash/            ← ті самі жорсткі посилання, дубльована структура тек

Кожен проєкт має свою власну структуру .pnpm з жорсткими посиланнями. Вміст файлів на диску не дублюється (жорсткі посилання використовують спільні inodes), натомість структура тек дублюється. У разі великих монорепозиторіїв або великої кількості паралельних перемикань час, витрачений на створення тисяч жорстких посилань під час виконання команди pnpm install, стає значним.

Глобальне віртуальне сховище​

project-a/
└── node_modules/
    └── lodash → <global-store>/links/@/lodash/4.17.21/<hash>/node_modules/lodash
project-b/
└── node_modules/
    └── lodash → <global-store>/links/@/lodash/4.17.21/<hash>/node_modules/lodash  ← теж саме місце призначення

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

Як працює ідентифікація пакунків​

У глобальному віртуальному сховищі кожна тека пакунка має імʼя, що відповідає хешу її графа залежностей. Два проєкти, які використовують lodash@4.17.21 з однаковим деревом транзитивних залежностей, вказуватимуть на одну й ту саму теку. Якщо дерева залежностей відрізняються (наприклад, мають різні прямі залежності) — pnpm створює окремі записи. Це концептуально схоже на те, як NixOS керує пакунками за допомогою хешів графів залежностей.

Коли використовувати глобальне віртуальне сховище​

Глобальне віртуальне сховище найбільш корисне, коли на диску зберігається кілька копій одного й того самого проєкту — наприклад, під час використання git worktrees для розробки з кількома агентами. У такому випадку кожне робоче дерево отримує node_modules, майже без накладних витрат, оскільки весь реальний вміст пакунка вже існує у спільному сховищі.

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

Обмеження​

  • Середовища неперервної інтеграції: У середовищах неперервної інтеграції кеші зазвичай відсутні, тому немає готового глобального сховища, яким можна було б скористатися. Глобальне віртуальне сховище, як правило, не використовується в CI.
  • Підняття ESM: pnpm використовує змінну середовища NODE_PATH для підтримки піднятих залежностей з глобальним віртуальним сховищем. Однак, Node.js не використовує NODE_PATH для імпорту ESM. Якщо залежності ESM намагаються імпортувати пакунки, які не вказані у їхньому власному файлі package.json, то розвʼязання залежностей завершиться невдачею. Цю проблему можна обійти за допомогою packageExtensions або конфігураційної залежності @pnpm/plugin-esm-node-path.
нотатка

Наразі глобальне віртуальне сховище зазвичай вимкнено для встановлень проєктів і позначено як експериментальне, оскільки деякі інструменти можуть працювати некоректно з текою node_modules, до якої створено символічне посилання. Щоб використовувати цю функцію під час встановлення проєктів, потрібно явно вказати enableGlobalVirtualStore: true у файлі pnpm-workspace.yaml. У pnpm v11 глобальне віртуальне сховище зазвичай увімкнено для пакунків, встановлених за допомогою pnpm dlx (pnpx), а також для пакунків, встановлених глобально. Мета полягає в тому, щоб у майбутній версії зробити це стандартним налаштуванням для всіх встановлень.

Глобальні пакунки​

У pnpm v11 глобальні встановлення (pnpm add -g) та pnpm dlx стандартно використовують глобальне віртуальне сховище. Дивіться Глобальні пакунки, щоб ознайомитися з повним посібником щодо роботи системи управління глобальними пакунками у версії 11, зокрема щодо ізольованих інсталяцій та нового розташування бінарних файлів.

Налаштування​

Детальну інформацію про налаштування дивіться у довідці параметра enableGlobalVirtualStore.