NodeJSUpdating & Auditing Packages

Updating Packages

Dependencies are not "install once and forget". They ship bug fixes, performance gains, and — critically — security patches. But updating carelessly breaks builds. The skill is knowing what changed, how far an update reaches, and which command to use for safe (in-range) updates versus deliberate (cross-major) upgrades.

See what is outdated

Bash
npm outdated
Package      Current   Wanted   Latest  Location
express       4.18.2   4.19.2   4.19.2  my-app
lodash        4.17.20  4.17.21  4.17.21 my-app
typescript     5.3.3    5.3.3    5.4.5   my-app

Column

Meaning

Current

What is installed right now (from the lockfile)

Wanted

The newest version your package.json range allows

Latest

The newest version published, ignoring your range

Wanted vs Latest is the whole story
When `Wanted` < `Latest` (like `typescript` above: wanted 5.3.3, latest 5.4.5), a new version exists but your range (`~5.3.0`) forbids it — taking it means **editing the range**, i.e. a deliberate upgrade. When `Current` < `Wanted`, a safe in-range update is available via `npm update`.
Safe, in-range updates

npm update moves each package to the newest version its package.json range permits, and rewrites the lockfile. It never crosses a boundary your range forbids — so with ^ ranges it will take minors and patches but never a new major:

Bash
npm update                 # update everything within allowed ranges
npm update express         # update just one package, in-range
npm update --save          # also bump the ^ranges in package.json to match
`npm update` will NOT cross a major boundary
With `"express": "^4.18.2"`, `npm update` happily goes to `4.19.2` or `4.99.0`, but never `5.0.0` — the caret locks the major. This is by design: majors may break you. To go to a new major you must explicitly change the range (next section). See [Semantic Versioning](/nodejs/semantic-versioning).
Deliberate major upgrades

Crossing a major is a decision, not a routine. Install the new major explicitly — npm updates the range for you — then read the changelog and run your tests:

Bash
npm install express@5            # jump to the latest 5.x; updates the ^range
npm install express@latest       # jump to whatever "latest" points to
npm install typescript@5.4.5     # pin an exact new version
Tools that handle the busywork
`npx npm-check-updates` (`ncu`) scans for the newest versions and can rewrite your `package.json` ranges in bulk (`ncu -u`), after which you run `npm install`. It is the standard way to do a "bump everything to latest" pass — followed, always, by running the test suite.
Security-driven updates

npm audit cross-references your tree against the advisory database and reports known vulnerabilities. npm audit fix applies the in-range updates that resolve them:

Bash
npm audit                  # report vulnerabilities, severity, and paths
npm audit fix              # auto-update vulnerable deps within ranges
npm audit fix --force      # allow breaking (cross-major) fixes — review after!
`--force` can break you — review every time
Plain `npm audit fix` is safe (in-range only). `--force` permits *breaking* upgrades to patch a vulnerability, which can change APIs your code relies on. Never run it unattended in CI; run it locally, then run your full test suite and read the diff. Deep dive in [Dependency & Secret Security](/nodejs/dependency-security).
A safe update workflow

  • Branch first — never update on main. A failed upgrade should be a discarded branch, not a revert.

  • Run npm outdated to see the landscape; separate in-range bumps from major jumps.

  • Do in-range updates with npm update, commit, run tests.

  • Do majors one at a time — npm install pkg@latest, read its migration guide, fix, test, commit. Bundling majors makes failures impossible to bisect.

  • Automate the noise — tools like Dependabot or Renovate open per-package PRs with changelogs and run CI, so routine bumps review themselves.

Next
npm is not the only package manager — meet the faster, stricter alternatives: [Yarn & pnpm](/nodejs/yarn-pnpm).