pnpm publish

Публікує пакунок в реєстрі.

pnpm [-r] publish [<tarball|folder>] [--tag <tag>]
     [--access <public|restricted>] [options]

Під час публікації пакунка у робочій області, файл LICENSE з кореня робочої області пакується разом з пакунком (якщо тільки пакунок не має власної ліцензії).

Ви можете перевизначити деякі поля перед публікацією, використовуючи поле publishConfig у package.json. Ви також можете використовувати publishConfig.directory для налаштування вкладеної теки, що публікується (зазвичай за допомогою сторонніх інструментів збірки).

При рекурсивному виконанні цієї команди (pnpm -r publish) pnpm опублікує усі пакунки, версії яких ще не було опубліковано у реєстрі.

Параметри#

--recursive, -r#

Публікує всі пакунки з робочого простору.

--json#

Показати інформацію у форматі JSON.

--tag <tag>#

Публікує. всі пакунки з вказаним теґом. Стандартно, pnpm publish оновлює теґ latest.

Наприклад:

# всередині теки пакунків foo
pnpm publish --tag next
# у проєкті, де ви хочете використовувати наступну версію foo
pnpm add foo@next

--access <public|restricted>#

Вказує реєстру, чи повинен опублікований пакунок бути загальнодоступним або обмеженим.

--no-git-checks#

Не перевіряти, чи поточна гілка є вашою гілкою для публікації, вона є чистою та актуальною з віддаленою версією.

--publish-branch <branch>#

• Стандартно: master та main
• Типи: String

Основна гілка репозиторію, яка використовується для публікації останніх змін.

--force#

Намагатись публікувати пакунки, навіть якщо їх поточну версію вже знайдено у реєстрі.

--batch#

Додано у: v11.7.0

Під час рекурсивної публікації (pnpm -r publish) надсилайте всі вибрані пакунки до реєстру одним запитом PUT /-/pnpm/v1/publish, а не окремим запитом для кожного пакунка.

Цільовий реєстр повинен реалізувати точку доступу для публікації партії (це робить pnpr); у разі, якщо реєстри цього не роблять, видається повідомлення про помилку ERR_PNPM_BATCH_PUBLISH_UNSUPPORTED. Процес обробки партії відбувається за принципом «все або нічого»: якщо хоча б один пакунок у партії не проходить перевірку, жоден із пакунків не публікується.

--skip-manifest-obfuscation#

Додано у: v11.3.0

Залишати оригінальне поле packageManager і публікувати скрипти життєвого циклу в опублікованому маніфесті, замість того щоб видаляти їх. Поле pnpm, характерне для pnpm, як і раніше, оминається.

--report-summary#

Зберегти список опублікованих пакунків у файлі pnpm-publish-summary.json. Корисно, коли для звіту про список опублікованих пакунків використовується інший інструментарій.

Приклад файлу pnpm-publish-summary.json:

{
  "publishedPackages": [
    {
      "name": "foo",
      "version": "1.0.0"
    },
    {
      "name": "bar",
      "version": "2.0.0"
    }
  ]
}

--dry-run#

Робити все, що робить публікація, за винятком власне публікації в реєстрі.

--otp#

При публікації пакунків, які вимагають двофакторної автентифікації, у цьому параметрі можна вказати одноразовий пароль.

Ви також можете вказати OTP через змінну середовища PNPM_CONFIG_OTP:

export PNPM_CONFIG_OTP='<your OTP here>'
pnpm publish --no-git-checks

Якщо реєстр запитує OTP, а ви не надали його через змінну середовища або прапорець --otp, pnpm безпосередньо запитає у вас код OTP.

Якщо реєстр запитує вебавтентифікацію, pnpm виведе доступний для сканування QR-код разом з URL-адресою.

--provenance#

При публікації з підтримуваної хмарної системи CI/CD пакунок буде публічно повʼязаний з місцем, де він був створений і опублікований.

--filter <package_selector>#

Читайте більше про використання фільтрів.

Налаштування#

Ви також можете встановити параметри gitChecks, publishBranch у файлі pnpm-workspace.yaml.

Наприклад:

gitChecks: false
publishBranch: production

Сценарії#

• prepublishOnly
• prepublish
• prepack
• prepare
• postpack
• publish
• postpublish