Update npm packages to latest without breaking your app

Updated 2026-11-08

There is no command that updates every npm package and guarantees your app still works. Start from a working commit, choose a small update, and prove the behavior you rely on before merging. “Latest” is a release tag, not a compatibility promise.

This guide is for a JavaScript or TypeScript app in a public GitHub repository. The commands below use npm and a committed package-lock.json. If the project uses pnpm or Yarn, keep that manager and its lockfile; do not create an npm lockfile to follow an example. Check the repository’s setup instructions and pinned tool versions first.

Package freshness, security advisories and dependency resolution are different jobs. For an advisory that remains after a repair, use npm audit fix not working. For an install rejected by peers, use the ERESOLVE guide. Here the goal is to move a working app forward while keeping failures small enough to understand.

Record a working baseline

Save your current work on a branch before updating. Record the commit that currently builds, the Node version used by deployment, and the checks that pass. If the app already fails, capture that failure first. Otherwise a pre-existing broken test can send you looking for a regression in a package that did not cause it.

For an npm project with a synchronized manifest and lockfile, npm ci installs the locked tree and refuses disagreement between those files. It removes the existing installed tree. Run it in your development checkout, not in a running production directory.

npm ci
npm run

npm run without a script name lists the available scripts. Read them before running them. Use the app’s documented test, type-check and production-build commands; script names differ, and a script that calls a deployment is not a local validation step. Note explicitly if the project has no tests.

Separate wanted from latest

npm outdated

npm’s outdated reference defines Current as the installed version, Wanted as the highest version satisfying your declared range, and Latest as the registry’s latest tag. Latest can point somewhere other than the highest published version. A newer major deserves its own migration review, even when installation succeeds.

1. Choose an update that has a concrete reason: support, a needed fix, or a planned framework migration.
2. Read that package’s release notes and upgrade guide, including required Node versions and companion packages.
3. Keep unrelated framework, database-client and build-tool migrations in separate pull requests.
4. Record a deferred major with an owner and a reason instead of repeatedly hiding it from reports.

Patch and minor releases still need checks. A package can have a regression or change behavior your app depended on accidentally. Semantic versioning helps choose scope; your application tests provide the evidence for this particular update.

Update one package family

npm update respects declared version constraints. Without a package name it updates the whole applicable set; naming one keeps the review narrower. It normally leaves direct dependency ranges in package.json unchanged. Read the resulting lockfile instead of assuming no manifest edit means no change.

npm update some-package

For a deliberate move beyond the declared range, npm install accepts an explicit version or tag. These are alternatives, not commands to run consecutively:

npm install some-package@X.Y.Z
npm install some-package@latest

some-package and X.Y.Z are placeholders. Use the real package and the version you reviewed. Preserve its dependency category; use --save-dev when deliberately adding a development dependency. An explicit latest tag can cross a major or require a different runtime. Do not paste a bulk “everything to latest” command before reading the migration requirements.

Some packages must move together because their supported versions are coupled. Treat those as one family with a clear reason in the pull request. The React upgrade checklist and Next.js upgrade checklist cover those migrations separately.

Verify the changed application

Read the manifest and lockfile diff. Unexpected removed packages, a second lockfile, a runtime change or a large unrelated dependency churn deserves investigation. Keep both dependency files in the same review. Do not delete the lockfile just to make a conflict disappear; that replaces a focused update with a fresh resolution of the whole tree.

Repeat the clean install and baseline checks. Then test what the updated library actually touches: rendering for UI packages, sign-in for auth helpers, and reads and writes for a database client. A successful build proves compilation, not that a user can complete a task. Add a small browser smoke test for an important flow that currently has no coverage.

When a check fails, keep the failing output and narrow the change. Do not disable the check or force the installer merely to produce a green badge. If the old commit fails identically, record that evidence separately so the reviewer can tell a baseline problem from a new one.

Merge with a recovery path

Before merging, say what changed, which release notes you followed, which checks ran, and what remains manual. Keep the previous known-good deployment available. A dependency rollback does not reverse database writes or migrations; changes to stored data need their own backup and recovery plan.

For weekly upkeep, you can manually create a recurring dependency-review task with Denly’s task schedules after connecting a project and runner. Configure its instructions and review gates before enabling it. The public report form below creates a report; it does not create a schedule or a pull request.

Commands and product behavior on this page were checked against the vendor documentation linked here on 8 November 2026. Those products change their screens. If a label has moved, follow the linked page rather than a memory of this one.

Read next

npm audit fix is not working: why, and what to do instead · Fix npm ERESOLVE and peer dependency conflicts