What a Year of Dependabot Looks Like When You're the Only Reviewer

backend/package.json and frontend/package.json together list around thirty direct dependencies — express, helmet, express-rate-limit, passport, jsonwebtoken, axios, cheerio on the backend; react, react-router-dom, recharts, axios, undici on the frontend. Every one of those has had at least one version bump over the life of this project, and every one of those bumps was reviewed — or not reviewed, and merged anyway — by the same person who wrote the code it touches. That's the actual discipline question a solo project has to answer that a team project mostly doesn't: nobody else is going to catch a bad merge.

The discipline that matters: reading every PR diff yourself, because nobody else will catch a bad bump.

Version bumps that were never just version bumps

express-rate-limit ^7.4.1 isn't in this project because a dependency update PR silently pulled it in — it's there because it was the fix for CodeQL alert #159, and once it was in, five more routes needed the same treatment before the alert class stopped recurring (a story told in an earlier post in this series). helmet ^8.0.0 similarly traces back to a deliberate hardening pass, not a routine bump. The lesson that generalizes: on a solo project, "check what changed in this dependency" and "check whether this dependency should even be here" end up being the same review pass, because there's no separate security team doing the second one on a different cadence.

--legacy-peer-deps is a maintenance cost that gets paid every CI run

- name: Install dependencies
  run: |
    cd backend && npm install --legacy-peer-deps
    cd ../frontend && npm install --legacy-peer-deps

That flag shows up in the E2E workflow because [email protected] and ajv@^8.17.1 disagree about a transitive peer dependency version, and resolving it "properly" (upgrading off Create React App, which is itself unmaintained) is a bigger project than fixing one CI flag. Commit cf28d0a, "fix: Resolve ajv dependency conflict in frontend build," is the moment that got documented instead of silently worked around — a solo maintainer's version of leaving a comment for the next person, except the next person is future-you six months later wondering why that flag is there.

The bumps you don't remember making are the risky ones

The commits worth being honest about are the ones where a routine dependency bump got merged without much scrutiny because nothing in the CI pipeline flagged it — a patch version of axios or pg, say, that passed the E2E suite and got merged on that basis alone. The E2E suite is thorough for user flows; it says nothing about whether a transitive dependency three levels down introduced a supply-chain risk. That's precisely where CodeQL's weekly schedule earns its keep, independent of anything Dependabot flags directly — a scan that runs regardless of whether a human remembered to look.

What actually holds up a solo review process

Two disciplines, neither glamorous: read the changelog of anything with a major version bump before merging, not just the diff; and treat "the test suite passed" as necessary, not sufficient, for a dependency update touching auth, crypto, or anything CodeQL has previously flagged in that area. Neither is automatable in a way that removes the human from the loop — which is really the honest conclusion of this whole series: CodeQL, Dependabot, Playwright, and the prod-check workflow all reduce how often you have to look carefully, but none of them replace looking carefully. They just make it possible for one person to keep doing that indefinitely without burning out.

Series: Fishing Tracker Pro. This closes out the series — from an environmental-context fishing log for Mauritius, through its solunar recommendation engine and marketing tooling, to a year of hardening it one CodeQL alert at a time.