All posts
5 min read

How to Update Your App's Dependencies Safely

The packages your app is built on get security fixes and new versions constantly. Ignore them and you accumulate risk; update carelessly and the app breaks. What version numbers mean, a safe routine for updating, how to handle security warnings, and how to let an AI do the tedious part.

getting startedtoolingsecuritybeginner

Your app is built on dozens or hundreds of packages written by other people. (What Are npm and package.json?) Those packages keep changing: bug fixes, security patches, new features, and occasionally changes that break things.

Leave them alone for a year and you'll have known security holes, and updating will be a painful leap. Update everything at once without checking and something will break. The trick is a steady, safe routine.

What version numbers mean

Most packages use semantic versioning: three numbers, MAJOR.MINOR.PATCH.

  4 . 21 . 3
  │    │    └── PATCH: bug fixes. Should never break anything.
  │    └─────── MINOR: new features, backwards compatible. Shouldn't break anything.
  └──────────── MAJOR: breaking changes. May require changes to your code.

So going from 4.21.3 to 4.21.4 or 4.22.0 should be safe. Going from 4.x to 5.0.0 means "read the upgrade notes first."

"Should" is doing some work there — not every package author follows the rules perfectly — which is why you test after every update.

Why updating matters

  • Security fixes. Vulnerabilities are found in popular packages regularly. Updates fix them.
  • Staying close is easier than catching up. Small, regular updates are easy. Jumping three major versions at once can take days.
  • Compatibility. Hosting platforms and runtimes move on; very old packages stop working with them.
  • AI tools know current versions. An app on very old versions confuses AI assistants, which write code for newer ones.

A safe routine

1. Start from a clean, saved state

Commit everything first, so you can undo the update if it goes wrong. Even better, do it on a branch. (Git and GitHub for Beginners)

2. See what's out of date

npm outdated

This lists each package with its current version, the newest version your package.json allows (wanted), and the newest version that exists (latest).

3. Do the safe updates first

npm update

This updates packages within the ranges in your package.json — typically patch and minor versions. Then:

4. Test

  • Run the app and click through the main journeys.
  • Run the build: npm run build. Many problems only show up there.
  • Run any automated tests you have.

If everything works, commit: "Update dependencies (minor/patch)."

5. Major updates, one at a time

For each major update:

  1. Read the package's changelog or upgrade guide — search for "[package name] upgrade guide" or "migration guide."
  2. Update just that package: npm install package-name@latest.
  3. Fix what the upgrade guide says to change.
  4. Test, then commit.

One major upgrade per commit means if something breaks, you know exactly which one caused it.

6. Deploy and watch

Deploy, then keep an eye on errors for a day. (How to Know When Your App Is Down.)

Security warnings

npm install often ends with a message like "5 vulnerabilities (2 moderate, 3 high)." Don't panic, and don't ignore it forever.

npm audit

shows details: which package, how serious, and whether a fix exists.

A few things to know:

  • Many reports are in development tools that never run in your live app. Still worth fixing, less urgent.
  • npm audit fix applies safe fixes. Run it, then test.
  • Be careful with npm audit fix --force — it can make major version jumps that break your app. Treat it like a major update: branch, test, commit.
  • Serious, reachable vulnerabilities in packages your live app uses — especially anything handling login, uploads, or user input — deserve prompt attention.

Let tools do the tedious part

GitHub's Dependabot (and similar tools like Renovate) can watch your dependencies and automatically open a pull request when updates or security fixes are available. Each PR updates one thing and, if you have automated checks, runs them. You review and merge. It turns updating from a chore into a steady trickle of small, easy decisions. (What Is a Pull Request?)

AI coding agents are also good at this. A prompt that works well:

Check for outdated dependencies. Apply patch and minor updates, run the build and tests, and report any failures. For major updates, list each one with what changed and what we'd need to modify — don't apply them yet.

Then apply the major ones one at a time, with the agent reading the upgrade guide for each.

Keep the lockfile

Always commit package-lock.json (or your tool's lockfile). It records exactly which versions you tested, so your live app installs the same ones. (What Are npm and package.json?)

How often?

  • Security fixes: soon after you hear about them.
  • Minor and patch updates: monthly is a good rhythm.
  • Major updates: when you have time to do them properly — but don't let them pile up for years.

The summary

  1. Commit first (or use a branch).
  2. npm outdated → npm update → test → commit.
  3. Major updates one at a time, with the upgrade guide.
  4. npm audit for security; be careful with --force.
  5. Let Dependabot or an AI agent do the tedious part.

EasySpawn runs Claude Code in a workspace with your app, its tests, and its database all present — so it can update dependencies, run the build and tests, and open a pull request with the results. See how it works or join the waitlist.

Related: What Are npm and package.json? · Set Up CI With GitHub Actions · Semantic Versioning Explained · npm Supply Chain Security

Keep reading