Dependabot для соло-разработчика: сгруппированный конфиг, который я реально использую

Dependabot из коробки непригоден для соло-разработчика. Включи его с настройками по умолчанию — получишь 20–30 PR в неделю: по одному на каждую зависимость, каждый требует ревью, прогона CI и мержа. Никто так не поддерживает. Либо тратишь часы на PR с зависимостями, либо начинаешь их полностью игнорировать.

Оба исхода плохи. Вот конфиг, который делает Dependabot полезным: 2–3 сгруппированных PR в неделю, которые можно отревьюить за 10 минут.

Конфиг

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: npm
    directory: /
    schedule:
      interval: weekly
      day: monday
    groups:
      # Группа 1: Minor и patch обновления (безопасно мержить)
      minor-and-patch:
        update-types:
          - minor
          - patch
        exclude-patterns:
          - 'next'
          - 'react'
          - 'react-dom'
          - '@types/react'
          - '@types/react-dom'

      # Группа 2: Next.js + React вместе (тестировать внимательно)
      next-react:
        patterns:
          - 'next'
          - 'react'
          - 'react-dom'
          - '@types/react'
          - '@types/react-dom'

    # Major версии: отдельные PR (breaking changes требуют внимания)
    # Это поведение по умолчанию — majors НЕ группируются

    open-pull-requests-limit: 5
    reviewers:
      - your-github-username

  - package-ecosystem: github-actions
    directory: /
    schedule:
      interval: monthly
    groups:
      actions:
        patterns:
          - '*'

Почему именно такая группировка

Группа 1: Minor + patch (основная масса)

Большинство обновлений зависимостей — это minor и patch версии. Semver говорит, что они не должны ничего ломать. На практике — редко ломают. Объединение их в один еженедельный PR означает:

Один прогон CI вместо 20
Одно ревью вместо 20
Один мерж вместо 20

CI прошёл — мержи. Упал — смотри, какая зависимость виновата: описание PR перечисляет все обновления.

Группа 2: Next.js + React закреплены вместе

Next.js и React имеют тесную версионную связь. Обновить Next.js без React (или наоборот) может сломать билд. Группировка гарантирует, что они обновляются вместе.

Такие обновления требуют больше внимания — читай changelog, проверяй breaking changes, тестируй локально. Но это один PR на ревью, а не четыре.

Major версии: отдельные PR

Major-обновления означают breaking changes. Ты хочешь видеть каждое из них по отдельности, чтобы:

Прочитать гайд по миграции
Проверить, использует ли твой код deprecated API
Тщательно протестировать
Мержить по одному

Группировка major-обновлений скрывает, какое именно изменение сломало билд. Держи их отдельно.

GitHub Actions: ежемесячно

Обновления actions — низкий риск и редкие. Раз в месяц — достаточно. Группируй все — CI прошёл, мержи.

`exclude-patterns` для Next.js/React

Без исключения Next.js и React из группы minor-and-patch они попадут в общую кучу. Minor-обновление Next.js часто требует тестирования — это не тот же уровень риска, что бамп date-fns с 3.6.0 до 3.6.1.

Моя еженедельная рутина

Понедельник утром: Dependabot создаёт сгруппированные PR за ночь. Я смотрю их за кофе.

PR minor + patch: смотрю статус CI. Зелёный? Мерж. Красный? Разбираюсь, какая зависимость упала, открываю issue или пиню версию.
PR Next.js + React (если есть): читаю changelog, гоняю dev-сервер локально 5 минут, проверяю Lighthouse. Мерж, если всё чисто.
Major PR (если есть): откладываю на конец недели, когда есть время разобраться с возможными поломками.

Итого: 10–15 минут. Было 2+ часа без группировки.

Security-алерты

Security-алерты Dependabot — это отдельно от запланированных обновлений. Они срабатывают немедленно при публикации уязвимости. Они обходят еженедельное расписание — и правильно делают.

Для security-алертов у меня другая политика:

Critical/High severity: чиню в тот же день. Обычно означает мерж security PR или ручной бамп зависимости.
Medium severity: чиню в течение недели.
Low severity: складываю в следующий еженедельный PR.

Что я не использую

Renovate. Renovate более конфигурируемый, чем Dependabot, но эта конфигурируемость — сложность. Для соло-разработчика на 1–5 проектах функции группировки Dependabot (добавлены в 2023 году) достаточно. Renovate имеет смысл для команд, управляющих 50+ репозиториями с общей конфигурацией.

Auto-merge. Некоторые команды автомержат minor/patch обновления при прохождении CI. Я не делаю — хочу видеть, что меняется, даже если мержу за 10 секунд. Один плохой автомерж незаметно сломанной зависимости стоит больше времени, чем месяцы ручных 10-секундных ревью.

Полный пин версий. Пин фиксирует тебя на точных версиях и отключает все автоматические обновления. Ты меняешь «слишком много PR» на «нулевую видимость security-уязвимостей». Диапазоны с lock-файлами (package-lock.json) дают воспроизводимые билды без потери видимости обновлений.

Вопрос `package-lock.json`

Dependabot обновляет package-lock.json в своих PR. Это корректное поведение — lock-файл должен отражать обновлённые версии. Если видишь большие диффы в lock-файле — это нормально для деревьев зависимостей.

Одно, за чем стоит следить: если PR Dependabot меняет только package-lock.json (без изменений в package.json), это обновление транзитивной зависимости. Обычно безопасно, но иногда может вызвать проблемы. CI ловит большинство из них.

Старт с нуля

Если у тебя есть проект без конфига Dependabot и зависимости не обновлялись месяцами:

Не включай Dependabot пока — сразу получишь 50+ PR.
Запусти npm outdated, чтобы увидеть, что отстало.
Вручную обнови всё за одну сессию: npm update для minor/patch, затем major-обновления по одному.
Исправь поломки.
Теперь включай Dependabot с конфигом выше. Еженедельные PR будут управляемыми, потому что ты стартуешь с чистого состояния.

Стартовать с нуля с Dependabot — всё равно что открыть пожарный кран. Сначала обнови, потом автоматизируй.

Хочешь управлять зависимостями без шума? Давай поговорим — я настраиваю security-ориентированные рабочие процессы на каждом клиентском проекте.