VueCraft NPM

Релиз и публикация ​

Полный цикл релиза: поднять версию через PR/MR, поставить тег, создать релиз и опубликовать в npm — четыре отдельных, компонуемых шага. Бампнуть партию пакетов и затем опубликовать или зарелизить только часть из них — разные по смыслу решения, которые не всегда происходят одновременно, поэтому они никогда не объединены принудительно. Работает с GitHub и GitLab, автоматически определяемыми для каждого репозитория — см. «Конфиг и поиск репозиториев».

bump ​

Выбор пакетов, поднятие версии (по умолчанию patch), открытие PR/MR, merge в основную ветку и тег релиза.

bash
polyrepo bump [options]
  1. Показывает чекбокс пакетов с текущей версией и версией, до которой она поднимется (1.2.9 → 1.2.10 для patch-бампа — --minor/--major поднимают другую часть версии, обнуляя всё, что ниже, как у любого semver-инструмента). Пакеты с грязным рабочим деревом помечены — они будут пропущены. В описании подсвеченного пакета показано, что реально изменилось с последнего git-тега — вычисляется для всех пакетов параллельно.
  2. После подтверждения — для каждого выбранного пакета по одному:
    1. git fetch origin → git checkout <default branch> → git merge --ff-only origin/<default branch> (bump-ветка всегда создаётся от актуальной основной ветки, а не от той, на которой репозиторий случайно оказался);
    2. проверяет состояние предыдущей попытки — есть ли уже смёрдженный PR/MR, открытый, либо просто запушенная ветка с именем <new-version>-version-bump. В зависимости от того, что найдено, процесс продолжается с нужного места вместо падения на «ветка уже существует» или создания дубликата;
    3. если package.json на ветке ещё не бампнут — поле "version" обновляется (текстовая замена — форматирование и порядок полей не трогаются). Если у пакета уже есть CHANGELOG.md, туда же добавляется черновик записи ## [x.y.z] - YYYY-MM-DD (в стиле Keep a Changelog) со списком коммитов с последнего тега — черновик для правки, не готовый changelog;
    4. gh pr create (GitHub) либо glab mr create (GitLab) в основную ветку (если PR/MR ещё не существует);
    5. с --wait-checks: ожидание CI перед merge — механизм отличается по хостингу, см. описание опции ниже; отсутствие настроенных проверок не считается ошибкой;
    6. gh pr merge / glab mr merge — через PR/MR, не прямым push;
    7. локальная основная ветка синхронизируется с только что смёрдженным PR/MR;
    8. git-тег v<new-version> создаётся и пушится, если его ещё нет.
  3. Любая ошибка на этом пути помечает пакет ✗ с понятным сообщением, и процесс переходит к следующему пакету, не прерывая весь запуск целиком.
  4. После обработки всех выбранных пакетов — отдельная проверка по всем пакетам (не только только что бампнутым): не остался ли у какого-то локального пакета диапазон зависимости, не соответствующий новой версии бампнутого пакета — ничего не меняется автоматически.

Реальный вывод — --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.

(На GitLab-репозитории это выглядит так же, но с «MR» вместо «PR» — провайдерный слой сам подставляет нужную метку, независимо от хостинга.)

--prerelease, либо --preid в паре с --major/--minor, вычисляют целевую версию иначе, но проходят через те же самые шаги ветка → PR/MR → 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 перед merge; не мёрджить, если проверки не прошли. На GitHub это gh pr checks --watch, привязанный к PR. У GitLab нет аналога, привязанного к MR — вместо этого используется glab ci status --branch --wait для пайплайна bump-ветки, суть та же. Отсутствие настроенных проверок не считается ошибкой в обоих случаях — просто нечего ждать.

Пример:

bash
# сначала 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 --yes

tag ​

Для пакета, версия которого уже была поднята каким-то другим способом (не через bump, либо до того, как он начал тегировать) — release не с чем работать, тега для текущей версии ещё нет. tag ставит недостающий тег на текущую версию без повторного бампа и без открытия PR/MR.

bash
polyrepo tag [options]
  1. Проверяет по каждому пакету (параллельно), существует ли уже тег v<local version>.
  2. Показывает чекбокс: пакет, версия, тег. Незатегованные пакеты отмечены по умолчанию; уже затегованные тоже можно выбрать вручную (безвредно — просто подтверждает, что тег на месте).
  3. После подтверждения — для каждого выбранного пакета: синхронизирует основную ветку (так же, как bump), затем создаёт и пушит тег, если его не хватает.
  4. Если хотя бы один пакет реально был затегован (и это не был --dry-run) — спрашивает: «Create a 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 ​

Создать релиз сразу после тегирования, без вопроса — для скриптов.

Пример:

bash
polyrepo tag --packages vue-toast-kit,os-detect --yes --release

release ​

Выбор пакетов и создание релиза для тега их текущей версии.

bash
polyrepo release [options]
  1. Проверяет по каждому пакету (параллельно) наличие тега v<local version> на origin (того самого, что создаёт bump или tag), и есть ли у этого тега уже релиз.
  2. Показывает чекбокс: пакет и его тег. Пакеты без тега для текущей версии показаны недоступными для выбора («run bump first»); уже зарелиженные — доступны, но не отмечены по умолчанию, на случай если нужно повторить.
  3. После подтверждения — для каждого выбранного пакета: gh release create <tag> --verify-tag (GitHub) либо glab release create <tag> (GitLab) — чекбокс и так предлагает только пакеты с уже существующим тегом, так что новый тег никогда не придумывается; --verify-tag у GitHub — это вторая, собственная гарантия того же самого, у GitLab такого флага нет. Текст релиза берётся из соответствующего раздела CHANGELOG.md, если он есть. Иначе — на GitHub --generate-notes (сводка по смёрдженным PR/коммитам); у GitLab аналога нет, поэтому вместо этого используется простой список коммитов с последнего тега.

Реальный вывод — на GitHub-репозитории:

[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?».

Пример:

bash
polyrepo release --packages vue-toast-kit,os-detect --yes

publish ​

Выбор пакетов и запуск npm publish — по умолчанию отмечены те, что обогнали реестр.

bash
polyrepo publish [options]
  1. Проверяет версию каждого пакета в реестре (npm view <pkg> version) в сравнении с локальной версией — параллельно.
  2. Показывает чекбокс: версия в реестре → локальная версия. Пакеты, у которых они различаются, отмечены по умолчанию; уже опубликованные остаются доступны для выбора (например, чтобы republish после unpublish).
  3. После подтверждения — один раз для всей партии (пропускается под --dry-run) проверяет npm whoami — если логин не активен, запускает npm login (в реальном терминале, так что и браузерный OTP-флоу, и обычный запрос учётных данных работают как обычно) до начала публикации, вместо того чтобы узнать об этом только на середине публикации первого пакета.
  4. Для каждого выбранного пакета по одному: 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?».

Пример:

bash
polyrepo publish --packages vue-toast-kit,os-detect --yes