pnpm install

Псевдоніми: i

pnpm install використовується для встановлення всіх залежностей проєкту.

У середовищі CI встановлення не вдається, якщо файл блокування присутній, але потребує оновлення.

У робочому просторі, pnpm install встановлює всі залежності в усіх проєктах. Якщо ви бажаєте вимкнути цю поведінку, змініть значення recursive-install на false.

TL;DR#

КомандаЗначення
pnpm i --offlineВстановити оффлайн, тільки зі сховища
pnpm i --frozen-lockfilepnpm-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 використовується наступний код:

https://github.com/watson/ci-info/blob/44e98cebcdf4403f162195fbcf90b1f69fc6e047/index.js#L54-L61
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.