Версія: 10.x

Налаштування (pnpm-workspace.yaml)

pnpm отримує свою конфігурацію з командного рядка, змінних оточення, файлівpnpm-workspace.yaml та .npmrc.

Команду pnpm config можна використовувати для читання та редагування вмісту файлів проєкту та файлів глобальної конфігурації.

Відповідні конфігураційні файли:

Конфігураційний файл для кожного проєкту: /path/to/my/project/pnpm-workspace.yaml
Глобальний файл конфігурації: ~/.config/pnpm/rc ([INI-форматований] список параметрів key = value)

нотатка

Параметри, пов’язані з авторизацією, обробляються системою конфігурації npm. Отже, pnpm config set registry=<value> фактично збереже параметр у глобальний файл конфігурації npm.

Значення у файлах конфігурації можуть містити змінні env із використанням синтаксису ${NAME}. Змінні env також можуть бути вказані зі стандартними значеннями. Використання ${NAME-fallback} поверне fallback, якщо NAME не задано. ${NAME:-fallback} поверне fallback, якщо NAME не задано або є порожнім рядком.

Розвʼязання залежностей

overrides

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

Зверніть увагу, що поле перевизначень можна встановити лише у корені проєкту.

Приклад поля overrides:

overrides:
  "foo": "^1.0.0"
  "quux": "npm:@myorg/quux@^1.0.0"
  "bar@^2.1.0": "3.0.0"
  "qar@1>zoo": "2"

Ви можете вказати пакунок, до якого належить перевизначена залежність, відокремивши селектор пакунка від селектора залежності символом ">", наприклад, qar@1>zoo перевизначить лише залежність zoo пакунка qar@1, а не будь-які інші залежності.

Перевизначення можна визначити як посилання на специфікацію прямої залежності. Це досягається шляхом додавання до імені залежності префікса $:

package.json
{
  "dependencies": {
    "foo": "^1.0.0"
  }
}

pnpm-workspace.yaml
overrides:
  foo: "$foo"

Пакунок, на який посилаються, не обовʼязково повинен збігатися з пакунком, на який посилається перевизначений:

pnpm-workspace.yaml
overrides:
  bar: "$foo"

Якщо ви вважаєте, що використання певного пакунка не потребує однієї з його залежностей, ви можете використовувати -, щоб вилучити її. Наприклад, якщо пакунок foo@1.0.0 потребує великого пакунка з назвою bar для функції, яку ви не використовуєте, вилучення цього пакунка може скоротити час встановлення:

overrides:
  "foo@1.0.0>bar": "-"

Ця можливість особливо корисна для optionalDependencies, де більшість необовʼязкових пакунків можна безпечно пропустити.

packageExtensions

Поля packageExtensions надають можливість розширити наявні визначення пакунків додатковою інформацією. Наприклад, якщо react-redux повинен мати react-dom у своїх peerDependencies, але не має, можна виправити react-redux за допомогою packageExtensions:

packageExtensions:
  react-redux:
    peerDependencies:
      react-dom: "*"

Ключами у packageExtensions є назви пакунків або назви пакунків і діапазони semver, тому можна виправити лише деякі версії пакунків:

packageExtensions:
  react-redux@1:
    peerDependencies:
      react-dom: "*"

Наступні поля можна розширити за допомогою packageExtensions: dependencies, optionalDependencies, peerDependencies і peerDependenciesMeta.

Більший приклад:

