Store & Lockfile Settings

Налаштування сховища

storeDir

• Стандартно:
  • Якщо встановлено змінну середовища $PNPM_HOME, тоді $PNPM_HOME/store
  • Якщо встановлено змінну середовища $XDG_DATA_HOME, тоді $XDG_DATA_HOME/pnpm/store
  • У Windows: ~/AppData/Local/pnpm/store
  • В macOS: ~/Library/pnpm/store
  • У Linux: ~/.local/share/pnpm/store
• Тип: path

Місце, де зберігаються всі пакунки на диску.

Сховище завжди має бути на тому самому диску, на якому відбувається встановлення, тому на кожному диску буде одне сховище. Якщо на поточному диску є домашня тека, то сховище створюється всередині неї. Якщо на диску немає домашньої теки, то сховище створюється у корені файлової системи. Наприклад, якщо встановлення відбувається у файлову систему, змонтовану за адресою /mnt, то сховище буде створено за адресою /mnt/.pnpm-store. Те ж саме стосується і систем Windows.

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

important

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

verifyStoreIntegrity

• Стандартно: true
• Тип: Boolean

Стандартно, якщо файл у сховищі було змінено, вміст цього файлу перевіряється перед звʼязуванням його з node_modules проєкту. Якщо verifyStoreIntegrity встановлено у false, файли у сховищі з адресованим вмістом не буде перевірено під час встановлення.

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

useRunningStoreServer

небезпека

Застаріла функція

• Стандартно: false
• Тип: Boolean

Дозволяє встановлення лише з сервером сховища. Якщо жоден сервер сховища не запущено, інсталяція завершиться невдало.

strictStorePkgContentCheck

• Стандартно: true
• Тип: Boolean

Деякі реєстри дозволяють публікувати один і той самий контент з різними назвами пакунків та/або версіями. Це порушує перевірку дійсності пакунків у сховищі. Щоб уникнути помилок при перевірці назв і версій таких пакунків у сховищі, ви можете встановити параметр strictStorePkgContentCheck у значення false.

frozenStore

Added in: v11.7.0

• Стандартно: false
• Тип: Boolean

Lets pnpm install run against a package store that lives on a read-only filesystem — for example a Nix store, a read-only bind mount, or an OCI image layer. When enabled, pnpm opens the store's SQLite index.db in immutable mode (bypassing the WAL/-shm sidecar files that otherwise can't be created on a read-only directory) and suppresses every code path that would write to the store.

Pair it with --offline and --frozen-lockfile against a fully-populated store:

pnpm install --frozen-store --offline --frozen-lockfile

The store must already contain everything the install needs, including the build output of any package whose lifecycle scripts are approved (or that has a patch applied). Under the global virtual store, those package directories live inside the store, so if a required build is missing the install fails up front with ERR_PNPM_FROZEN_STORE_NEEDS_BUILD — seed the store with those builds first. If the store is missing its content directory entirely, the install fails fast with ERR_PNPM_FROZEN_STORE_INCOMPLETE rather than trying to initialize it.

frozenStore is incompatible with --force and with a configured pnpr server, since both write into the store. The side effects cache is not written either.

нотатка

The read-only store open requires Node.js >=22.15.0, >=23.11.0, or >=24.0.0. On older runtimes, --frozen-store fails with ERR_PNPM_FROZEN_STORE_UNSUPPORTED_NODE.

Параметри Lockfile

lockfile

• Стандартно: true
• Тип: Boolean

Якщо встановлено false, pnpm не читатиме та не створюватиме файл pnpm-lock.yaml.

preferFrozenLockfile

• Стандартно: true
• Тип: Boolean

Якщо встановлено значення true і наявний pnpm-lock.yaml задовольняє директиві залежностей package.json, виконується headless встановлення. Встановлення headless пропускає визначення всіх залежностей, оскільки йому не потрібно змінювати файл блокування.

lockfileIncludeTarballUrl

• Стандартно: false
• Тип: Boolean

Додайте повну URL-адресу tar-файлу пакунка до кожного запису у pnpm-lock.yaml.

gitBranchLockfile

• Стандартно: false
• Тип: Boolean

Якщо встановлено значення true, згенерований файл блокування після встановлення буде названо на основі поточної назви гілки, щоб повністю уникнути конфліктів при злитті. Наприклад, якщо поточна назва гілки feature-foo, то відповідна назва файлу блокування буде pnpm-lock.feature-foo.yaml замість pnpm-lock.yaml. Зазвичай використовується разом з аргументом командного рядка --merge-git-branch-lockfilesабо за допомогою параметраmergeGitBranchLockfilesBranchPatternу файліpnpm-workspace.yaml`.

mergeGitBranchLockfilesBranchPattern

• Стандартно: null
• Тип: Array або null

Ця конфігурація відповідає назві поточної гілки, щоб визначити, чи потрібно обʼєднувати всі файли lockfile гілки git. Стандартно вам потрібно вручну передати параметр командного рядка --merge-git-branch-lockfiles. Ця конфігурація дозволяє автоматично завершити цей процес.

Наприклад:

mergeGitBranchLockfilesBranchPattern:
- main
- release*

Ви також можете виключити шаблони за допомогою !.

peersSuffixMaxLength

• Стандартно: 1000
• Тип: number

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