Check and update npm dependencies

Start with npm outdated to compare installed packages with versions allowed by your manifest and the registry's latest tag. Then choose whether to update within the current range or deliberately change that range.

Read the version columns

npm outdated
npm outdated --all

The default report focuses on direct dependencies; --all also includes dependencies deeper in the tree.

Latest is not necessarily the numerically highest published version. A prerelease or a separately tagged release may have a higher number. An outdated report is also not a security advisory or a proof that an upgrade is necessary.

Update within the existing range

npm update
# Or select one package:
npm update lodash

The resolver respects the applicable semver constraints. For a typical caret range on a stable major, that usually prevents crossing the major boundary. Broad ranges such as * can permit major changes, and zero-major ranges have their own rules. Even a version allowed by a range can introduce a regression.

Inspect the resulting lockfile and any manifest changes, then run the project's tests and build. Do not assume that an update changes only one physical directory: dependency resolution can adjust transitive packages too.

Deliberately change allowed versions

To select a new target explicitly:

npm install lodash@latest

Read the project's release notes before a major upgrade. npm-check-updates can help review broader changes:

npx npm-check-updates
npx npm-check-updates -u
npm install

The first command previews proposed manifest updates. -u writes them to package.json; installation is a separate step. Because npx may download and execute a tool, choose a trusted release and pin it when repeatability matters. Interactive tools such as npm-check offer another workflow, while Dependabot or Renovate can prepare recurring upgrade proposals.

Keep security and release checks separate

npm audit reports known advisories for the resolved dependency graph. npm audit fix can install changes, and --force can allow changes outside existing ranges; neither is an unconditional safe repair. Review advisories, reachability, breaking changes, and the resulting diff.

For a controlled rollout, commit the manifest and lockfile together, run tests against the resolved tree, and deploy the tested artifact. Monitor application errors and latency after deployment. A rollback needs a known-good artifact and compatible application state, not just an older lockfile.

Why does npm update leave a package behind latest? Its declared range or another dependency constraint may exclude that version. Inspect the graph and change the constraint only when you intend to accept the new compatibility requirements.

See npm outdated, npm update, and npm-check-updates.