Install a specific npm package version

Install an exact package release, control the saved version range, and use the lockfile to keep a rollback reproducible.

Best practices
Illustration of files, modules, and their dependencies

Run npm install package@version to select a release. Add --save-exact when the dependency declaration should retain that exact version rather than a range.

npm install lodash@4.17.21 --save-exact
npm ls lodash

This version is an example of the syntax, not a recommendation to downgrade to it. Check the release's compatibility and security notices before choosing an older version.

Choose a version, range, or tag

npm view lodash versions --json
npm install lodash@4.17.21
npm install 'lodash@^4.17.0'
npm install 'lodash@~4.17.0'
npm install lodash@latest

An exact version selects that release for this installation. With npm's default save settings, the manifest may still record a caret range. --save-exact, or save-exact=true in the project's .npmrc, changes what is saved.

For these examples, ^4.17.0 admits compatible stable versions below 5.0.0, while ~4.17.0 stays below 4.18.0. Caret ranges behave more narrowly for 0.x packages, and prereleases have additional matching rules. Quote ranges to avoid shell interpretation. latest is a registry tag controlled by the publisher; it is not a guarantee of the greatest version or compatibility with your runtime.

Roll back a dependency

Identify the last working release from version control or your deployment record, install it explicitly, and review both package.json and package-lock.json. Run the affected tests and build before deploying the rollback.

A valid lockfile normally keeps an ordinary install on the locked version when it still satisfies the manifest. A caret declaration alone does not mean every npm install automatically upgrades it. Missing or incompatible lock entries, explicit update commands, or changed installation settings can produce a different resolution.

Commit the manifest and lockfile together. In CI, npm ci uses the lockfile and fails when it disagrees with the manifest instead of silently repairing it. Exact direct dependencies alone do not pin the entire transitive tree.

Git dependencies and verification

npm also accepts Git dependencies with a commit, tag, or branch fragment. A full commit identifier is more reproducible than a moving branch; review the repository and any installation scripts before using it.

Use npm ls package-name to inspect the installed version. Use npm view package-name version to inspect registry metadata. These answer different questions: the registry's current tag does not tell you what is installed locally.

References

Get a tailored plan

Contact us

Join the community

Scan with WeChat
to join the community

Try Guance

Start online and pay only for what you use.

Get started

Choose a Guance plan

Code hosting