Версія: 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, якщо ви вже розвʼязали залежність, яку ви хочете змінити.

підказка

If you need changes to package.json saved to the filesystem, you need to use the pnpm patch command and patch the package.json file. Це може бути корисно, наприклад, якщо ви хочете видалити поле 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

Finders

Added in: v10.16.0

Finder functions are used with pnpm list and pnpm why via the --find-by flag.

Приклад:

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

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

pnpm why --find-by=react17

See Finders for more details.

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

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​

Finders​

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

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`

Finders

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

ignorePnpmfile

pnpmfile

globalPnpmfile