Релиз и публикация
Полный цикл релиза: поднять версию через PR, поставить тег, создать GitHub Release и опубликовать в npm — четыре отдельных, компонуемых шага. Бампнуть партию пакетов и затем опубликовать или зарелизить только часть из них — разные по смыслу решения, которые не всегда происходят одновременно, поэтому они никогда не объединены принудительно.
bump
Выбор пакетов, поднятие версии (по умолчанию patch), открытие PR, merge в основную ветку и тег релиза.
polyrepo bump [options]- Показывает чекбокс пакетов с текущей версией и версией, до которой она поднимется (
1.2.9 → 1.2.10для patch-бампа —--minor/--majorподнимают другую часть версии, обнуляя всё, что ниже, как у любого semver-инструмента). Пакеты с грязным рабочим деревом помечены — они будут пропущены. В описании подсвеченного пакета показано, что реально изменилось с последнего git-тега — вычисляется для всех пакетов параллельно. - После подтверждения — для каждого выбранного пакета по одному:
git fetch origin→git checkout <default branch>→git merge --ff-only origin/<default branch>(bump-ветка всегда создаётся от актуальной основной ветки, а не от той, на которой репозиторий случайно оказался);- проверяет состояние предыдущей попытки — есть ли уже смёрдженный PR, открытый PR, либо просто запушенная ветка с именем
<new-version>-version-bump. В зависимости от того, что найдено, процесс продолжается с нужного места вместо падения на «ветка уже существует» или создания дублирующего PR; - если
package.jsonна ветке ещё не бампнут — поле"version"обновляется (текстовая замена — форматирование и порядок полей не трогаются). Если у пакета уже естьCHANGELOG.md, туда же добавляется черновик записи## [x.y.z] - YYYY-MM-DD(в стиле Keep a Changelog) со списком коммитов с последнего тега — черновик для правки, не готовый changelog; gh pr createв основную ветку (если PR ещё не существует);- с
--wait-checks: ожидание CI-проверок PR перед merge; отсутствие настроенных проверок не считается ошибкой; gh pr merge --merge— через PR, не прямым push;- локальная основная ветка синхронизируется с только что смёрдженным PR;
- git-тег
v<new-version>создаётся и пушится, если его ещё нет.
- Любая ошибка на этом пути помечает пакет ✗ с понятным сообщением, и процесс переходит к следующему пакету, не прерывая весь запуск целиком.
- После обработки всех выбранных пакетов — отдельная проверка по всем пакетам (не только только что бампнутым): не остался ли у какого-то локального пакета диапазон зависимости, не соответствующий новой версии бампнутого пакета — ничего не меняется автоматически.
Реальный вывод — --dry-run, пока ещё ничего не существует:
[1/1] os-detect 2.1.5 → 2.1.6
$ git fetch origin
$ git checkout master
Your branch is up to date with 'origin/master'.
Already on 'master'
$ git merge --ff-only origin/master
Already up to date.
✓ master is up to date.
[dry-run] would create branch 2.1.6-version-bump, ensure version 2.1.6 (+ a CHANGELOG.md entry if one exists), commit/push if needed, then open + merge a PR, then tag v2.1.6.Повторный запуск bump на пакете, где предыдущая попытка уже прошла весь путь до конца, гораздо короче — всё уже сделанное просто подтверждается, а не выполняется заново:
[1/1] vue-toast-kit 1.0.7 → 1.0.8
✓ master is up to date.
✓ Already merged as PR #12 — master already has it.
✓ Tag v1.0.8 already exists on origin.--prerelease, либо --preid в паре с --major/--minor, вычисляют целевую версию иначе, но проходят через те же самые шаги ветка → PR → merge → тег:
[1/1] os-detect 2.1.5 → 2.1.6-beta.0
$ git fetch origin
$ git checkout master
Your branch is up to date with 'origin/master'.
Already on 'master'
$ git merge --ff-only origin/master
Already up to date.
✓ master is up to date.
[dry-run] would create branch 2.1.6-beta.0-version-bump, ensure version 2.1.6-beta.0 (+ a CHANGELOG.md entry if one exists), commit/push if needed, then open + merge a PR, then tag v2.1.6-beta.0.Опции
--dry-run
Печатает план по каждому пакету, ничего не пушит и не меняет — включая запись в CHANGELOG.md, ожидание CI и git-тег.
--minor
Поднять minor-версию вместо patch (например, 1.2.9 → 1.3.0).
--major
Поднять major-версию вместо patch (например, 1.2.9 → 2.0.0).
--prerelease
Поднять (или начать) пререлиз вместо patch/minor/major (например, 1.2.9 → 1.2.10-alpha.0, либо 1.2.10-alpha.0 → 1.2.10-alpha.1). В паре с --preid задаётся имя — node-semver сам решает, добавить ли -alpha.0 к текущей версии или продвинуть номер уже существующего пререлиза.
--preid <name>
Идентификатор пререлиза для --prerelease, либо в паре с --minor/--major — для preminor/premajor-пререлиза (например, --major --preid beta на 1.2.9 → 2.0.0-beta.0). По умолчанию alpha.
--custom-version <version>
Задать точную версию вместо вычисления. Работает только вместе с --packages, называющим ровно один пакет — применять одну и ту же версию сразу к нескольким пакетам никогда не имеет смысла.
--packages <a,b,c>
Имена директорий пакетов через запятую вместо интерактивного чекбокса — для скриптов. Неизвестные имена выводятся как предупреждение и пропускаются.
--yes
Пропустить подтверждение «proceed?».
--wait-checks
Дождаться CI-проверок PR (если они настроены) перед merge; не мёрджить, если проверки не прошли.
Пример:
# сначала dry run — ничего не пушится, не коммитится, не мёрджится и не тегается
polyrepo bump --dry-run
# поднять или продвинуть beta-пререлиз
polyrepo bump --prerelease --preid beta
# начать premajor release candidate (например, 2.0.0-rc.0)
polyrepo bump --major --preid rc
# задать точную версию для одного пакета, например для хотфикса
polyrepo bump --packages os-detect --custom-version 2.1.6-hotfix.1
# полностью неинтерактивно, для скрипта/CI
polyrepo bump --packages vue-toast-kit,os-detect --yestag
Для пакета, версия которого уже была поднята каким-то другим способом (не через bump, либо до того, как он начал тегировать) — release не с чем работать, тега для текущей версии ещё нет. tag ставит недостающий тег на текущую версию без повторного бампа и без открытия PR.
polyrepo tag [options]- Проверяет по каждому пакету (параллельно), существует ли уже тег
v<local version>. - Показывает чекбокс: пакет, версия, тег. Незатегованные пакеты отмечены по умолчанию; уже затегованные тоже можно выбрать вручную (безвредно — просто подтверждает, что тег на месте).
- После подтверждения — для каждого выбранного пакета: синхронизирует основную ветку (так же, как
bump), затем создаёт и пушит тег, если его не хватает. - Если хотя бы один пакет реально был затегован (и это не был
--dry-run) — спрашивает: «Create a GitHub Release for the N package(s) just tagged?» — ответ «да» запускает тот же процесс, что иrelease, но именно для этих пакетов.
Реальный вывод — у текущей версии тег уже есть, так что остаётся только его подтвердить:
[1/1] os-detect v2.1.5
$ git fetch origin
$ git checkout master
Your branch is up to date with 'origin/master'.
Already on 'master'
$ git merge --ff-only origin/master
Already up to date.
✓ master is up to date.
✓ Tag v2.1.5 already exists on origin.Опции
--dry-run
Печатает план; ничего не тегает, не пушит и не релизит.
--packages <a,b,c>
Список пакетов вместо интерактивного чекбокса.
--yes
Пропустить подтверждение «proceed?» (вопрос про релиз тоже пропускается — релиз не создаётся, пока не указан --release).
--release
Создать релиз сразу после тегирования, без вопроса — для скриптов.
Пример:
polyrepo tag --packages vue-toast-kit,os-detect --yes --releaserelease
Выбор пакетов и создание GitHub Release для тега их текущей версии.
polyrepo release [options]- Проверяет по каждому пакету (параллельно) наличие тега
v<local version>на origin (того самого, что создаётbumpилиtag), и есть ли у этого тега уже GitHub Release. - Показывает чекбокс: пакет и его тег. Пакеты без тега для текущей версии показаны недоступными для выбора («run
bumpfirst»); уже зарелиженные — доступны, но не отмечены по умолчанию, на случай если нужно повторить. - После подтверждения — для каждого выбранного пакета:
gh release create <tag> --verify-tag—--verify-tagгарантирует, что команда никогда не придумает новый тег, а всегда использует уже существующий. Текст релиза берётся из соответствующего разделаCHANGELOG.md, если он есть, иначе — из--generate-notes.
Реальный вывод:
[1/1] os-detect v2.1.5
✓ No changelog entry — using --generate-notes.
$ gh release create v2.1.5 --verify-tag --title os-detect@2.1.5 --generate-notes
✓ Created release os-detect@2.1.5.Опции
--dry-run
Печатает, что было бы создано, ничего реально не создавая.
--packages <a,b,c>
Список пакетов вместо интерактивного чекбокса.
--yes
Пропустить подтверждение «proceed?».
Пример:
polyrepo release --packages vue-toast-kit,os-detect --yespublish
Выбор пакетов и запуск npm publish — по умолчанию отмечены те, что обогнали реестр.
polyrepo publish [options]- Проверяет версию каждого пакета в реестре (
npm view <pkg> version) в сравнении с локальной версией — параллельно. - Показывает чекбокс: версия в реестре → локальная версия. Пакеты, у которых они различаются, отмечены по умолчанию; уже опубликованные остаются доступны для выбора (например, чтобы republish после unpublish).
- После подтверждения — один раз для всей партии (пропускается под
--dry-run) проверяетnpm whoami— если логин не активен, запускаетnpm login(в реальном терминале, так что и браузерный OTP-флоу, и обычный запрос учётных данных работают как обычно) до начала публикации, вместо того чтобы узнать об этом только на середине публикации первого пакета. - Для каждого выбранного пакета по одному:
npm publish(либоnpm publish --dry-runс флагом--dry-run). Работает с реальным терминалом, без перехвата вывода — запрос 2FA/OTP от npm работает как обычно.
Реальный вывод — средняя часть это собственный вывод сборки/тестов/упаковки самого npm для этого пакета, показанный вживую в реальном терминале, а не то, что polyrepo как-то перехватывает или переформатирует:
[1/1] os-detect@2.1.5
$ npm publish --dry-run
… (сборка и тесты самого пакета, список содержимого тарбола от npm)
✓ Published os-detect@2.1.5 (dry run).Опции
--dry-run
npm publish --dry-run вместо реальной публикации.
--packages <a,b,c>
Список пакетов вместо интерактивного чекбокса.
--yes
Пропустить подтверждение «proceed?».
Пример:
polyrepo publish --packages vue-toast-kit,os-detect --yes