.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
пакунка з архіву пакунка, на який хук не впливає. Щоб ігнорувати збірку пакунка, використовуйте поле neverBuiltDependencies.
hooks.updateConfig(config): config | Promise<config>
Додано у: v10.8.0
Дозволяє змінювати параметри конфігурації, які використовуються pnpm. Цей хук є найбільш корисним у поєднанні з configDependencies, що дозволяє вам ділитися та повторно використовувати налаштування в різних репозиторіях Git.
Наприклад, @pnpm/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>
This hook is executed after reading and parsing the lockfiles of the project, but before resolving dependencies. It allows modifications to the lockfile objects.
Аргументи
options.existsCurrentLockfile
- A boolean that is true if the lockfile atnode_modules/.pnpm/lock.yaml
exists.options.currentLockfile
- The lockfile object fromnode_modules/.pnpm/lock.yaml
.options.existsNonEmptyWantedLockfile
- A boolean that is true if the lockfile atpnpm-lock.yaml
exists.options.wantedLockfile
- The lockfile object frompnpm-lock.yaml
.options.lockfileDir
- The directory where the wanted lockfile is found.options.storeDir
- The location of the store directory.options.registries
- A map of scopes to registry URLs.
hooks.importPackage(destinationDir, options): Promise<string | undefined>
This hook allows to change how packages are written to node_modules
. The return value is optional and states what method was used for importing the dependency, e.g.: clone, hardlink.
Аргументи
destinationDir
- The destination directory where the package should be written.options.disableRelinkLocalDirDeps
options.filesMap
options.force
options.resolvedFrom
options.keepModulesDir
hooks.fetchers
This hook allows to override the fetchers that are used for different types of dependencies. It is an object that may have the following fields:
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 як основний менеджер пакунків.