Перейти до основного вмісту
Версія: 8.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​

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 як ваш компонувальник.
  • Стандартно: 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 to true, the generated lockfile name after installation will be named based on the current branch name to completely avoid merge conflicts. Наприклад, якщо поточна назва гілки feature-foo, то відповідна назва файлу блокування буде pnpm-lock.feature-foo.yaml замість pnpm-lock.yaml. It is typically used in conjunction with the command line argument --merge-git-branch-lockfiles or by setting merge-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​

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 use pnpm add @babel/core, or any @babel scoped package, the package will be fetched from https://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 no certfile 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 to true, 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 have webpack in their dependencies. webpack has esbuild in its optional peer dependencies, and one of the projects has esbuild in its dependencies. In this case, pnpm will link two instances of webpack to the node_modules/.pnpm directory: one with esbuild 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 because webpack is used in two projects, and one of the projects doesn't have esbuild, so the two projects cannot share the same instance of webpack. However, this is not what most developers expect, especially since in a hoisted node_modules, there would only be one instance of webpack. Therefore, you may now use the dedupe-peer-dependents setting to deduplicate webpack when it has no conflicting peer dependencies (explanation at the end). In this case, if we set dedupe-peer-dependents to true, both projects will use the same webpack instance, which is the one that has esbuild 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 dedupe webpack as webpack has react in its peer dependencies and react 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 проєкту та його залежностях.

примітка

Цей прапорець не перешкоджає виконанню .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.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 from https://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/

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

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

If this is enabled, locally available packages are linked to node_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 the workspace: 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 use save-workspace-protocol.

shared-workspace-lockfile​

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

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

Advantages of this option:

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

Even though all the dependencies will be hard linked into the root node_modules, packages will have access only to those dependencies that are declared in their package.json, so pnpm's strictness is preserved. This is a result of the aforementioned symbolic linking.

save-workspace-protocol​

  • Default: 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​

Added in: v8.1.0

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

When set to true, 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's full metadata. Тому в деяких сценаріях це відбувається повільніше. However, if you use Verdaccio v5.15.1 or newer, you may set the registry-supports-time-field setting to true, and it will be really fast.

When resolution-mode is set to lowest-direct, direct dependencies will be resolved to their lowest versions.

registry-supports-time-field​

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

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

extend-node-path​

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

When false, the NODE_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 the package.json, then only the listed files and directories are copied.

dedupe-direct-deps​

Added in: v8.1.0

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

When set to true, dependencies that are already symlinked to the root node_modules directory of the workspace will not be symlinked to subproject node_modules directories.

dedupe-injected-deps​

Added in: v8.13.1

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

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