.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
пакунка з архіву пакунка, на який хук не впливає. In order to ignore a package's build, use the neverBuiltDependencies field.
hooks.updateConfig(config): config | Promise<config>
Added in: v10.8.0
Allows you to modify the configuration settings used by pnpm. This hook is most useful when paired with configDependencies, allowing you to share and reuse settings across different Git repositories.
For example, @pnpm/better-defaults uses the updateConfig
hook to apply a curated set of recommended settings.
Приклад використання
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
}
}
Відомі обмеження
Їх немає — все, що можна зробити з файлом блокування, можна змінити за допомогою цієї функції, і ви навіть можете розширити функціональність файлу блокування.
Повʼязана конфігурація
ignore-pnpmfile
- Стандартно: false
- Тип: Boolean
.pnpmfile.cjs
буде проігноровано. Корисно використовувати разом з --ignore-scripts
, якщо ви хочете переконатися, що жоден скрипт не буде виконано під час встановлення.