How to review dependency updates without reflex-merging

Renovate and Dependabot turned dependency maintenance into a stream of small, identical-looking pull requests, and most teams responded by developing a merge reflex: green CI, click, next. The reflex is understandable, and for plenty of updates it is even correct. The problem is applying it uniformly, because that means you review dependency updates with the least attention exactly where breaking changes and supply-chain attacks concentrate. The fix is not reviewing harder across the board. It is deciding, before you open the PR at all, how much scrutiny this particular update has earned.

Why the merge reflex exists

Volume, mostly. A bot can open fifteen PRs on a Monday morning, and each one looks the same: two changed lines in a manifest and a wall of lockfile churn. SmartBear’s peer review research suggests keeping a review session under roughly 400 lines of code; a single lockfile regeneration can blow past that by an order of magnitude, so reviewers read none of it. When every update looks equally unreadable, every update gets the same three seconds. The reflex is not laziness. It is what happens when the process gives you no way to tell a boring update from a dangerous one.

Tier the update before you open it

Two questions sort almost every dependency PR: how big is the version jump, and how much do you trust what the package can reach?

• Tier 0: patch or minor bumps of dev-only tooling (linters, formatters, test runners) in a repo with real CI. The blast radius is your build, not your users.
• Tier 1: minor bumps of runtime dependencies. Skim the changelog, glance at the lockfile, merge.
• Tier 2: major versions, anything in the auth, crypto, networking, or serialization path, and any update that runs install scripts or pulls new packages into the tree. This one is a real review.

This is the same reasoning as reviewing by blast radius generally: effort should follow consequences, not diff size. A patch bump of a formatter and a major of your OAuth client produce nearly identical diffs and have nothing else in common. Treat tier 2 updates of security-relevant libraries with the rigor of security-critical code, because that is what they are: code you are choosing to run with your users’ credentials in scope.

A checklist to review dependency updates

• Read the changelog, not the version number. Release notes and migration guides say what actually changed; the semver bump only says what the maintainer believes changed. For majors, read the breaking-changes section before you read any diff.
• Distinguish lockfile-only from manifest changes. A lockfile-only bump stays inside version ranges you already declared. A manifest change is a new contract. They look alike and mean different things.
• Watch for new transitive packages. Every new name entering the tree is new supply-chain surface: a maintainer you now trust by default. A patch bump that adds six unfamiliar packages deserves more attention than a major that adds none.
• Check for install scripts. A postinstall hook executes on every developer machine and CI runner. It is the classic delivery mechanism for a compromised package.
• Note license changes. Rare, but a dependency relicensing from MIT to something restrictive is a legal change your project inherits silently.

Batch by tier, not by weekday

Batching is fine; blending is not. Group tier 0 updates into a weekly rollup so they cost one review instead of ten, but never let a tier 2 update ride into main inside a batch of fourteen boring ones. Give majors their own PR so the changelog reading has somewhere to happen, and so a revert removes one change instead of fifteen. Reading the risky ones is also partly a tooling problem: a raw lockfile wall hides the three lines that matter, and a review surface that groups the diff and separates manifest changes from lock churn makes the five minutes count. That is part of why we built Pyor (ours). But tiering beats tooling: even on plain GitHub, splitting the batch is most of the win.

When the reflex is the right call

Reflex-merging is genuinely fine for tier 0, provided the reflex is a policy rather than a mood. A patch bump of a well-tested dev dependency, in a repo whose CI actually exercises the affected path, does not need human eyes; it needs an automerge rule that names the packages and the version jumps it covers. The difference between a reflex and a policy is that a policy has edges: it says exactly which updates skip review, which means everything outside the edge gets one. The failure mode of dependency review is not merging fast. It is never deciding which updates deserve slowness, and letting fatigue decide for you.