.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
для застосування спеціального набору рекомендованих параметрів.
Приклад використання
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)
дозволяє використовувати журнал налагодження для кроку.
Приклад використання
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
Повʼязана конфігурація
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 як основний менеджер пакунків.