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

Параметри (.npmrc)

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

Командою pnpm config можна оновити та відредагувати вміст власного та глобального файлів .npmrc.

Ось чотири відповідні файли:

  • конфігураційний файл для кожного проєкту (/path/to/my/project/.npmrc`)
  • конфігураційний файл для кожного робочого простору (тека, в якій міститься файл pnpm-workspace.yaml файл)
  • файл конфігурації для кожного користувача (~/.npmrc)
  • файл глобальної конфігурації (/etc/npmrc)

Усі файли .npmrc — це список у форматі INI параметрів key = value.

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

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

hoist​

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

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

hoist-workspace-packages​

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

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

hoist-pattern​

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

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

Наприклад:

hoist-pattern[]=*eslint*
hoist-pattern[]=*babel*

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

Наприклад:

hoist-pattern[]=*types*
hoist-pattern[]=!@types/react

public-hoist-pattern​

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

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

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

Наприклад:

public-hoist-pattern[]=*plugin*

Зауваження: Встановлення shamefully-hoist у true аналогічно встановленню public-hoist-pattern у *.

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

Наприклад:

public-hoist-pattern[]=*types*
public-hoist-pattern[]=!@types/react

shamefully-hoist​

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

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

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

modules-dir​

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

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

node-linker​

  • Стандартно: 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 створює віртуальну теку сховища без жодних символьних посилань. Це корисний параметр разом з node-linker=pnp.

enable-modules-dir​

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

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

virtual-store-dir​

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

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

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

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

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

virtual-store-dir-max-length​

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

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

package-import-method​

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

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

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

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

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

modules-cache-max-age​

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

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

dlx-cache-max-age​

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

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

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

store-dir​

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

verify-store-integrity​

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

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

use-running-store-server​

небезпека

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

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

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

strict-store-pkg-content-check​

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

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

Параметри Lockfile​

lockfile​

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

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

prefer-frozen-lockfile​

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

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

lockfile-include-tarball-url​

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

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

git-branch-lockfile​

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

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

merge-git-branch-lockfiles-branch-pattern​

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

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

Наприклад:

merge-git-branch-lockfiles-branch-pattern[]=main
merge-git-branch-lockfiles-branch-pattern[]=release*

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

peers-suffix-max-length​

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

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

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

registry​

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

&lt;scope>:registry​

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

&lt;URL&gt;:_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

&lt;URL&gt;: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.

&lt;URL&gt;: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-----"

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

&lt;URL&gt;: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, зафіксованого у репозиторії.

&lt;URL&gt;:keyfile​

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

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

git-shallow-hosts​

  • Стандартно: ['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​

  • Стандартно: network-concurrency x 3
  • Тип: Number

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

noproxy​

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

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

strict-ssl​

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

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

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

network-concurrency​

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

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

fetch-retries​

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

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

fetch-retry-factor​

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

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

fetch-retry-mintimeout​

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

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

fetch-retry-maxtimeout​

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

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

fetch-timeout​

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

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

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

auto-install-peers​

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

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

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

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

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

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

dedupe-peer-dependents​

  • Стандартно: 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. Отже, тепер ви можете використовувати параметр dedupe-peer-dependents для дедуплікації webpack, якщо він не має конфліктуючих прямих залежностей (пояснення у кінці). У цьому випадку, якщо ми встановимо dedupe-peer-dependents у 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 розвʼязується з двох різних версій у контексті двох проєктів.

strict-peer-dependencies​

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

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

resolve-peers-from-workspace-root​

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

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

Параметри CLI​

[no-]color​

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

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

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

loglevel​

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

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

use-beta-cli​

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

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

recursive-install​

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

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

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

engine-strict​

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

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

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

npm-path​

  • Тип: path

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

package-manager-strict​

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

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

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

package-manager-strict-version​

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

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

manage-package-manager-versions​

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

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

{
  "packageManager": "pnpm@9.3.0"
}

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

ignore-scripts​

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

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

нотатка

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

ignore-dep-scripts​

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

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

child-concurrency​

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

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

side-effects-cache​

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

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

side-effects-cache-readonly​

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

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

unsafe-perm​

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

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

node-options​

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

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

verify-deps-before-run​

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

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

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

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

use-node-version​

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

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

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

16.16.0

Використовуйте цей файл .npmrc:

use-node-version=16.16.0

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

node-version​

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

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

Якщо ви хочете заборонити учасникам вашого проєкту додавати нові несумісні залежності, використовуйте node-version та engine-strict у файлі .npmrc у корені проєкту:

node-version=12.22.0
engine-strict=true

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

node-mirror:&lt;releaseDir>​

  • Стандартно: 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/

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

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

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

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

inject-workspace-packages​

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

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

prefer-workspace-packages​

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

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

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

shared-workspace-lockfile​

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

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

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

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

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

save-workspace-protocol​

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

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

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

save-workspace-protocolsave-prefixspec
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:^

include-workspace-root​

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

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

ignore-workspace-cycles​

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

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

disallow-workspace-cycles​

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

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

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

save-prefix​

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

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

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

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

tag​

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

Якщо ви додасте пакунок pnpm add і не вкажете конкретну версію, то він встановить пакунок з версією, зареєстрованою з теґом з цього параметра.

Це також встановлює теґ, який буде додано до package@version, вказаного командою pnpm tag, якщо явно не вказано жодного теґу.

global-dir​

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

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

global-bin-dir​

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

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

state-dir​

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

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

cache-dir​

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

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

use-stderr​

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

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

update-notifier​

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

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

prefer-symlinked-executables​

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

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

ignore-compatibility-db​

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

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

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

resolution-mode​

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

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

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

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

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

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

registry-supports-time-field​

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

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

extend-node-path​

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

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

deploy-all-files​

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

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

dedupe-direct-deps​

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

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

dedupe-injected-deps​

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

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