build(deps): add Dependabot configuration

[vlakoff]

Adds automated dependency update tracking via Dependabot (quickstart guide).

What

Adds .github/dependabot.yml with monthly update checks for:

• Composer (phpunit, spatie packages, etc.)
• npm (pixelmatch)
• GitHub Actions

Why

Dependency updates have been handled manually so far.

For instance, running npm install recently bumped pixelmatch from 7.1.0 to 7.2.0 locally, with no automated mechanism to catch and PR that update.

The same applies to GitHub Actions — without automated updates, action versions tend to go stale silently.

Notes

• Monthly interval chosen given the low dependency count and low churn.

• Dependabot will open one PR per outdated dependency when it triggers. If PR noise becomes an issue, Renovate with grouping would be a good alternative.

  Edit: I later noticed that Dependabot supports grouped updates and added it to the config, so PR noise is no longer a concern — each scheduled run produces at most 2 PRs per ecosystem (one for minor+patch, one for major), and just 1 for GitHub Actions (all updates grouped together).

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 71.72%. Comparing base (4da2233) to head (926d9be).

Additional details and impacted files

@@            Coverage Diff            @@
##               main     #239   +/-   ##
=========================================
  Coverage     71.72%   71.72%           
  Complexity      999      999           
=========================================
  Files            49       49           
  Lines          3158     3158           
=========================================
  Hits           2265     2265           
  Misses          893      893           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[vlakoff]

We could even use quarterly for the schedule intervals (documentation).

Given the low dependency count and low churn, it would lower the maintenance burden further, while remaining active enough.

Feel free to go with whichever intervals feel right.

---

For what it's worth, a small personal note that might help put this in perspective.

I happen to have a recurring administrative task in my own life — nothing complicated, but particularly tedious — and I've noticed that annoyance has a way of accumulating over repetition. Coincidentally, it also comes with exactly this choice: monthly or quarterly. Most people default to monthly, but I went with quarterly from the start, since doing it monthly brings no real benefit other than increasing the frequency.

That choice is what makes the difference between something I could barely stand and something relatively manageable. I'd never go back to monthly.

Of course, the analogy isn't perfect — for a software project, monthly does have a slight edge in theory. But for a maintainer who doesn't want dependency management constantly on their radar, quarterly feels like the better tradeoff.

---

One small caveat worth mentioning: Dependabot enforces a default limit of 5 open PRs at a time per ecosystem (open-pull-requests-limit). If more than 5 updates are available for a given ecosystem when a scheduled run fires, only 5 PRs are created — the rest are deferred until the next scheduled run. That limit exists for a reason (keeping the PR inbox manageable), so raising it isn't really the answer — it just trades one problem for another.

A higher schedule frequency does statistically reduce the chance of hitting the ceiling, and shortens how long deferred updates wait — which is a mild argument in favor of monthly over quarterly.

Either way, the solution is simply to re-trigger Dependabot manually once the initial batch of PRs has been processed, via Insights → Dependency graph → Dependabot → Recent update jobs → Check for updates. It's a manual step, but a straightforward one — the main thing is just remembering to do it.

(I also looked briefly into automating this via a workflow triggered when a Dependabot PR is merged, but it turned out to be surprisingly convoluted — not a path I'd recommend.)

Edit: this caveat is now moot — I later added grouped updates, which cap each scheduled run at 2 PRs per ecosystem (and just 1 for GitHub Actions) regardless of how many dependencies are outdated. The 5-PR-per-ecosystem ceiling, the deferred updates, and the manual re-trigger workaround no longer apply.

[vlakoff]

I noticed we could also cover GitHub Actions — so I've added it to the Dependabot config.

It's easy to overlook: action versions (e.g. actions/checkout@v3) don't update themselves, and many projects just never bump them. Dependabot handles it exactly the same way as Composer or npm — one PR per outdated action, no extra setup needed.

I've updated the commit accordingly.

[vlakoff]

I've updated the config to add grouped updates (see also the announcement in 2023).

This fully resolves the 5-PR ceiling I mentioned above. Instead of Dependabot opening one PR per outdated dependency and quickly hitting the open-pull-requests-limit, updates are now batched: one PR for all minor+patch updates, one PR for all major updates — per ecosystem. In practice, each scheduled run produces at most 2 PRs per ecosystem, regardless of how many dependencies are outdated.

For Composer and npm, major updates are kept in a separate group from minor/patch. Majors can introduce breaking changes and deserve deliberate review; minor and patch are generally safe to merge as a batch.

For GitHub Actions, everything is grouped together with no filter. Actions do follow semver, but major bumps (e.g. actions/checkout@v3 → @v4) are not breaking changes for users — they reflect internal refactors or runtime changes by the action's maintainers, not API changes that affect workflows. Treating all action updates uniformly is the standard practice.