Перейти до основного вмісту
Версія: 10.x

.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.')) {
    // Replace bar@x.x.x with 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 пакунка з архіву пакунка, на який хук не впливає. Щоб ігнорувати збірку пакунка, використовуйте поле pnpm.neverBuiltDependencies.

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

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

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

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

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 як основний менеджер пакунків.