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

Dependabot «з коробки» непридатний для сольного розробника. Вмикаєш із дефолтними налаштуваннями — і отримуєш 20–30 PR на тиждень. Один на залежність, кожен потребує рев'ю, запуску CI та мерджу. Ніхто це не підтримує. Або ти спалюєш години на dependency 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 version bump означає breaking changes. Ти хочеш бачити кожен окремо, щоб:

Прочитати migration guide
Перевірити, чи твій код використовує застарілі API
Ретельно протестувати
Мерджити по одному

Групування major-оновлень ховає, яка саме зміна зламала білд. Тримай їх окремо.

GitHub Actions: щомісяця

Оновлення action-ів — низький ризик і нечасто. Щомісяця достатньо. Групуй усі — якщо CI проходить, мердж.

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

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

Мій тижневий ритуал

Понеділок зранку: Dependabot за ніч створює згруповані PR-и. Переглядаю їх із кавою.

Minor + patch PR: перевіряю статус CI. Зелений? Мердж. Червоний? Дивлюсь, яка залежність зламала, відкриваю issue або піную версію.
Next.js + React PR (якщо є): читаю changelog, запускаю dev server локально на 5 хвилин, перевіряю Lighthouse. Мердж, якщо все чисто.
Major PR-и (якщо є): планую на пізніше цього тижня, коли матиму час розібратись із потенційними зламами.

Загальний час: 10–15 хвилин. Порівняно з 2+ годинами без групування.

Сповіщення про безпеку

Dependabot security alerts — це окремо від запланованих оновлень. Вони спрацьовують миттєво, коли публікується вразливість. Вони обходять тижневий розклад — і це правильно.

Для security alerts у мене інша політика:

Critical/High severity: виправляю того ж дня. Зазвичай це означає мердж security PR або ручний bump залежності.
Medium severity: виправляю протягом тижня.
Low severity: об'єдную з наступним тижневим PR.

Що я не використовую

Renovate. Renovate більш конфігурований за Dependabot, але ця конфігурованість — це складність. Для сольного розробника з 1–5 проєктами функції групування Dependabot (доданої у 2023) достатньо. Renovate має сенс для команд, що керують 50+ репозиторіями зі спільним конфігом.

Auto-merge. Деякі команди автоматично мерджать minor/patch оновлення, коли CI проходить. Я ні — хочу бачити, що змінюється, навіть якщо мерджу за 10 секунд. Один поганий auto-merge непомітно зламаної залежності коштує більше часу, ніж місяці ручних 10-секундних рев'ю.

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

Питання `package-lock.json`

Dependabot оновлює package-lock.json у своїх PR-ах. Це правильна поведінка — lock-файл має відображати оновлені версії. Якщо бачиш великі diff-и у lock-файлі — це нормально для дерев залежностей.

Одна річ, за якою варто стежити: якщо Dependabot PR змінює тільки package-lock.json (без змін у package.json) — це оновлення транзитивної залежності. Зазвичай безпечно, але іноді може викликати проблеми. CI ловить більшість із них.

Старт із нуля

Якщо у тебе є проєкт без конфігурації Dependabot і ти не оновлював залежності місяцями:

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

Стартувати з Dependabot із нуля — як відкрити пожежний гідрант. Спочатку оновись вручну, потім автоматизуй.

Хочеш, щоб залежності керувались без шуму? Пиши — я налаштовую workflows розробки з урахуванням безпеки на кожному клієнтському проєкті.