Параметри збирання

ignoreScripts#

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

Не виконувати будь-які скрипти, визначені в package.json проєкту та його залежностях.

нотатка

Цей прапорець не перешкоджає виконанню .pnpmfile.mjs

childConcurrency#

  • Стандартно: 5
  • Тип: Number

Максимальна кількість дочірніх процесів, які можна одночасно виділити для збірки node_modules.

sideEffectsCache#

  • Стандартно: true
  • Type: Boolean or Object

Використовувати та кешувати результати хуків (пре/пост)встановлення.

Коли скрипти (пре/пост)встановлення змінюють вміст пакунка (наприклад, вивід даних збірки), pnpm зберігає змінений пакунок у глобальному сховищі. On future installs on the same machine, pnpm reuses this cached, prebuilt version, which makes installs faster.

нотатка

Можливо, ви захочете вимкнути цей параметр, якщо:

  1. Скрипти встановлення змінюють файли поза текою пакунків (pnpm не може відстежувати або кешувати ці зміни).
  2. Скрипти виконують побічні ефекти, не повʼязані зі збіркою пакунка.

An object says the same thing in more detail, and is the canonical way to declare the remote tier:

pnpm-workspace.yaml
sideEffectsCache:
  read: true
  write: true
  remote:
    org: acme
    packages:
      - native-addon
  • read: restore a build from the cache when one is present. Default true.
  • write: save a package's build output to the cache. Default true.
  • remote: reuse builds across machines; see below.

sideEffectsCache: true is the shorthand for reading and writing, and is what the setting meant before it grew a remote tier. Writing without reading (read: false, write: true) populates a cache the run never consumes, which is what a job that warms one for others wants.

Since v11.26.0, the --side-effects-cache and --no-side-effects-cache flags, and PNPM_CONFIG_SIDE_EFFECTS_CACHE, toggle the local cache only. A remote tier declared under sideEffectsCache.remote is left in place, so a run can turn the local cache off without losing the shared one.

sideEffectsCacheReadonly#

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

Використовувати кеш побічних ефектів лише за наявності, не створювати його для нових пакунків. The older spelling of sideEffectsCache: { read: true, write: false }.

sideEffectsCache.remote#

Added in: v11.25.0

  • Стандартно: undefined
  • Type: Object

Opt in to reusing a dependency's build output across machines, by restoring signed, organization-scoped artifacts through a pnpr server instead of running the package's lifecycle scripts locally. This is a proof of concept: it is off unless configured, it needs a pnpr server started with artifacts.enabled: true, and it restores artifacts on Linux/glibc, macOS, and Windows, on x64 and arm64. Other operating systems and libc families build locally.

A repository declares eligibility and nothing else:

pnpm-workspace.yaml
pnprServer: http://127.0.0.1:7677
allowBuilds:
  native-addon: true
sideEffectsCache:
  remote:
    org: acme
    packages:
      - native-addon

Declaring only remote leaves read and write at their defaults, so the local cache keeps working as it did.

packages is an eligibility list, not a permission: a package is only a candidate when it also passes allowBuilds, has requiresBuild: true, and has a verified source integrity. Listing a package here does not review its build scripts for you. Under the default strictDepBuilds an install still fails with ERR_PNPM_IGNORED_BUILDS when it reaches a build nobody has ruled on, and a package denied with allowBuilds: false is never built, from the cache or otherwise.

Everything describing the act of signing (publish, keyId, builderId, imageDigest, architectureBaseline, buildEnv, trustedKeys and privateKey) is refused in pnpm-workspace.yaml with ERR_PNPM_WORKSPACE_REMOTE_SIDE_EFFECTS_TRUST, and is read from the global configuration file or the environment instead. A cloned repository is not a trust root, and must not be able to turn the machine's signing key into a signing oracle.

Any cache failure (an unreachable server, an unverifiable signature, an incompatible platform, a bad blob) falls back to the ordinary local build. See Shared side-effects cache for the full setup, including the server flag, the trust material, and how an artifact is published.

Since v11.25.0, a restored artifact is saved in the shared store together with its signed origin. Before a later install reuses it, pnpm checks the signature again against the machine's current keys and revalidates its owner, package and source identity, platform, policy, and stored files. A bad remote variant is quarantined for that pnpr server and is not selected again.

нотатка

remoteSideEffectsCache is the older spelling of this setting, and organization of its org field; both still work.

The two spellings are merged, not chosen between: a field set under both takes its value from sideEffectsCache.remote, and a field set under only one is kept either way. That is what lets a repository declare the org in pnpm-workspace.yaml while the machine supplies the signing key from the global config under whichever spelling it already used.

unsafePerm#

  • Стандартно: false, ЯКЩО запуск від імені користувача root, ІНАКШЕ — true
  • Тип: Boolean

When set to false, lifecycle scripts run with TMPDIR set to the package's node_modules/.tmp directory.

nodeOptions#

  • Стандартно: NULL
  • Типи: String

