Polyrepo CLI

Интерактивный CLI для управления папкой локальных npm-пакетов: бамп версии через pull request, публикация в npm, GitHub Releases и отслеживание рассинхронизации зависимостей между пакетами — всё из одного инструмента, и всё можно предварительно проверить через --dry-run, прежде чем что-то реально изменится.

Возможности

• setup — добавление, редактирование и удаление директорий с пакетами, которые сканирует CLI, прямо из терминала.
• clone — сверяет список репозиториев GitHub-организации/пользователя с тем, что уже склонировано локально, и клонирует недостающее.
• list — одна таблица по всем пакетам: версия, ветка, git-статус, git-тег, GitHub Release, статус в npm-реестре и рассинхронизация зависимостей между локальными пакетами. --quick пропускает сетевые проверки ради мгновенного вывода версии/ветки/git-статуса; --output сохраняет ту же таблицу в Markdown, JSON, CSV или HTML.
• outdated — одна таблица устаревших зависимостей по всем пакетам сразу, сгруппированная по пакетам, с раскраской колонки Latest по тому, насколько версия отстала (major/minor/patch).
• audit — одна таблица уязвимостей npm по всем пакетам сразу, сгруппированная по пакетам, с раскраской по критичности (critical/high/moderate/low) и отметкой, есть ли готовый фикс.
• prs — одна таблица всех открытых pull request'ов по всем пакетам.
• doctor — проверка состояния из семи разделов с несколькими безопасными автофиксами по пути: окружение (Node/git/gh/npm), дрейф основной ветки от реального состояния на GitHub, устаревшие remote-tracking ссылки, расхождение с origin, состояние detached HEAD, отсутствие защиты ветки и мёртвые ветки после прошлых релизов (--clean-branches превращает последний пункт в интерактивную чистку).
• switch-default — подтягивает выбранные репозитории до актуальной основной ветки — какой бы она ни называлась, master, main или как-то иначе (определяется отдельно для каждого репозитория, а не предполагается заранее). --force/--clean — для полного сброса репозитория, когда он действительно нужен.
• bump — поднимает версию пакета (по умолчанию patch; либо --minor/--major; либо --prerelease/--preid для старта или продвижения пререлиза; либо --custom-version для точной версии) через ветку → PR → merge, затем ставит тег релиза. Безопасно перезапускать, если предыдущая попытка прервалась на середине — процесс продолжается с того места, где остановился. Сам пишет черновик записи в CHANGELOG.md, если у пакета такой файл уже есть.
• publish — запускает npm publish только для тех пакетов, что реально обогнали реестр, предварительно проверяя (и при необходимости обновляя) логин в npm.
• tag — ставит тег на текущую версию пакета без повторного бампа, если версия уже была поднята каким-то другим способом. Сразу после предлагает создать GitHub Release.
• release — создаёт GitHub Release из тега, с текстом релиза из соответствующего раздела CHANGELOG.md, если он есть.
• exec — прогоняет любую команду по каждому выбранному пакету, один за другим, с реальным терминалом.
• Любая команда, затрагивающая несколько репозиториев, поддерживает --packages и --yes для полностью неинтерактивного использования в скриптах.

Как это работает

Каждая команда читает один и тот же список репозиториев из одного конфиг-файла (roots — папки, каждая подпапка которых является отдельным пакетом; packages — отдельные папки репозиториев). Список настраивается один раз через setup, после чего всё остальное работает с ним же.

Read-only проверки (git-статус, теги, релизы, состояние реестра, статус PR) выполняются по всем репозиториям параллельно, поэтому полный list или doctor по многим пакетам работает быстро, а не ждёт каждый репозиторий по очереди. А вот всё, что реально меняет состояние — коммит, push, merge, тег — выполняется по одному репозиторию за раз, с выводом каждого шага по мере его выполнения. bump отдельно отслеживает, как далеко зашла предыдущая попытка (запушена ли ветка? открыт ли PR? смёрджен ли он?), так что повторный запуск после прерывания продолжается с нужного места вместо падения на «ветка уже существует» или создания дублирующего PR.