packageExtensions:
  express@1:
    optionalDependencies:
      typescript: "2"
  fork-ts-checker-webpack-plugin:
    dependencies:
      "@babel/core": "1"
    peerDependencies:
      eslint: ">= 6"
    peerDependenciesMeta:
      eslint: {
        optional: true

підказка

Разом з Yarn ми підтримуємо базу даних packageExtensions для виправлення несправних пакунків в екосистемі. Якщо ви використовуєте packageExtensions, подумайте про те, щоб надіслати PR і внести ваше розширення до бази даних @yarnpkg/extensions.

allowedDeprecatedVersions

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

Приклад:

allowedDeprecatedVersions:
  express: "1"
  request: "*"

У наведеній вище конфігурації pnpm не виводитиме попередження про застарілість для будь-якої версії request і для v1 express.

updateConfig

updateConfig.ignoreDependencies

Іноді ви не можете оновити залежність. Наприклад, остання версія залежності почала використовувати ESM, але ваш проєкт ще не в ESM. На жаль, такий пакунок завжди буде виведено командою pnpm outdated і оновлено при виконанні pnpm update --latest. Втім, ви можете перелічити пакунки, які не потрібно оновлювати, у полі ignoreDependencies:

updateConfig:
  ignoreDependencies:
  - load-json-file

Також підтримуються шаблони, тому ви можете ігнорувати будь-які пакунки з області видимості: @babel/*.

supportedArchitectures

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

Наприклад, у наведеній нижче конфігурації вказано встановити необовʼязкові залежності для Windows x64:

supportedArchitectures:
  os:
  - win32
  cpu:
  - x64

Тоді як ця конфігурація встановить необовʼязкові залежності для Windows, macOS та архітектури системи, на якій наразі виконується встановлення. Вона включає артефакти як для x64, так і для arm64 процесорів:

supportedArchitectures:
  os:
  - win32
  - darwin
  - current
  cpu:
  - x64
  - arm64

Крім того, supportedArchitectures також підтримує вказівку libc системи.

ignoredOptionalDependencies

Якщо необовʼязкова залежність має імʼя у цьому масиві, її буде пропущено. Наприклад:

ignoredOptionalDependencies:
- fsevents
- "@esbuild/*"

Налаштування підйому залежностей

hoist

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

Коли true, всі залежності підіймаються до node_modules/.pnpm/node_modules. Це робить не перелічені залежності доступними для всіх пакунків всередині node_modules.

hoistWorkspacePackages

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

Коли true, пакунки з робочих просторів буде звʼязано або з <workspace_root>/node_modules/.pnpm/node_modules, або з <workspace_root>/node_modules, залежно від інших параметрів підйому (hoistPattern та publicHoistPattern).

hoistPattern

Стандартно: ['*']
Тип: string[]

Вказує pnpm, які пакунки слід підняти до node_modules/.pnpm/node_modules. Стандартно, всі пакунки буде піднято — однак, якщо ви знаєте, що лише деякі пакунки мають фантомні залежності, ви можете скористатися цим параметром, щоб підняти лише фантомні залежності (рекомендується).

Наприклад:

hoistPattern:
- "*eslint*"
- "*babel*"

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

Наприклад:

hoistPattern:
- "*types*"
- "!@types/react"

publicHoistPattern

Стандартно: []
Тип: string[]

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

Цей параметр корисний при роботі з деякими недосконалими інструментами, що підключаються, які не обробляють залежності належним чином.

Наприклад:

publicHoistPattern:
- "*plugin*"

Зауваження: Встановлення shamefullyHoist у true аналогічно встановленню publicHoistPattern у *.

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

Наприклад:

publicHoistPattern:
- "*types*"
- "!@types/react"

shamefullyHoist

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

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

Параметри модулів

modulesDir

Стандартно: node_modules
Тип: path

Тека, до якої буде встановлено залежності (замість node_modules).

nodeLinker

Стандартно: isolated
Тип: isolated, hoisted, pnp

Визначає, який компонувальник слід використовувати для встановлення пакунків Node.

isolated — залежності компонуються з віртуального сховища за адресою node_modules/.pnpm.
hoisted — створюється плаский node_modules без символічних посилань. Так само як і node_modules, створені за допомогою npm або Yarn Classic. При використанні цього параметра для підйому використовується одна з бібліотек Yarn. Законні причини для використання цього налаштування:
1. Ваші інструменти погано працюють із символічними посиланнями. Проєкт на React Native, швидше за все, буде працювати тільки в тому випадку, якщо ви використовуєте піднятий node_modules.
2. Ваш проєкт буде розгорнуто на безсерверний хостинг. Деякі безсерверні провайдери (наприклад, AWS Lambda) не підтримують symlinks. Альтернативним розвʼязання цієї проблеми є пакування програми перед розгортанням.
3. Якщо ви хочете опублікувати свій пакунок за допомогою "bundledDependencies".
4. Якщо ви використовуєте Node.js із прапорцем --preserve-symlinks.
pnp — без node_modules. Plug'n'Play — це інноваційна стратегія для Node, яка використовується Yarn Berry. Рекомендується також встановити параметр symlink у значення false, якщо ви використовуєте pnp як ваш компонувальник.

символічне посилання

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

Коли symlink встановлено у false, pnpm створює віртуальну теку сховища без жодних символьних посилань. Це корисний параметр разом з nodeLinker=pnp.

enableModulesDir

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

Якщо false, pnpm не записуватиме жодних файлів до теки модулів (node_modules). Це корисно, коли теку модулів змонтовано з файловою системою у просторі користувача (FUSE). Існує експериментальна версія CLI, яка дозволяє змонтувати теку модулів за допомогою FUSE: @pnpm/mount-modules.

virtualStoreDir

Стандартно: node_modules/.pnpm
Тип: path

Тека з посиланнями на сховище. Всі прямі та непрямі залежності проєкту повʼязані з цією текою.

Це корисний параметр, який може усунути проблеми з довгими шляхами у Windows. Якщо у вас є залежності з дуже довгими шляхами, ви можете вибрати віртуальне сховище у корені диска (наприклад, C:\my-project-store).

Або ви можете встановити віртуальне сховище у .pnpm і додати його до .gitignore. Це зробить трасування стеку чистішим, оскільки шляхи до залежностей будуть на одну теку вище.

ПРИМІТКА: віртуальне сховище не може бути спільним для декількох проєктів. Кожен проєкт повинен мати власне віртуальне сховище (за винятком робочих просторів, де корінь є спільним).

virtualStoreDirMaxLength

Стандартно:
- У Linux/macOS: 120
- У Windows: 60
Тип: number

Встановлює максимально допустиму довжину назв тек всередині теки віртуального сховища (node_modules/.pnpm). Ви можете встановити менше значення, якщо у вас виникають проблеми з довгими шляхами у Windows.

packageImportMethod

Стандартно: auto
Тип: auto, hardlink, copy, clone, clone-or-copy

Керує способом імпорту пакунків зі сховища (якщо ви хочете вимкнути symlinks всередині node_modules, то вам потрібно змінити параметр nodeLinker, а не цей).

auto — спробувати клонувати пакунки зі сховища. Якщо клонування не підтримується, встановіть жорстке посилання на пакунки зі сховища. Якщо ані клонування, ані звʼязування неможливі, поверніться до копіювання
hardlink — жорстке посилання на пакунки зі сховища
clone-or-copy — спробувати клонувати пакунки зі сховища. Якщо клонування не підтримується, поверніться до копіювання
copy — скопіювати пакунки зі сховища
clone —клонувати (те ж що й copy-on-write або посилатись за посиланням) пакунки зі сховища

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

На жаль, не всі файлові системи підтримують клонування. Ми рекомендуємо використовувати файлову систему з копіюванням при записі (CoW) (наприклад, Btrfs замість Ext4 в Linux) для найкращого досвіду роботи з pnpm.

modulesCacheMaxAge

Стандартно: 10080 (7 днів в хвилинах)
Тип: number

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

dlxCacheMaxAge

Стандартно: 1440 (1 день в хвилинах)
Тип: number

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

enableGlobalVirtualStore

Додано у: v10.12.1

Стандартно: false (завжди false в CI)
Тип: Boolean
Статус: Experimental

Якщо увімкнено, node_modules містить лише символьні посилання на центральне віртуальне сховище, а не на node_modules/.pnpm. Стандартно, це центральне сховище розташовано за адресою <store-path>/links (використовуйте pnpm store path, щоб знайти <store-path>).

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

Це не слід плутати з глобальним сховищем адресованого вмісту. Фактичні файли пакунків, як і раніше, жорстко повʼязані зі сховищем, що адресується за вмістом, але замість того, щоб бути повʼязаними безпосередньо з node_modules/.pnpm, вони повʼязані з глобальним віртуальним сховищем.

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

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

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

verifyStoreIntegrity

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

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

useRunningStoreServer

небезпека

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

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

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

strictStorePkgContentCheck

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

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

Параметри 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

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

Реєстр та параметри автентифікації

registry

Стандартно: https://registry.npmjs.org/
Тип: url

Базова URL-адреса реєстру пакунків npm (включно з кінцевою косою рискою).

<scope>:registry

Реєстр npm, який слід використовувати для пакунків вказаної області доступу. Наприклад, встановлення @babel:registry=https://example.com/packages/npm/ призведе до того, що при використанні pnpm add @babel/core або будь-якого пакунка з діапазоном @babel, пакунок буде отримано з https://example.com/packages/npm, а не зі стандартного реєстру.

<URL>:_authToken

Визначає токен автентифікації на предʼявника, який буде використовуватися при доступі до вказаного реєстру. Наприклад:

//registry.npmjs.org/:_authToken=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Ви також можете використовувати змінну оточення. Наприклад:

//registry.npmjs.org/:_authToken=${NPM_TOKEN}

Або ви можете використовувати змінну оточення безпосередньо, не змінюючи .npmrc взагалі:

npm_config_//registry.npmjs.org/:_authToken=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

<URL>:tokenHelper

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

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

Встановлення помічника токенів для стандартного реєстру:

tokenHelper=/home/ivan/token-generator

Встановлення помічника токена для вказаного реєстру:

//registry.corp.com:tokenHelper=/home/ivan/token-generator

Налаштування запиту

ca

Стандартно: Сертифікат npm CA
Тип: Array або null

Сертифікат підпису центру сертифікації, якому довіряють для SSL-зʼєднань з реєстром. Значення повинні бути у форматі PEM (також відомий як «Base-64 кодований X.509 (.CER)»). Наприклад:

ca="-----BEGIN CERTIFICATE-----\nXXXX\nXXXX\n-----END CERTIFICATE-----"

Встановіть значення null, щоб дозволити довіряти лише відомим реєстраторам, або певному сертифікату ЦС, щоб довіряти лише цьому конкретному центру сертифікації підписів.

Можна довіряти декільком центрам сертифікації, вказавши масив сертифікатів:

ca[]="..."
ca[]="..."

Дивіться також конфігурацію strict-ssl.

cafile

Стандартно: null
Тип: path

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

<URL>:cafile

Визначає шлях до файлу центру сертифікації, який буде використовуватися при доступі до вказаного реєстру. Наприклад:

//registry.npmjs.org/:cafile=ca-cert.pem

cert

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

Клієнтський сертифікат, який потрібно передати при доступі до реєстру. Значення повинні бути у форматі PEM (також відомий як «Base-64 кодований X.509 (.CER)»). Наприклад:

cert="-----BEGIN CERTIFICATE-----\nXXXX\nXXXX\n-----END CERTIFICATE-----"

Це не шлях до файлу сертифіката.

<URL>:certfile

Визначає шлях до файлу сертифіката, який буде використовуватися при доступі до вказаного реєстру. Наприклад:

//registry.npmjs.org/:certfile=server-cert.pem

key

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

Ключ клієнта, який потрібно передати при доступі до реєстру. Значення повинні бути у форматі PEM (також відомий як «Base-64 кодований X.509 (.CER)»). Наприклад:

key="-----BEGIN PRIVATE KEY-----\nXXXX\nXXXX\n-----END PRIVATE KEY-----"

Це не шлях до файлу ключа (і немає параметра keyfile).

Цей параметр містить конфіденційну інформацію. Не записуйте його до локального файлу .npmrc, зафіксованого у репозиторії.

<URL>:keyfile

Визначає шлях до файлу клієнтського ключа, який буде використовуватися при доступі до вказаного реєстру. Наприклад:

//registry.npmjs.org/:keyfile=server-key.pem

gitShallowHosts

Стандартно: ['github.com', 'gist.github.com', 'gitlab.com', 'bitbucket.com', 'bitbucket.org']
Тип: string[]

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

https-proxy

Стандартно: null
Тип: url

Проксі-сервер для вихідних HTTPS-запитів. Якщо встановлено змінні оточення HTTPS_PROXY, https_proxy, HTTP_PROXY або http_proxy, замість них буде використано їхні значення.

Якщо URL-адреса вашого проксі містить імʼя користувача та пароль, переконайтеся, що вони закодовані в URL. Наприклад:

https-proxy=https://use%21r:pas%2As@my.proxy:1234/foo

Не кодуйте двокрапку (:) між іменем користувача та паролем.

http-proxy

proxy

Стандартно: null
Тип: url

Проксі для вихідних http-запитів. Якщо встановлено змінні оточення HTTP_PROXY або http_proxy, налаштування проксі будуть враховані базовою бібліотекою запитів.

local-address

Стандартно: undefined
Тип: IP Address

IP-адреса локального інтерфейсу для підключення до реєстру npm.

maxsockets

Стандартно: networkConcurrency x 3
Тип: Number

Максимальна кількість зʼєднань, які можна використовувати для одного джерела (комбінація протокол/хост/порт).

noproxy

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

Розділений комами рядок розширень доменів, для яких не слід використовувати проксі-сервер.

strict-ssl

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

Чи потрібно робити перевірку SSL-ключів при запитах до реєстру через HTTPS.

Дивіться також параметр ca.

networkConcurrency

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

Контролює максимальну кількість запитів HTTP(S) для одночасної обробки.

fetchRetries

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

Скільки разів повторити спробу, якщо pnpm не вдається отримати дані з реєстру.

fetchRetryFactor

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

Експоненціальний коефіцієнт для повторної спроби.

fetchRetryMintimeout

Стандартно: 10000 (10 секунд)
Тип: Number

Мінімальний (базовий) тайм-аут для повторних запитів.

fetchRetryMaxtimeout

Стандартно: 60000 (1 хвилина)
Тип: Number

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

fetchTimeout

Стандартно: 60000 (1 хвилина)
Тип: Number

Максимальний час очікування виконання HTTP-запитів.

Параметри прямих залежностей

autoInstallPeers

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

Якщо true, всі відсутні необовʼязкові прямі залежності будуть автоматично встановлені.

Конфлікт версій

Якщо існують суперечливі вимоги до версій для прямої залежності з різних пакунків, pnpm не встановлюватиме автоматично жодну з версій суперечливої прямої залежності. Натомість виводиться попередження. Наприклад, якщо одна залежність вимагає react@^16.0.0, а інша — react@^17.0.0, ці вимоги конфліктують, і автоматичного встановлення не відбудеться.

Розвʼязання конфліктів

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

dedupePeerDependents

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

Якщо цей параметр встановлено у значення true, пакунки з прямими залежностями буде дедупліковано після розвʼязання прямих залежностей.

Наприклад, скажімо, у нас є робоча область з двома проєктами, і обидва з них мають webpack у своїх залежностях. webpack має esbuild у необовʼязкових прямих залежностях, а один з проєктів має esbuild у своїх залежностях. У цьому випадку pnpm зв'яже два екземпляри webpack з текою node_modules/.pnpm: один з esbuild, а інший без нього:

node_modules
  .pnpm
    webpack@1.0.0_esbuild@1.0.0
    webpack@1.0.0
project1
  node_modules
    webpack -> ../../node_modules/.pnpm/webpack@1.0.0/node_modules/webpack
project2
  node_modules
    webpack -> ../../node_modules/.pnpm/webpack@1.0.0_esbuild@1.0.0/node_modules/webpack
    esbuild

Це має сенс, оскільки webpack використовується у двох проєктах, і в одному з них немає esbuild, тому ці два проєкти не можуть використовувати один і той самий екземпляр webpack. Однак це не те, чого очікує більшість розробників, особливо з огляду на те, що у піднятому node_modules буде лише один екземпляр webpack. Отже, тепер ви можете використовувати параметр dedupePeerDependents для дедуплікації webpack, якщо він не має конфліктні прямі залежності (пояснення у кінці). У цьому випадку, якщо ми встановимо dedupePeerDependents у true, обидва проєкти використовуватимуть той самий екземпляр webpack, який має esbuild:

node_modules
  .pnpm
    webpack@1.0.0_esbuild@1.0.0
project1
  node_modules
    webpack -> ../../node_modules/.pnpm/webpack@1.0.0_esbuild@1.0.0/node_modules/webpack
project2
  node_modules
    webpack -> ../../node_modules/.pnpm/webpack@1.0.0_esbuild@1.0.0/node_modules/webpack
    esbuild

Що таке конфліктуючі прямі залежності? Під конфліктуючими одноранговими залежностями ми маємо на увазі сценарій, подібний до наведеного нижче:

node_modules
  .pnpm
    webpack@1.0.0_react@16.0.0_esbuild@1.0.0
    webpack@1.0.0_react@17.0.0
project1
  node_modules
    webpack -> ../../node_modules/.pnpm/webpack@1.0.0/node_modules/webpack
    react (v17)
project2
  node_modules
    webpack -> ../../node_modules/.pnpm/webpack@1.0.0_esbuild@1.0.0/node_modules/webpack
    esbuild
    react (v16)

У цьому випадку ми не можемо дедуплікувати webpack, оскільки webpack має react у своїх прямих залежностях, а react розвʼязується з двох різних версій у контексті двох проєктів.

strictPeerDependencies

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

Якщо цей параметр увімкнено, команди не будуть виконуватися, якщо у дереві відсутня або невірна залежність від прямої залежності.

resolvePeersFromWorkspaceRoot

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

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

peerDependencyRules

peerDependencyRules.ignoreMissing

pnpm не виводитиме попередження про відсутні у цьому списку прямі залежності.

Наприклад, у наступній конфігурації pnpm не виводитиме попередження, якщо залежність потребує react, але react не встановлено:

peerDependencyRules:
  ignoreMissing:
  - react

Також можна використовувати шаблони назв пакунків:

peerDependencyRules:
  ignoreMissing:
  - "@babel/*"
  - "@eslint/*"

peerDependencyRules.allowedVersions

Попередження про незадоволені залежності не буде виведено для залежностей із вказаного діапазону.

Наприклад, якщо у вас є залежності, які потребують react@16, але ви знаєте, що вони чудово працюють з react@17, то ви можете використовувати наступну конфігурацію:

peerDependencyRules:
  allowedVersions:
    react: "17"

Це скаже pnpm, що будь-яка залежність, яка має react у своїх прямих залежностях, повинна дозволити встановлення react v17.

Також можна вимкнути попередження лише для прямих залежностей певних пакунків. Наприклад, у наведеній нижче конфігурації react v17 буде дозволено лише тоді, коли він є в однорангових залежностях пакунка button v2 або в залежностях будь-якого пакунка card:

peerDependencyRules:
  allowedVersions:
    "button@2>react": "17",
    "card>react": "17"

peerDependencyRules.allowAny

allowAny — масив шаблонів назв пакунків, будь-яка пряма залежність, що відповідає шаблону, буде розвʼязана з будь-якої версії, незалежно від діапазону, вказаного у peerDependencies. Наприклад:

peerDependencyRules:
  allowAny:
  - "@babel/*"
  - "eslint"

Наведений вище параметр вимкне попередження про невідповідність версій залежностей, повʼязаних з пакунками @babel/ або eslint.

Параметри CLI

[no-]color

Стандартно: auto
Тип: auto, always, never

Керує кольорами у виводі.

auto — вивід використовує кольори, коли стандартним виводом є термінал або TTY.
always — ігнорувати різницю між терміналами та конвеєрами. У більшості сценаріїв, якщо вам потрібні кольорові коди у перенаправленому виводі, ви можете замість цього передати команді pnpm прапорець --color, щоб змусити її використовувати кольорові коди. Стандартні налаштування майже завжди відповідають вашим потребам.
never — вимикає кольори. Цей параметр використовується для --no-color.

loglevel

Стандартно: info
Тип: debug, info, warn, error

Будуть показані всі журнали вказаного рівня або вище. Замість цього ви можете передати --silent, щоб вимкнути всі журнали виводу.

useBetaCli

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

Експериментальна опція, яка дозволяє використовувати бета-функції CLI. Це означає, що ви можете отримати деякі зміни у функціоналі CLI, які є порушеннями або потенційними помилками.

recursiveInstall

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

Якщо цей параметр увімкнено, основною поведінкою pnpm install стане поведінка pnpm install -r, тобто встановлення буде виконано до всіх пакунків робочого простору або вкладених тек.

Інакше, pnpm install збиратиме пакунок виключно у поточній теці.

engineStrict

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

Якщо цей параметр увімкнено, pnpm не встановлюватиме пакунки, які стверджують, що вони несумісні з поточною версією Node.

Незалежно від цієї конфігурації, встановлення завжди завершиться невдачею, якщо проєкт (не залежність) вкаже несумісну версію у своєму полі engines.

npmPath

Тип: path

Розташування бінарного файлу npm, який pnpm використовує для деяких дій, таких як публікація.

packageManagerStrict

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

Якщо цей параметр вимкнено, pnpm не зазнає невдачі, якщо у полі packageManager файлу package.json вказано інший менеджер пакунків. Якщо увімкнено, перевіряється лише назва пакунка (починаючи з pnpm v9.2.0), тому ви можете запускати будь-яку версію pnpm, незалежно від версії, вказаної у полі packageManager.

Крім того, ви можете вимкнути цей параметр, встановивши змінну оточення COREPACK_ENABLE_STRICT у значення 0.

packageManagerStrictVersion

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

Якщо увімкнено, pnpm зазнає невдачі, якщо його версія не збігається з версією, вказаною у полі packageManager у файлі package.json.

managePackageManagerVersions

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

Якщо увімкнено, pnpm автоматично завантажить і запустить версію pnpm, вказану у полі packageManager файлу package.json. Це те саме поле, що використовується Corepack. Приклад:

{
  "packageManager": "pnpm@9.3.0"
}

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

ignoreScripts

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

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

нотатка

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

ignoreDepScripts

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

Не виконувати жодних скриптів встановлених пакунків. Скрипти проєктів виконуються.

нотатка

Починаючи з версії 10, pnpm не виконує сценарії життєвого циклу залежностей, якщо вони не вказані у onlyBuiltDependencies.

childConcurrency

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

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

sideEffectsCache

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

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

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

нотатка

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

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

sideEffectsCacheReadonly

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

Використовувати кеш побічних ефектів лише за наявності, не створювати його для нових пакунків.

unsafePerm

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

Встановіть значення true, щоб увімкнути перемикання UID/GID під час запуску скриптів пакунків. Якщо явно вказати значення false, то встановлення від імені не root-користувача не вдасться.

nodeOptions

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

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

verifyDepsBeforeRun

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

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

install — Автоматично запускає встановлення, якщо node_modules не оновлено.
warn — Виводить попередження, якщо вміст node_modules не є актуальним.
prompt — Запитує у користувача дозвіл на запуск встановлення, якщо node_modules не оновлено.
error — Викликає помилку, якщо node_modules не є актуальним.
false — Вимикає перевірку залежностей.

strictDepBuilds

Додано у: v10.3.0

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

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

neverBuiltDependencies

Це поле дозволяє ігнорувати збірки певних залежностей. Скрипти "preinstall", "install" і "postinstall" перелічених пакунків не буде виконано під час встановлення.

Приклад поля neverBuiltDependencies:

neverBuiltDependencies:
- fsevents
- level

onlyBuiltDependencies

Список назв пакунків, які дозволено виконувати під час встановлення. Лише пакунки, перелічені у цьому масиві, зможуть запускати сценарії встановлення. Якщо onlyBuiltDependenciesFile і neverBuiltDependencies не встановлено, цей параметр конфігурації стандартно блокуватиме всі сценарії встановлення.

Приклад:

onlyBuiltDependencies:
- fsevents

onlyBuiltDependenciesFile

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

Приклад:

configDependencies:
  '@pnpm/trusted-deps': 0.1.0+sha512-IERT0uXPBnSZGsCmoSuPzYNWhXWWnKkuc9q78KzLdmDWJhnrmvc7N4qaHJmaNKIusdCH2riO3iE34Osohj6n8w==
onlyBuiltDependenciesFile: node_modules/.pnpm-config/@pnpm/trusted-deps/allow.json

Сам JSON-файл повинен містити масив імен пакунків:

node_modules/.pnpm-config/@pnpm/trusted-deps/allow.json
[
  "@airbnb/node-memwatch",
  "@apollo/protobufjs",
  ...
]

ignoredBuiltDependencies

Додано у: v10.1.0

Список назв пакунків, які не слід збирати під час встановлення.

Приклад:

ignoredBuiltDependencies:
- fsevents

dangerouslyAllowAllBuilds

Додано у: v10.9.0

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

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

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

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

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

Для максимальної безпеки вмикайте цю функцію, тільки якщо ви повністю усвідомлюєте ризики і довіряєте всій екосистемі, з якої ви отримуєте дані. Рекомендується переглядати і дозволяти збірки явним чином.

Параметри Node.js

useNodeVersion

Стандартно: undefined
Тип: semver

Вказує, яку саме версію Node.js слід використовувати для виконання проєкту. pnpm автоматично встановить вказану версію Node.js і використовуватиме її для виконання команд pnpm run або команди pnpm node.

Його можна використовувати замість .nvmrc та nvm. Замість наступного файлу .nvmrc:

16.16.0

Використовуйте цей файл pnpm-workspace.yaml:

useNodeVersion: 16.16.0

Цей параметр працює лише у файлі pnpm-workspace.yaml, який знаходиться в корені вашої робочої області. Якщо вам потрібно вказати власний Node.js для проєкту в робочій області, використовуйте поле executionEnv.nodeVersion в package.json замість цього.

nodeVersion

Стандартно: значення, що повертається node -v, без префікса v
Тип: semver

Версія Node.js, яку слід використовувати при перевірці параметра engines пакунка.

Якщо ви хочете заборонити учасникам вашого проєкту додавати нові несумісні залежності, використовуйте nodeVersion та engineStrict у файлі pnpm-workspace.yaml у корені проєкту:

nodeVersion: 12.22.0
engineStrict: true

Таким чином, навіть якщо хтось використовує Node.js v16, він не зможе встановити нову залежність, яка не підтримує Node.js v12.22.0.

node-mirror

Стандартно: https://nodejs.org/download/<releaseDir>/
Тип: URL

Задає базову URL-адресу для завантаження Node.js. Частина <releaseDir> цього параметра може бути будь-якою текою з https://nodejs.org/download: release, rc, nightly, v8-canary тощо.

Ось як можна налаштувати pnpm для завантаження Node.js з дзеркала Node.js в Китаї:

node-mirror:release=https://npmmirror.com/mirrors/node/
node-mirror:rc=https://npmmirror.com/mirrors/node-rc/
node-mirror:nightly=https://npmmirror.com/mirrors/node-nightly/

executionEnv.nodeVersion

Наприклад:

executionEnv:
  nodeVersion: 16.16.0

Налаштування робочого простору

linkWorkspacePackages

Стандартно: false
Тип: true, false, deep

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

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

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

injectWorkspacePackages

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

Вмикає жорстке звʼязування всіх локальних залежностей робочого простору замість їхнього звʼязування у вигляді символічних посилань. Крім того, цього можна досягти за допомогою dependenciesMeta[].injected, що дозволяє вибірково вмикати жорстке зв’язування для певних залежностей.

syncInjectedDepsAfterScripts

Додано у: v10.5.0

Стандартно: undefined
Тип: String[]

Інʼєкції залежності робочого простору — це колекції жорстких посилань, які не додають і не видаляють файли при зміні їхніх джерел. Це спричиняє проблеми у пакунках, які потрібно зібрати (наприклад, у проєктах на TypeScript).

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

preferWorkspacePackages

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

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

Цей параметр корисний лише у тому випадку, якщо у робочому просторі не використовується saveWorkspaceProtocol .

sharedWorkspaceLockfile

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

Якщо цей параметр увімкнено, pnpm створить єдиний файл pnpm-lock.yaml у корені робочого простору. Це також означає, що всі залежності пакунків робочої області будуть знаходитися у єдиній теці node_modules (і будуть привʼязані до теки їх пакунків node_modules для розпізнавання модулів Node).

Переваги цього параметра:

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

нотатка

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

saveWorkspaceProtocol

Стандартно: rolling
Тип: true, false, rolling

Цей параметр керує тим, як залежності, приєднані з робочої області, додаються до package.json.

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

saveWorkspaceProtocol	savePrefix	spec
false	`''`	`1.0.0`
false	`'~'`	`~1.0.0`
false	`'^'`	`^1.0.0`
true	`''`	`workspace:1.0.0`
true	`'~'`	`workspace:~1.0.0`
true	`'^'`	`workspace:^1.0.0`
rolling	`''`	`workspace:*`
rolling	`'~'`	`workspace:~`
rolling	`'^'`	`workspace:^`

includeWorkspaceRoot

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

При рекурсивному виконанні команд у робочій області, виконуйте їх також у кореневому проєкті робочої області.

ignoreWorkspaceCycles

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

Якщо встановлено значення true, попередження про цикли робочої області не буде виведено.

disallowWorkspaceCycles

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

Якщо встановлено значення true, встановлення не вдасться, якщо у робочій області є цикли.

Налаштування розгортання

forceLegacyDeploy

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

Стандартно, pnpm deploy спробує створити спеціальний файл блокування зі спільного файлу блокування для розгортання. Якщо цей параметр встановлено у значення true, буде використано успадковану поведінку deploy.

Виправлення залежностей

patchedDependencies

Це поле буде додано/оновлено автоматично під час запуску pnpm patch-commit. Воно визначає патчі для залежностей за допомогою словника, де:

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

Приклад:

patchedDependencies:
  express@4.18.1: patches/express@4.18.1.patch

Dependencies можна виправляти за діапазоном версій. Порядок пріоритетності такий:

Точні версії (найвищий пріоритет)
Діапазони версій
Патчі лише для імен (застосовуються до всіх версій, якщо їх не замінено)

Окремий випадок: діапазон версій * поводиться як патч лише з назвою, але не ігнорує помилки патча.

Приклад:

patchedDependencies:
  foo: patches/foo-1.patch
  foo@^2.0.0: patches/foo-2.patch
  foo@2.1.0: patches/foo-3.patch

patches/foo-3.patch застосовується до foo@2.1.0.
patches/foo-2.patch застосовується до всіх версій foo, що відповідають ^2.0.0, крім 2.1.0.
patches/foo-1.patch застосовується до всіх інших версій foo.

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

Приклад:

patchedDependencies:
  # Specialized sub-range
  "foo@2.2.0-2.8.0": patches/foo.2.2.0-2.8.0.patch
  # General patch, excluding the sub-range above
  "foo@>=2.0.0 <2.2.0 || >2.8.0": patches/foo.gte2.patch

У більшості випадків достатньо визначити точну версію, щоб перевизначити ширший діапазон.

allowUnusedPatches

Додано у: v10.7.0 (Попередня назва allowNonAppliedPatches)

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

Якщо true, встановлення не завершиться невдачею, якщо деякі з виправлень з поля patchedDependencies не було застосовано.

patchedDependencies:
  express@4.18.1: patches/express@4.18.1.patch
allowUnusedPatches: true

ignorePatchFailures

Додано у: v10.7.0

Стандартно: undefined
Тип: Boolean, undefined

Керує обробкою збоїв у роботі з патчами.

Поведінка:

undefined (стандартно):
- Виводить помилки, коли не вдається встановити патч із точною версією або діапазоном версій.
- Ігнорує збої від патчів лише з іменами.
false: Виводить помилки для всіх невдалих виправлень.
true: Виводить попередження замість невдачі, якщо не вдається застосувати жодну латку.

Параметри аудиту

auditConfig

auditConfig.ignoreCves

Список ідентифікаторів CVE, які буде проігноровано командою pnpm audit.

auditConfig:
  ignoreCves:
    - CVE-2022-36313

auditConfig.ignoreGhsas

Список кодів GHSA, які буде проігноровано командою pnpm audit.

auditConfig:
  ignoreGhsas:
    - GHSA-42xw-2xvc-qx8m
    - GHSA-4w2v-q235-vp99
    - GHSA-cph5-m8f7-6c5x
    - GHSA-vh95-rmgr-6w4m

Інші налаштування

savePrefix

Стандартно: '^'
Тип: '^', '~', ''

Налаштуйте спосіб префіксації версій пакунків, встановлених до файлу package.json.

Наприклад, якщо пакунок має версію 1.2.3, стандартно його версію встановлено як ^1.2.3, що дозволяє незначні оновлення для цього пакунка, але після pnpm config set save-prefix='~' його буде встановлено як ~1.2.3, що дозволяє лише оновлення патчів.

Цей параметр ігнорується, якщо доданий пакунок має вказаний діапазон. Наприклад, pnpm add foo@2 встановить версію foo у package.json на 2, незалежно від значення savePrefix .

globalDir

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

Вкажіть власну теку для зберігання глобальних пакунків.

globalBinDir

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

Дозволяє задати цільову теку для bin-файлів глобально встановлених пакунків.

stateDir

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

Тека, у якій pnpm створює файл pnpm-state.json, який наразі використовується лише у програмі перевірки оновлень.

cacheDir

Стандартно:
- Якщо встановлено змінну середовища $XDG_CACHE_HOME, тоді $XDG_CACHE_HOME/pnpm
- У Windows: ~/AppData/Local/pnpm-cache
- В macOS: ~/Library/Caches/pnpm
- У Linux: ~/.cache/pnpm
Тип: path

Розташування кешу (метадані пакунків та dlx).

useStderr

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

Якщо значення true, весь вивід записується у stderr.

updateNotifier

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

Встановіть значення false, щоб приховати сповіщення про оновлення при використанні старішої версії pnpm, ніж остання.

preferSymlinkedExecutables

Стандартно: true, коли node-linker встановлено у hoisted і система є POSIX
Тип: Boolean

Створіть символічні посилання на виконувані файли у node_modules/.bin замість команд shims. Цей параметр ігнорується у Windows, де працюють лише командні shims.

ignoreCompatibilityDb

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

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

Виправлення застосовуються з пакунка Yarn @yarnpkg/extensions.

resolutionMode

Стандартно: highest (було lowest-direct з v8.0.0 до v8.6.12)
Тип: highest, time-based, lowest-direct

Коли resolutionMode встановлено у time-based, залежності буде розвʼязано у такий спосіб:

Прямі залежності будуть вирішені до найнижчих версій. Отже, якщо у залежностях є foo@^1.1.0, то буде встановлено 1.1.0.
Підзалежності будуть врегульовані, починаючи з версій, які були опубліковані до того, як була опублікована остання пряма залежність.

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

Цей режим працює лише з повними метаданими npm. Тому в деяких сценаріях це відбувається повільніше. Однак, якщо ви використовуєте Verdaccio v5.15.1 або новішу версію, ви можете встановити параметр registrySupportsTimeField у значення true, і він працюватиме дуже швидко.

Коли resolutionMode встановлено у lowest-direct, прямі залежності буде розвʼязано до їх найнижчих версій.

registrySupportsTimeField

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

Встановіть значення true, якщо реєстр, який ви використовуєте, повертає поле "time" у скорочених метаданих. Наразі цю функцію підтримує лише Verdaccio з версії 5.15.1.

extendNodePath

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

Якщо false, змінна оточення NODE_PATH не встановлюється у shims команди.

deployAllFiles

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

Під час розгортання пакунка або встановлення локального пакунка копіюються всі файли пакунка. Стандартно, якщо пакунок має поле "files" у package.json, то копіюються лише перелічені файли та теки.

dedupeDirectDeps

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

Якщо встановлено значення true, залежності, які вже привʼязано до кореневої теки node_modules робочої області, не буде привʼязано до теки node_modules вкладених проєктів.

dedupeInjectedDeps

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

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

optimisticRepeatInstall

Додано у: v10.1.0

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

Якщо увімкнено, буде виконано швидку перевірку перед початком інсталяції. Таким чином, повторне встановлення або встановлення в проєкті з усіма оновленнями стає набагато швидшим.

requiredScripts

Скрипти, перелічені у цьому масиві, будуть потрібні у кожному проєкті робочого простору. Інакше виконання pnpm -r run <script name> завершиться невдачею.

requiredScripts:
- build

enablePrePostScripts

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

Якщо true, pnpm автоматично виконуватиме будь-які пре/пост-скрипти. Отже, виконання pnpm foo буде подібне до виконання pnpm prefoo && pnpm foo && pnpm postfoo.

scriptShell

Стандартно: null
Тип: path

Оболонка для запуску скриптів за допомогою команди pnpm run.

Наприклад, щоб примусово використовувати Git Bash у Windows:

pnpm config set scriptShell "C:\\Program Files\\git\\bin\\bash.exe"

shellEmulator

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

Якщо true, pnpm використовуватиме JavaScript-реалізацію bash-подібної оболонки для виконання скриптів.

Цей параметр спрощує написання крос-платформних скриптів. Наприклад, стандартно наступний скрипт не працюватиме в системах, не сумісних з POSIX:

"scripts": {
  "test": "NODE_ENV=test node test.js"
}

Але якщо для параметра shellEmulator встановлено значення true, він працюватиме на всіх платформах.

catalogMode

Додано у: v10.12.1

Стандартно: manual
Тип: manual, strict, prefer

Керує тим, чи додаються залежності до стандартного каталогу при виконанні pnpm add, і якщо так, то як саме. Є три режими:

strict — дозволяє лише версії залежностей з каталогу. Додавання залежності за межами діапазону версій каталогу призведе до помилки.
prefer — надає перевагу версіям з каталогу, але повертається до прямих залежностей, якщо сумісну версію не знайдено.
manual (стандартно) — не додає автоматично залежності до каталогу.

ci

Додано у: v10.12.1

Стандартно: true (коли середовище визначається як CI)
Тип: Boolean

Цей параметр явно вказує pnpm, чи є поточне середовище середовищем CI (безперервної інтеграції).

Розвʼязання залежностей​

overrides​

packageExtensions​

allowedDeprecatedVersions​

updateConfig​

updateConfig.ignoreDependencies​

supportedArchitectures​

ignoredOptionalDependencies​

Налаштування підйому залежностей​

hoist​

hoistWorkspacePackages​

hoistPattern​

publicHoistPattern​

shamefullyHoist​

Параметри модулів​

modulesDir​

nodeLinker​

символічне посилання​

enableModulesDir​

virtualStoreDir​

virtualStoreDirMaxLength​

packageImportMethod​

modulesCacheMaxAge​

dlxCacheMaxAge​

enableGlobalVirtualStore​

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

storeDir​

verifyStoreIntegrity​

useRunningStoreServer​

strictStorePkgContentCheck​

Параметри Lockfile​

файл блокування​

preferFrozenLockfile​

lockfileIncludeTarballUrl​

gitBranchLockfile​

mergeGitBranchLockfilesBranchPattern​

peersSuffixMaxLength​

Реєстр та параметри автентифікації​

registry​

<scope>:registry​

<URL>:_authToken​

<URL>:tokenHelper​

Налаштування запиту​

ca​

cafile​

<URL>:cafile​

cert​

<URL>:certfile​

key​

<URL>:keyfile​

gitShallowHosts​

https-proxy​

http-proxy​

proxy​

local-address​

maxsockets​

noproxy​

strict-ssl​

networkConcurrency​

fetchRetries​

fetchRetryFactor​

fetchRetryMintimeout​

fetchRetryMaxtimeout​

fetchTimeout​

Параметри прямих залежностей​

autoInstallPeers​

Конфлікт версій​

Розвʼязання конфліктів​

dedupePeerDependents​

strictPeerDependencies​

resolvePeersFromWorkspaceRoot​

peerDependencyRules​

peerDependencyRules.ignoreMissing​

peerDependencyRules.allowedVersions​

peerDependencyRules.allowAny​

Параметри CLI​

[no-]color​

loglevel​

useBetaCli​

recursiveInstall​

Розвʼязання залежностей

overrides

packageExtensions

allowedDeprecatedVersions

updateConfig

updateConfig.ignoreDependencies

supportedArchitectures

ignoredOptionalDependencies

Налаштування підйому залежностей

hoist

hoistWorkspacePackages

hoistPattern

publicHoistPattern

shamefullyHoist

Параметри модулів

modulesDir

nodeLinker

символічне посилання

enableModulesDir

virtualStoreDir

virtualStoreDirMaxLength

packageImportMethod

modulesCacheMaxAge

dlxCacheMaxAge

enableGlobalVirtualStore

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

storeDir

verifyStoreIntegrity

useRunningStoreServer

strictStorePkgContentCheck

Параметри Lockfile

файл блокування

preferFrozenLockfile

lockfileIncludeTarballUrl

gitBranchLockfile

mergeGitBranchLockfilesBranchPattern

peersSuffixMaxLength

Реєстр та параметри автентифікації

registry

<scope>:registry

<URL>:_authToken

<URL>:tokenHelper

Налаштування запиту

ca

cafile

<URL>:cafile

cert

<URL>:certfile

key

<URL>:keyfile

gitShallowHosts

https-proxy

http-proxy

proxy

local-address

maxsockets

noproxy

strict-ssl

networkConcurrency

fetchRetries

fetchRetryFactor

fetchRetryMintimeout

fetchRetryMaxtimeout

fetchTimeout

Параметри прямих залежностей

autoInstallPeers

Конфлікт версій

Розвʼязання конфліктів

dedupePeerDependents

strictPeerDependencies

resolvePeersFromWorkspaceRoot

peerDependencyRules

peerDependencyRules.ignoreMissing

peerDependencyRules.allowedVersions

peerDependencyRules.allowAny

Параметри CLI

[no-]color

loglevel

useBetaCli

recursiveInstall