Параметри для передачі в Node.js через змінну оточення NODE_OPTIONS. Це не впливає на те, як виконується сам pnpm, але впливає на те, як викликаються сценарії життєвого циклу.

Щоб зберегти наявні NODE_OPTIONS, ви можете звернутися до поточної змінної оточення за допомогою ${NODE_OPTIONS} у вашій конфігурації:

pnpm-workspace.yaml
nodeOptions: "${NODE_OPTIONS:- } --experimental-vm-modules"

verifyDepsBeforeRun#

  • Стандартно: install
  • Тип: install, warn, error, prompt, false

Цей параметр дозволяє перевіряти стан залежностей перед запуском сценаріїв. Перевірка виконується для команд pnpm run і pnpm exec. Підтримуються наступні значення:

  • install — Автоматично запускає встановлення, якщо node_modules не оновлено. If that install fails, for example because the store is read-only or there is no network, pnpm prints a warning and runs the command anyway.
  • warn — Виводить попередження, якщо вміст node_modules не є актуальним.
  • prompt — Запитує у користувача дозвіл на запуск встановлення, якщо node_modules не оновлено.
  • error — Викликає помилку, якщо node_modules не є актуальним.
  • false — Вимикає перевірку залежностей.

strictDepBuilds#

Додано у: v10.3.0

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

Якщо увімкнено strictDepBuilds , інсталяція завершуватиметься з ненульовим кодом завершення, якщо будь-які залежності мають нерецензовані скрипти збірки (так звані післяінсталяційні скрипти).

allowBuilds#

Додано у: v10.26.0

Набір відповідників пакунків, які явно дозволяють (true) або забороняють (false) виконання скриптів.

pnpm-workspace.yaml
allowBuilds:
  esbuild: true
  core-js: false
  # nx versions with build scripts not listed below will
  # fail by default with ERR_PNPM_IGNORED_BUILDS
  nx@21.6.4 || 21.6.5: true
  nx@21.6.0: false

Git-hosted packages: a package name on its own never approves builds for a git or tarball dependency, because the name alone does not identify the artifact. Approve one either by its exact resolved path (including the commit) or, since v11.11.0, by its repository URL:

pnpm-workspace.yaml
allowBuilds:
  # Approves any commit from this repository
  'foo@git+ssh://git@example.com/org/foo.git': true
  # Approves only this exact commit
  'bar@git+https://github.com/org/bar.git#abc123': true

The repository form lets a trusted git dependency keep running its build scripts across branch updates without re-approving each new commit. The key is the package name, followed by @ and the git URL, with no #<ref> suffix. Matching is exact, so git+ssh:// and git+https:// URLs for the same repository are separate keys.

Since v11.19.0, the repository form also approves git-hosted packages that pnpm downloads as a tarball rather than clones, such as github: dependencies, which are fetched from codeload.github.com. A foo@git+https://github.com/org/foo.git entry approves foo whether pnpm clones the repository or downloads a tarball. GitLab and Bitbucket tarball downloads are matched the same way. Approving or denying a specific resolved commit by its full tarball dep path continues to work.

Denials by package name are not restricted this way: foo: false blocks foo whether it comes from the registry or from git.

Default behavior: Packages not listed in allowBuilds are disallowed by default and are treated as unreviewed. By default, an error is printed (strictDepBuilds defaults to true). Якщо для параметра strictDepBuilds встановлено значення false, замість цього виводиться попередження.

During install, dependencies with ignored builds that are not yet listed in allowBuilds are automatically added to pnpm-workspace.yaml with a placeholder value, so you can manually set them to true or false. The --allow-build flag on pnpm add and pnpm approve-builds writes its entries here as well.

Migrating from older settings

To migrate these settings automatically, run pnpx codemod run pnpm-v10-to-v11 from the Migrating from v10 to v11 guide.

The following settings have been removed in v11 and replaced by allowBuilds: onlyBuiltDependencies, onlyBuiltDependenciesFile, neverBuiltDependencies, ignoredBuiltDependencies, and ignoreDepScripts.

До:

pnpm-workspace.yaml
onlyBuiltDependencies:
  - electron
neverBuiltDependencies:
  - core-js
ignoredBuiltDependencies:
  - esbuild

Після:

pnpm-workspace.yaml
allowBuilds:
  electron: true
  core-js: false
  esbuild: false

dangerouslyAllowAllBuilds#

Додано у: v10.9.0

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

Якщо встановлено значення true, усі скрипти збірки (наприклад, preinstall, install, postinstall) з залежностей будуть виконуватися автоматично, без необхідності схвалення.

попередження

This setting allows all dependencies, including transitive ones, to run install scripts, both now and in the future. Навіть якщо ваш поточний граф залежності здається безпечним:

  • У майбутніх оновленнях можуть зʼявитися нові ненадійні залежності.
  • До наявних пакунків можуть бути додані скрипти у пізніших версіях.
  • Пакунки можуть бути перехоплені або скомпрометовані і почати виконувати шкідливий код.

For maximum safety, only enable this if you're fully aware of the risks and trust the entire ecosystem you're pulling from. It's recommended to review and allow builds explicitly.