pnpm install
Псевдоніми: i
pnpm install використовується для встановлення всіх залежностей проєкту.
У середовищі CI встановлення не вдається, якщо файл блокування присутній, але потребує оновлення.
У робочому просторі, pnpm install встановлює всі залежності в усіх проєктах. Якщо ви бажаєте вимкнути цю поведінку, змініть значення recursive-install на false.
TL;DR#
| Команда | Значення |
|---|---|
pnpm i --offline | Встановити оффлайн, тільки зі сховища |
pnpm i --frozen-lockfile | pnpm-lock.yaml не буде змінено |
pnpm i --lockfile-only | Оновити тільки pnpm-lock.yaml |
pnpm i --dry-run | Попередній перегляд змін без запису |
Параметри фільтрації залежностей#
За відсутності файлу блокування pnpm має створити його, і він має бути узгодженим незалежно від фільтрації залежностей, тому запуск pnpm install --prod у теці без файлу блокування все одно призведе до розвʼязання залежностей dev, а якщо розвʼязання буде невдалим, то виникне помилка. Єдиним винятком з цього правила є залежності link:.
Без --frozen-lockfile pnpm перевірятиме застарілу інформацію з залежностей file:, тому запуск pnpm install --prod без --frozen-lockfile у середовищі, де ціль file: було видалено, призведе до помилки.
--prod, -P#
- Стандартно: false
- Тип: Boolean
Якщо true, pnpm не встановлюватиме жодного пакунка, з devDependencies, і видалятиме ті, які вже встановлені. Якщо false, pnpm встановить усі пакунки, з devDependencies та dependencies.
--dev, -D#
Встановлюються лише devDependencies і видаляються dependencies, якщо вони вже були встановлені.
--no-optional#
optionalDependencies не буде встановлено.
--no-runtime#
Додано у: v11.1.0
Пропустити встановлення елементів середовища виконання (наприклад, Node.js, завантаженого через devEngines.runtime). Файл блокування залишається без змін, тому «заморожені» встановлення все ще перевіряються на коректність; пропускаються лише завантаження під час виконання та компіляція з бінарними файлами.
Це корисно в матрицях CI, де середовище виконання надається ззовні (наприклад, через pnpm runtime -g set node <version>) перед запуском pnpm install.
Це також можна встановити за допомогою runtime=false у pnpm-workspace.yaml.
Параметри#
--force#
Примусове перевстановлення залежностей: перезавантаження пакунків, змінених у сховищі, перестворення файлу блокування та/або теки модулів, створених несумісною версією pnpm. Встановить усі optionalDependencies, навіть якщо вони не задовольняють поточному оточенню (cpu, os, arch).
--offline#
- Стандартно: false
- Тип: Boolean
Якщо true, pnpm буде використовувати тільки пакунки, які вже доступні в сховищі. Якщо пакунок не буде знайдено локально, встановлення завершиться невдачею.
--prefer-offline#
- Стандартно: false
- Тип: Boolean
Якщо true, то перевірку свіжості кешованих даних буде пропущено, але дані, яких бракує буде запитано з сервера. Щоб примусово увімкнути офлайн режим, використовуйте --offline.
--no-lockfile#
Не читати і не генерувати файл pnpm-lock.yaml.
--lockfile-only#
- Стандартно: false
- Тип: Boolean
При використанні, оновлює тільки pnpm-lock.yaml і package.json. До теки node_modules нічого не буде записано.
--dry-run#
Додано у: v11.8.0
Виконує повне визначення залежностей та повідомляє, що зміниться під час реальної інсталяції, не записуючи нічого на диск. Зміни у файлі блокування, маніфесті або в node_modules не зберігаються.
Пробний запуск завершується з кодом 0, навіть якщо повідомляється, що під час реальної інсталяції файл блокування буде оновлено.
--dry-run не можна використовувати з налаштованим сервером pnpr, оскільки цей шлях установки визначається та пов’язується через сервер.
--fix-lockfile#
Автоматично виправити пошкоджені записи файлу блокування.
--update-checksums#
Додано у: v11.4.0
Оновлює значення цілісності захищеного архіву на ті, що наразі надаються реєстром, якщо хеш завантаженого архіву не збігається з даними про цілісність, записаними у файлі pnpm-lock.yaml.
З версії 11.4.0 зазвичай невідповідність цілісності вважається серйозною помилкою: команда pnpm install завершується з помилкою ERR_PNPM_TARBALL_INTEGRITY, а не виконує мовчазне повторне визначення з реєстру та перезапис заблокованої цілісності. Це захищає проєкти, які поширюють зафіксований файл блокування, від компрометованого реєстру, проксі-сервера або перевиданої версії, що замінює вміст на чистій машині на такий, що контролюється зловмисником.
--update-checksums — це опція з вузькою сферою застосування, призначена для конкретних випадків (наприклад, якщо репозиторій переписав свої архіви tar, і ви переконалися, що нові байти є правильними). Коли оминання вступає в дію, на екрані все одно з’являється попередження, щоб цю операцію можна було перевірити.
Команди --force та pnpm update навмисно не оминають перевірку цілісності. --frozen-lockfile залишається без змін, а --fix-lockfile зберігає своє задокументоване призначення (заповнення відсутніх записів у файлі блокування) і також не є обхідним варіантом.
--frozen-lockfile#
- Стандартно:
- Для не CI: false
- Для CI: true, якщо присутній файл блокування
- Тип: Boolean
Якщо true, pnpm не генерує файл блокування та не виконує інсталяцію, якщо файл блокування не синхронізований з маніфестом / потрібне оновлення або файл блокування відсутній.
Цей параметр стандартно дорівнює true в CI середовищах. Для виявлення середовищ CI використовується наступний код:
exports.isCI = !!(
env.CI || // Travis CI, CircleCI, Cirrus CI, GitLab CI, Appveyor, CodeShip, dsari
env.CONTINUOUS_INTEGRATION || // Travis CI, Cirrus CI
env.BUILD_NUMBER || // Jenkins, TeamCity
env.RUN_ID || // TaskCluster, dsari
exports.name ||
false
)
--merge-git-branch-lockfiles#
Обʼєднання всіх файлів блокування гілок git. Докладніше про файли блокування гілок git.
--reporter=<name>#
- Стандартно:
- Для TTY stdout: default
- Для non-TTY stdout: append-only
- Тип: default, append-only, ndjson, silent
Дозволяє вибрати репортера, який записуватиме у термінал налагоджувальну інформацію про хід встановлення.
- silent — у консоль не виводиться жодних даних, навіть фатальних помилок
- default — стандартний репортер, коли stdout є TTY
- append-only — результат завжди додається в кінець. Жодні маніпуляції з курсором не виконуються
- ndjson — найдокладніший репортер. Виводіть всі журнали у форматі ndjson
Якщо ви хочете змінити тип інформації, що виводиться, скористайтеся параметром loglevel.
--shamefully-hoist#
- Стандартно: false
- Тип: Boolean
Створює пласку структуру node_modules, подібну до структури npm або yarn. ПОПЕРЕДЖЕННЯ: це вкрай не рекомендується.
--ignore-scripts#
- Стандартно: false
- Тип: Boolean
Не виконувати будь-які скрипти, визначені в package.json проєкту та його залежностях.
--filter <package_selector>#
Читайте більше про використання фільтрів.
--resolution-only#
Перезапускає вирішення: корисно для виводу проблем із прямою залежністю.
інформація
Цей прапорець існує лише в pnpm 11. pnpm 12 не підтримує цю опцію і видає помилку error: unexpected argument '--resolution-only' found.
Щоб переглянути перелік проблем із прямими залежностями у будь-якій із цих версій, виконайте команду pnpm peers check. Вони зчитуються з файлу блокування, тому не потрібно ні повторного визначення, ні встановлення.
--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.