A dependency-update habit that does not break the build

Written By: BrainSoft In Security

Dependency updates pile up quietly. Nobody touches them for a month, then a security advisory lands and you are staring at forty version bumps at once, half of them with breaking changes. The usual reaction is to bump everything, push, and spend the afternoon fixing a red pipeline.

The habit that works is small and boring: one scheduled slot per week, patch and minor updates batched together, majors handled one at a time on their own branch, and a full test run before anything merges. It keeps the diff readable and the build green.

Why batching everything at once fails

A big update pull request hides the cause of a failure. If twenty packages move and the tests go red, you are bisecting by hand. Small, frequent updates mean a red build points at one or two changes, and you can read the changelog for those two instead of skimming twenty.

The other problem is timing. Updates that land during a release week get rushed. A fixed weekly slot gives you room to actually read what changed.

The weekly routine

Check what is outdated and separate patch, minor, and major.
Update patch and minor versions in one branch and run the full suite.
Open one pull request per major version, with the changelog linked.
Merge only what passes CI and a quick manual smoke test.
Leave a short note in the commit about anything that needed a code change.

For a Node project the first step is a single command:

npm outdated
npm update --save

Then run the tests before you commit anything. If the suite is fast, this is a two-minute check. If it is slow, run the affected packages first and the full suite in CI.

Let a bot do the opening

Dependabot or Renovate will open the pull requests for you on a schedule. The habit is not the tool, it is the review discipline: you still read the diff, you still run the tests, and you do not merge a major on a Friday. Configure the bot to group patch and minor updates so the noise stays low.

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: npm
    directory: "/"
    schedule:
      interval: weekly
    groups:
      minor-and-patch:
        update-types: ["minor", "patch"]

If your team would rather not own this, it fits neatly into the maintenance side of our services.

What to do when a major breaks

Read the migration guide first, not the stack trace. Most majors ship one. If there is no guide, the release notes and the diff of the changed package are usually enough to find the renamed function or the dropped option. Fix it on its own branch, keep the pull request small, and do not mix it with unrelated work.

Pin the version you tested so a surprise patch does not slip in.
Commit the lockfile every time, in the same commit as the manifest change.
If a major is not worth it yet, note why and revisit next quarter.

Frequently asked questions

How often should I update dependencies?

Weekly for patch and minor versions is a good default. It keeps the diffs small enough to review and gives you a predictable slot to fix anything that breaks.

Should I update major versions automatically?

No. Let the bot open the pull request, but treat a major as a small project: read the migration notes, run the tests, and merge it on its own branch.

What if the tests are too slow to run on every update?

Run the tests for the packages that depend on the changed one locally, and let CI run the full suite on the pull request. If the suite is slow enough that this hurts, that is worth fixing separately.

#Security