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

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

ignore-pnpmfile​

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

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

pnpmfile​

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

Розташування локального pnpmfile.

global-pnpmfile​

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

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

нотатка

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