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​

Added in: v8.14.0

• Стандартно:false
• Тип: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*

You may also exclude patterns from hoisting using!.

Наприклад:

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

public-hoist-pattern​

• Default:['*eslint*', '*prettier*']
• Тип:string[]

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

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

Наприклад:

public-hoist-pattern[]=*plugin*

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

You may also exclude patterns from hoisting using!.

Наприклад:

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

shamefully-hoist​

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

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

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

store-dir​

• Стандартно:
  • If the$PNPM_HOME env variable is set, then$PNPM_HOME/store
  • Якщо встановлено змінну$XDG_DATA_HOME env, то$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 копіюватиме пакунки зі сховища, а не звʼязуватиме їх жорсткими посиланнями, оскільки жорсткі посилання можливі лише у тій самій файловій системі.

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 як ваш компонувальник.

symlink​

• Стандартно: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. Це зробить трасування стеку чистішим, оскільки шляхи до залежностей будуть на одну теку вище.

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

package-import-method​

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

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

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

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

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

modules-cache-max-age​

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

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

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

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

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

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

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

Наприклад:

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

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

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

registry​

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

The base URL of the npm package registry (trailing slash included).

<scope>:registry​

The npm registry that should be used for packages of the specified scope. For example, setting@babel:registry=https://example.com/packages/npm/ will enforce that when you usepnpm add @babel/core, or any@babel scoped package, the package will be fetched fromhttps://example.com/packages/npm instead of the default registry.

<URL>:_authToken​

Define the authentication bearer token to use when accessing the specified registry. Наприклад:

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

You may also use an environment variable. Наприклад:

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

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

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

<URL>:tokenHelper​

A token helper is an executable which outputs an auth token. This can be used in situations where the authToken is not a constant value but is something that refreshes regularly, where a script or other tool can use an existing refresh token to obtain a new access token.

The configuration for the path to the helper must be an absolute path, with no arguments. In order to be secure, it is only permitted to set this value in the user.npmrc. Otherwise a project could place a value in a project's local.npmrc and run arbitrary executables.

Setting a token helper for the default registry:

tokenHelper=/home/ivan/token-generator

Setting a token helper for the specified registry:

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

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

ca​

• Стандартно:Сертифікат npm CA
• Тип:String, 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.

cert​

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

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

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

It is not the path to a certificate file (and there is nocertfile option).

key​

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

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

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

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

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

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, замість них буде використано їхні значення.

If your proxy URL contains a username and password, make sure to URL-encode them. Наприклад:

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

Do not encode the colon (:) between the username and password.

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

When this setting is set totrue, packages with peer dependencies will be deduplicated after peers resolution.

For instance, let's say we have a workspace with two projects and both of them havewebpack in their dependencies.webpack hasesbuild in its optional peer dependencies, and one of the projects hasesbuild in its dependencies. In this case, pnpm will link two instances ofwebpack to thenode_modules/.pnpm directory: one withesbuild and another one without it:

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

This makes sense becausewebpack is used in two projects, and one of the projects doesn't haveesbuild, so the two projects cannot share the same instance ofwebpack. However, this is not what most developers expect, especially since in a hoistednode_modules, there would only be one instance ofwebpack. Therefore, you may now use thededupe-peer-dependents setting to deduplicatewebpack when it has no conflicting peer dependencies (explanation at the end). In this case, if we setdedupe-peer-dependents totrue, both projects will use the samewebpack instance, which is the one that hasesbuild resolved:

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

What are conflicting peer dependencies? By conflicting peer dependencies we mean a scenario like the following one:

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)

In this case, we cannot dedupewebpack aswebpack hasreact in its peer dependencies andreact is resolved from two different versions in the context of the two projects.

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 використовує для деяких дій, таких як публікація.

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

ignore-scripts​

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

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

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.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

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:<releaseDir>​

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

Задає базову URL-адресу для завантаження Node.js. The<releaseDir> portion of this setting can be any directory fromhttps://nodejs.org/download:release,rc,nightly,v8-canary, etc.

Ось як можна налаштувати 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/

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

link-workspace-packages​

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

If this is enabled, locally available packages are linked tonode_modules instead of being downloaded from the registry. This is very convenient in a monorepo. Якщо вам потрібно, щоб локальні пакунки також були повʼязані з підзалежностями, ви можете скористатися параметромdeep.

Else, packages are downloaded and installed from the registry. However, workspace packages can still be linked by using theworkspace: range protocol.

prefer-workspace-packages​

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

If this is enabled, local packages from the workspace are preferred over packages from the registry, even if there is a newer version of the package in the registry.

This setting is only useful if the workspace doesn't usesave-workspace-protocol.

shared-workspace-lockfile​

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

If this is enabled, pnpm creates a singlepnpm-lock.yaml file in the root of the workspace. This also means that all dependencies of workspace packages will be in a singlenode_modules (and get symlinked to their packagenode_modules folder for Node's module resolution).

Advantages of this option:

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

save-workspace-protocol​

• Default:rolling
• Тип:true,false,rolling

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

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

include-workspace-root​

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

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

ignore-workspace-cycles​

Added in: v8.1.0

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

When set totrue, no workspace cycle warnings will be printed.

disallow-workspace-cycles​

Added in: v8.9.0

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

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

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

use-running-store-server​

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

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

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 додасте пакунок і не вкажете конкретну версію, то він встановить пакунок з версією, зареєстрованою з тегом з цього параметра.

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

global-dir​

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

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

state-dir​

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

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

cache-dir​

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

The location of the package metadata cache.

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.

verify-store-integrity​

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

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

ignore-compatibility-db​

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

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

The patches are applied from Yarn's@yarnpkg/extensions package.

resolution-mode​

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

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

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

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

This resolution mode works only with npm'sfull metadata. Тому в деяких сценаріях це відбувається повільніше. However, if you useVerdaccio v5.15.1 or newer, you may set theregistry-supports-time-field setting totrue, and it will be really fast.

Whenresolution-mode is set tolowest-direct, direct dependencies will be resolved to their lowest versions.

registry-supports-time-field​

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

Встановіть значенняtrue, якщо реєстр, який ви використовуєте, повертає поле «time» у скорочених метаданих. As of now, onlyVerdaccio from v5.15.1 supports this.

extend-node-path​

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

Whenfalse, theNODE_PATH environment variable is not set in the command shims.

deploy-all-files​

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

When deploying a package or installing a local package, all files of the package are copied. By default, if the package has a"files" field in thepackage.json, then only the listed files and directories are copied.

dedupe-direct-deps​

Added in: v8.1.0

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

When set totrue, dependencies that are already symlinked to the rootnode_modules directory of the workspace will not be symlinked to subprojectnode_modules directories.

dedupe-injected-deps​

Added in: v8.13.1

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

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