VueCraft NPM

Коммит изменений ​

polyrepo commit — коммит того, что npm audit fix, npm update или sync-deps оставили в рабочем дереве репозитория, так, как это разрешает сам репозиторий.

bash
polyrepo commit [options]

Многие репозитории не принимают коммиты прямо в основную ветку: правило на хостинге требует сначала pull (merge) request. Тогда обычные git commit и git push падают в самом конце, а работа остаётся на локальной master, которую уже не отправить. commit смотрит на правила до коммита и выбирает путь, который будет принят.

  1. Показывает чекбоксом репозитории с незакоммиченными изменениями в package.json или lock-файлах (--scope all расширяет это до всех отслеживаемых изменений); --packages пропускает список.
  2. Спрашивает сообщение коммита (по умолчанию chore: update dependencies; с --yes и без --message берётся оно). Сообщение также становится заголовком pull request'а.
  3. Для каждого выбранного репозитория по одному решает, куда пойдёт коммит (см. ниже), и, если не указан --yes, сначала просит подтвердить именно этот маршрут.

Куда пойдёт коммит ​

  • На feature-ветке (любой, кроме основной) коммит просто ложится туда и отправляется.
  • На основной ветке polyrepo читает правила хостинга и выбирает:
    • Прямые коммиты разрешены — коммит на основную ветку и push.
    • Нужен pull/merge request или правила прочитать не удалось — создаётся ветка (chore/<сообщение>-<дата>, либо --branch), коммит ложится туда, ветка отправляется, открывается PR/MR в основную ветку, после чего команда возвращается на основную ветку, которая остаётся ровно такой, какой была. Сам PR/MR эта команда никогда не вливает: его проверяют на хостинге.
  • Прямой push, который хостинг всё же отклонил (правила читаются не всегда, а некоторые хостинги отказывают только в момент push), исправляется автоматически: коммит переносится в ветку, локальная основная ветка возвращается на origin, открывается PR/MR. Это происходит, только если этот коммит — единственное, что локальная основная ветка имеет сверх origin; иначе ничего не переносится, а сообщение говорит, что сделать руками.

Что считается правилом ​

  • GitHub — rulesets репозитория, которые требуют pull request, проверки статуса или ограничивают обновления; классическая защита ветки с обязательными ревью, проверками статуса или ограничением push. Rulesets читаются обычным доступом, классическая защита только с правами администратора, поэтому защищённая ветка, правила которой вам скрыты, считается «неизвестной», а неизвестная всегда идёт через ветку.
  • GitLab — уровень доступа на push у защищённой ветки в сравнении с вашей ролью в проекте. «Пушить могут только Maintainers» означает merge request для Developer; «никто» — merge request для всех.

Опции ​

--message <text> (-m) ​

Сообщение коммита и заголовок PR/MR. По умолчанию: chore: update dependencies.

--scope <manifest|all> ​

Что коммитится. manifest (по умолчанию) — package.json и lock-файлы (package-lock.json, npm-shrinkwrap.json, pnpm-lock.yaml, yarn.lock) пакета. all — все отслеживаемые изменения в папке пакета; неотслеживаемые файлы не добавляются никогда.

--mode <auto|direct|branch> ​

Маршрут на основной ветке. auto (по умолчанию) отдаёт решение правилам. direct коммитит и отправляет прямо в основную ветку (а если push отклонён, переходит на ветку). branch всегда использует новую ветку.

--branch <name> ​

Имя новой ветки. По умолчанию: chore/<сообщение>-<дата>, например chore/npm-audit-fix-20261008.

--no-push ​

Только коммит; ничего не отправлять и ничего не открывать.

--no-pr ​

Отправить новую ветку, но не открывать PR/MR.

--stay ​

Остаться на новой ветке, а не возвращаться на основную.

--dry-run ​

Напечатать каждый шаг, ничего не коммитя, не отправляя и не открывая.

--packages <a,b,c> ​

Список пакетов вместо интерактивного чекбокса.

--yes ​

Пропустить подтверждение, а без --message использовать сообщение по умолчанию.

Пример вывода — репозиторий, основная ветка которого требует pull request:

[1/1] color-value-tools
  package.json, package-lock.json → a new branch chore/npm-audit-fix-20261008 and a PR into master
  ✓ master does not take direct commits (a pull request is required (repository rules)).
  ✓ Using a new branch chore/npm-audit-fix-20261008 and a PR.
  $ git checkout -b chore/npm-audit-fix-20261008
  $ git add -- package.json package-lock.json
  $ git commit -m chore: npm audit fix -- package.json package-lock.json
  ✓ Committed package.json, package-lock.json: chore: npm audit fix
  $ git push -u origin chore/npm-audit-fix-20261008
  ✓ Pushed chore/npm-audit-fix-20261008 to origin.
  ✓ Opened PR #12: https://github.com/you/color-value-tools/pull/12
  ✓ Back on master.

Open for review:
  color-value-tools: https://github.com/you/color-value-tools/pull/12

Пример:

bash
polyrepo commit

# один пакет, без вопросов, маршрут выбирают правила
polyrepo commit --packages color-value-tools --yes

# всегда через ветку, отправить её, но PR открыть самому
polyrepo commit --mode branch --no-pr

# сначала посмотреть план
polyrepo commit --dry-run

После слияния PR/MR на хостинге polyrepo switch-default подтягивает локальную основную ветку.

Проблемы и коды выхода ​

  • Нечего коммитить (нет изменений в package.json и lock-файлах): сообщается, код выхода 0. Если изменения в других файлах, используйте --scope all.
  • Неудачные git add, commit, checkout или push сообщаются, а процесс завершается с кодом 1 после того, как испробованы остальные пакеты. Коммит, сделанный до неудачного push, остаётся на своей локальной ветке.
  • Неизвестное значение --scope или --mode: код выхода 2.
  • Тот же сценарий стоит за кнопкой Commit… в веб-интерфейсе, который заодно показывает правила до выбора.