Версія: Next

.pnpmfile.cjs

pnpm дозволяє вам підключатися безпосередньо до процесу встановлення за допомогою спеціальних функцій (хуків). Хуки можуть бути оголошені у файлі з назвою .pnpmfile.cjs.

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

Хуки

TL;DR

Функція хука	Процес	Використання
`hooks.readPackage(pkg, context): pkg`	Викликається після того, як pnpm проаналізує маніфест пакунків залежності	Дозволяє змінювати файл `package.json` залежності
`hooks.afterAllResolved(lockfile, context): lockfile`	Викликається після розвʼязання залежностей.	Дозволяє змінювати файл блокування.

`hooks.readPackage(pkg, context): pkg | Promise<pkg>`

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

Зауважте, що вам потрібно буде видалити pnpm-lock.yaml, якщо ви вже розвʼязали залежність, яку ви хочете змінити.

підказка

Якщо вам потрібно внести зміни до package.json, збереженого у файловій системі, вам потрібно скористатися командою pnpm patch і виправити файл package.json. Це може бути корисно, наприклад, якщо ви хочете видалити поле bin у залежності.

Аргументи

pkg – маніфест пакунка. Або відповідь з реєстру, або вміст package.json.
context — обʼєкт Context для кроку. Метод #log(msg) дозволяє використовувати журнал налагодження для кроку.

Використання

Приклад .pnpmfile.cjs (змінює dependencies залежності):

function readPackage(pkg, context) {
  // Перевизначимо маніфест foo@1.x, завантаживши його з реєстру
  if (pkg.name === 'foo' && pkg.version.startsWith('1.')) {
    // Заміними bar@x.x.x на bar@2.0.0
    pkg.dependencies = {
      ...pkg.dependencies,
      bar: '^2.0.0'
    }
    context.log('bar@1 => bar@2 in dependencies of foo')
  }

  // Це призведе до зміни всіх пакунків, які використовують baz@x.x.x, на baz@1.2.3.
  if (pkg.dependencies.baz) {
    pkg.dependencies.baz = '1.2.3';
  }

  return pkg
}

module.exports = {
  hooks: {
    readPackage
  }
}

Відомі обмеження

Видалення поля scripts з маніфесту залежності за допомогою readPackage не завадить pnpm зібрати залежність. При побудові залежності pnpm зчитує package.json пакунка з архіву пакунка, на який хук не впливає. Щоб ігнорувати збірку пакунка, використовуйте поле neverBuiltDependencies.

`hooks.updateConfig(config): config | Promise<config>`

Додано у: v10.8.0

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

Наприклад, @pnpm/plugin-better-defaults використовує хук updateConfig для застосування спеціального набору рекомендованих параметрів.

Приклад використання

.pnpmfile.cjs
module.exports = {
  hooks: {
    updateConfig (config) {
      return Object.assign(config, {
        enablePrePostScripts: false,
        optimisticRepeatInstall: true,
        resolutionMode: 'lowest-direct',
        verifyDepsBeforeRun: 'install',
      })
    }
  }
}

`hooks.afterAllResolved(lockfile, context): lockfile | Promise<lockfile>`

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

Аргументи

lockfile — Обʼєкт резолюції файлу блокування, який серіалізовано у pnpm-lock.yaml.
context — обʼєкт Context для кроку. Метод #log(msg) дозволяє використовувати журнал налагодження для кроку.

Приклад використання

.pnpmfile.cjs
function afterAllResolved(lockfile, context) {
  // ...
  return lockfile
}

module.exports = {
  hooks: {
    afterAllResolved
  }
}

Відомі обмеження

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

`hooks.preResolution(options): Promise<void>`

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

Аргументи

options.existsCurrentLockfile — булеве значення, яке є істинним, якщо файл блокування за адресою node_modules/.pnpm/lock.yaml існує.
options.currentLockfile — Обʼєкт файлу блокування з node_modules/.pnpm/lock.yaml.
options.existsNonEmptyWantedLockfile — булеве значення, яке є істинним, якщо файл блокування за адресою pnpm-lock.yaml існує.
options.wantedLockfile — Обʼєкт файлу блокування з pnpm-lock.yaml.
options.lockfileDir — Тека, де знаходиться потрібний файл блокування.
options.storeDir — Розташування теки store.
options.registries — Зіставлення областей видимості з URL-адресами реєстрів.

`hooks.importPackage(destinationDir, options): Promise<string | undefined>`

Цей хук дозволяє змінити спосіб запису пакунків до node_modules. Значення, що повертається, є необовʼязковим і вказує, який метод було використано для імпорту залежності, наприклад: clone, hardlink.

Аргументи

destinationDir — Тека призначення, куди має бути записано пакунок.
options.disableRelinkLocalDirDeps
options.filesMap
options.force
options.resolvedFrom
options.keepModulesDir

`hooks.fetchers`

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

localTarball
remoteTarball
gitHostedTarball
directory
git

Пошук

Додано у: v10.16.0

Функції пошуку використовуються з pnpm list та pnpm why через прапорець --find-by.

Приклад:

.pnpmfile.cjs
module.exports = {
  finders: {
    react17: (ctx) => {
      return ctx.readManifest().peerDependencies?.react === "^17.0.0"
    }
  }
}

Використання:

pnpm why --find-by=react17

Дивіться Пошук для отримання додаткової інформації.

Повʼязана конфігурація

ignorePnpmfile

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

.pnpmfile.cjs буде проігноровано. Корисно використовувати разом з --ignore-scripts, якщо ви хочете переконатися, що жоден скрипт не буде виконано під час встановлення.

pnpmfile

Стандартно: ['.pnpmfile.cjs']
Тип: path[]
Приклад: ['.pnpm/.pnpmfile.cjs']

Розташування локальних файлів pnpmfile.

globalPnpmfile

Стандартно: null
Тип: path
Приклад: ~/.pnpm/global_pnpmfile.cjs

Розташування глобального pnpmfile. Глобальний pnpmfile використовується всіма проєктами під час встановлення.

нотатка

Рекомендується використовувати локальні pnpmfiles. Використовуйте глобальний файл pnpmfile лише у тому випадку, якщо ви використовуєте pnpm у проєктах, які не використовують pnpm як основний менеджер пакунків.

Хуки​

TL;DR​

hooks.readPackage(pkg, context): pkg | Promise<pkg>​

Аргументи​

Використання​

Відомі обмеження​

hooks.updateConfig(config): config | Promise<config>​

Приклад використання​

hooks.afterAllResolved(lockfile, context): lockfile | Promise<lockfile>​

Аргументи​

Приклад використання​

Відомі обмеження​

hooks.preResolution(options): Promise<void>​

Аргументи​

hooks.importPackage(destinationDir, options): Promise<string | undefined>​

Аргументи​

hooks.fetchers​

Пошук​

Повʼязана конфігурація​

ignorePnpmfile​

pnpmfile​

globalPnpmfile​

Хуки

TL;DR

`hooks.readPackage(pkg, context): pkg | Promise<pkg>`

Аргументи

Використання

Відомі обмеження

`hooks.updateConfig(config): config | Promise<config>`

Приклад використання

`hooks.afterAllResolved(lockfile, context): lockfile | Promise<lockfile>`

Аргументи

Приклад використання

Відомі обмеження

`hooks.preResolution(options): Promise<void>`

Аргументи

`hooks.importPackage(destinationDir, options): Promise<string | undefined>`

Аргументи

`hooks.fetchers`

Пошук

Повʼязана конфігурація

ignorePnpmfile

pnpmfile

globalPnpmfile