Store & Lockfile Settings

Store 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 копіюватиме пакунки зі сховища, а не звʼязуватиме їх жорсткими посиланнями, оскільки жорсткі посилання можливі лише у тій самій файловій системі.

If no directory above the project accepts a hard link at all (an agent sandbox that grants write access only to the project, or a container with just the project bind-mounted writable), the store is created at .pnpm-store inside the project. Putting it in the home directory there would either fail on a read-only home or land on another volume, which copies every package instead of hard-linking it (#13525).

verifyStoreIntegrity#

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

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

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

strictStorePkgContentCheck#

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

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

frozenStore#

Додано у: 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.

Ordinary installs can run in parallel and populate the same store on a local filesystem on the same machine. Leave frozenStore disabled for that use case.

With frozenStore enabled, no other process may modify the store during the install. Immutable reads bypass SQLite locking and can report "database disk image is malformed" if another job changes the database. This restriction does not apply to --frozen-lockfile, which still allows writes 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.

Lockfile settings#

lockfile#

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

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

frozenLockfile#

• Стандартно:
  • Для не-CI: false
  • Для CI: true, якщо присутній файл блокування
• Тип: Boolean

When set to true, pnpm fails the installation if the lockfile needs updating or is missing.

In CI environments, this setting defaults to true when a lockfile is present.

preferFrozenLockfile#

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

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

lockfileIncludeTarballUrl#

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

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

gitBranchLockfile#

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

When set to true, the generated lockfile name after installation will be named based on the current branch name to completely avoid merge conflicts. Наприклад, якщо поточна назва гілки feature-foo, то відповідна назва файлу блокування буде pnpm-lock.feature-foo.yaml замість pnpm-lock.yaml. It is typically used in conjunction with the command line argument --merge-git-branch-lockfilesor by settingmergeGitBranchLockfilesBranchPatternin thepnpm-workspace.yaml` file.

mergeGitBranchLockfilesBranchPattern#

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

This configuration matches the current branch name to determine whether to merge all git branch lockfile files. By default, you need to manually pass the --merge-git-branch-lockfiles command line parameter. This configuration allows this process to be automatically completed.

Наприклад:

mergeGitBranchLockfilesBranchPattern:
- main
- release*

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

peersSuffixMaxLength#

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

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