pnpm add <pkg>
Встановлює пакунок та будь-які пакунки, від яких він залежить. Стандартно будь-який новий пакунок встановлюється як залежність режиму production.
TL;DR#
| Команда | Значення |
|---|---|
pnpm add sax | Зберегти до dependencies |
pnpm add -D sax | Зберегти до devDependencies |
pnpm add -O sax | Зберегти до optionalDependencies |
pnpm add -g sax | Встановити пакунок глобально |
pnpm add sax@next | Встановити з тегу next |
pnpm add sax@3.0.0 | Вкажіть версію 3.0.0 |
Підтримувані джерела пакунків#
pnpm підтримує встановлення пакунків з різних джерел. Див. сторінку Підтримувані джерела пакетів для отримання докладної документації щодо:
- Реєстру npm
- Реєстру JSR
- Пакунків робочих просторів
- Локальної файлової системи (архіви та теки)
- Віддалені архіви
- Репозиторії Git (із semver, підтеками тощо)
Додавання менеджера пакунків або середовища виконання#
Додано у: v12.0.0-rc.6 (тільки pnpm v12)
Вказання менеджера пакунків, npm, yarn або bun, фіксує, який саме з них використовується в проєкті, замість того, щоб встановлювати пкунок npm з такою ж назвою:
pnpm add yarn@4
запише у "packageManager": "yarn@4.18.0", всі інші менеджери пакунків записуються як діапазон у devEngines.packageManager. Зазначення імені середовища виконання (node, deno) записує його у engines.runtime, як це вже робилося при явному записі node@runtime:22 — bun є і тим, і іншим, і оголошується як менеджер пакунків проєкту, якщо ви не вкажете, що це середовище виконання (pnpm add bun@runtime:1.3.0).
У глобальному режимі команда pnpm add -g yarn встановлює поточну версію Yarn, а не класичний пакунок yarn, а команда pnpm add -g node@22 встановлює саме цей випуск Node.js, а не обгортку, яка завантажує його.
Специфікатор, який вказує на розташування пакунка, а не вимагає випущеної версії — pnpm add yarn@npm:yarn@1.22.22, pnpm add yarn@yarnpkg/berry — встановлює те, що вказано в його імені, як звичайну залежність.
Параметри#
--save-prod, -P, -p#
Встановлює вказані пакунки як звичайні dependencies.
--save-dev, -D, -d#
Встановлює вказані пакунки як devDependencies.
--save-optional, -O, -o#
Встановлює вказані пакунки як optionalDependencies.
--save-exact, -E, -e#
Збережені залежності (dependencies) буде сконфігуровано з точною версією, а не з використанням стандартного оператора діапазону semver.
--save-peer#
Використання --save-peer додасть один або кілька пакунків до peerDependencies та встановить їх як залежності для розробки (dev dependencies).
--save-catalog#
Додано у: v10.12.1
Зберігає нову залежність до стандартного каталогу.
--save-catalog-name <catalog_name>#
Додано у: v10.12.1
Зберігає нову залежність до вказаного каталогу.
--config#
Додано у: v10.8.0
Зберігає залежність у configDependencies.
--ignore-workspace-root-check#
Додавання нової залежності до пакунка кореневого робочого простору завершиться невдачею, якщо не використовується прапорець --ignore-workspace-root-check або -w.
Наприклад, pnpm add debug -w.
--global, -g#
Встановлює пакунок глобально. Дивіться розділ Глобальні пакунки для отримання додаткової інформації.
Кожен відділкний пробілом пакунок встановлюється у свою окрему теку. Щоб обʼєднати кілька пакунків в один ізольований процес встановлення (так вони матимуть спільні залежності та будуть видалені разом), передайте їх як список, розділений комами, наприклад pnpm add -g eslint,prettier.
--workspace#
Додає нову залежність лише у випадку, якщо вона знаходиться в робочому просторі.
--allow-build#
Додано у: v10.4.0
Список назв пакунків, для яких дозволено запускати післяінсталяційні скрипти під час встановлення.
Приклад:
pnpm --allow-build=esbuild add my-bundler
Це запустить післяінсталяційний скрипт esbuild і додасть його до поля allowBuilds у файлі pnpm-workspace.yaml. Отже, esbuild завжди матиме змогу запускати свої скрипти у майбутньому.
--filter <package_selector>#
--cpu=<name>#
Додано у: v10.14.0
Перевизначити архітектуру CPU нативних модулів для встановлення. Прийнятні значення такі самі, як поле cpu у файлі package.json, яке походить із process.arch.
--os=<name>#
Додано у: v10.14.0
Перевизначити OS нативних модулів для встановлення. Прийнятні значення такі самі, як поле os у файлі package.json, яке походить із process.platform.
--libc=<name>#
Додано у: v10.14.0
Перевизначити libc нативних модулів для встановлення. Прийнятні значення такі самі, як поле libc у файлі package.json.