MailSlurp logo

blog

How to show the latest package version in npm

Find the npm version behind latest, compare installed and allowed updates, check dist-tags, and upgrade packages without surprising your test suite.

How to show the latest package version in npm article preview

Need the version npm installs by default? Run:

npm view <package-name> version

npm show <package-name> version gives the same answer because show is an alias for view. There is one small trap worth knowing: the command returns the version behind the registry's latest dist-tag. That tag is usually the stable release, but it is a label maintained by the package publisher, not a promise that npm sorted every published version and picked the largest number.

The useful npm version commands

What you want to know Command
Version behind the default latest tag npm view <package> version
Same lookup using the alias npm show <package> version
Version behind a named channel such as next npm view <package>@next version
Every dist-tag and its version npm view <package> dist-tags --json
Every published version npm view <package> versions --json
Installed, allowed, and tagged versions for this project npm outdated
Machine-readable outdated results npm outdated --json

The official npm view reference documents the show, info, and v aliases and confirms that an unspecified version defaults to latest.

Check one package without installing it

Registry lookups do not require the package to be installed. For the MailSlurp JavaScript client, these commands answer three slightly different questions:

# Which version is tagged latest?
npm view mailslurp-client version

# Prove that npm show is the same lookup
npm show mailslurp-client version

# See stable and prerelease channels separately
npm view mailslurp-client dist-tags --json

The first two values should agree because neither command names another tag or version. The third command explains why. A package publisher can point latest, next, beta, or another dist-tag at different releases.

Use an explicit tag when that is what you mean:

npm view react@next version

Use a version range when you want the registry metadata for releases inside that range:

npm view 'typescript@^5' version

Quote ranges so the shell does not try to interpret their punctuation. If you need publish dates or repository details before an upgrade, ask for those fields rather than scraping the normal display:

npm view mailslurp-client time --json
npm view mailslurp-client repository.url

latest is a dist-tag, not a chronology check

Publishers use dist-tags to offer stable and prerelease channels. latest is the default tag for an ordinary publish, but it can be moved. It may therefore differ from the numerically greatest version or the most recently published version.

That distinction matters when a package has a beta, a maintenance line, or a release that was tagged incorrectly and later corrected. If a result surprises you, inspect both the tags and the version history:

npm view <package-name> dist-tags --json
npm view <package-name> versions --json

Do not automatically install the largest number in the second list. The project's supported Node version, peer dependencies, release notes, and migration guide still get a vote.

Read Current, Wanted, and Latest correctly

Run npm outdated inside an installed project:

npm outdated

The columns describe different layers:

  • Current is the version in the installed dependency tree.
  • Wanted is the highest version that satisfies the range in package.json.
  • Latest is the version carrying the registry's latest dist-tag.

For example, an exact dependency on 17.3.0 can show 17.3.0 for both Current and Wanted while the package's Latest column shows 17.4.0. Nothing is inconsistent: the exact range refuses the newer release.

The npm outdated documentation also notes that latest may not be the maximum or most recently published version. By default, the command reports direct dependencies from the root project and configured workspaces. Add --all when you genuinely need outdated transitive dependencies too; the result can be much noisier.

If Current is missing or unexpected, install from the committed lockfile first. npm outdated describes the physical dependency tree, not a hypothetical install represented only by package-lock.json.

Use JSON carefully in CI

For scripts, prefer structured output:

npm outdated --json

Do not assume that a non-zero exit means npm failed to contact the registry. With npm 11.17, a fixture containing one intentionally outdated MailSlurp client returned useful JSON and exit code 1, just like the table form. Pin the npm version used by CI, capture the output, and decide whether "an update exists" should warn or fail for your project. A security patch, a routine minor release, and a breaking major do not deserve the same alarm bell.

For a workspace, scope the question instead of dumping the whole monorepo:

npm outdated --workspace packages/api
npm outdated --workspaces

The first command helps one team investigate its package. The second is useful for a scheduled repository-wide report.

What npm update changes

npm update is an install operation, not another read-only version check:

npm update

It updates installed packages to versions allowed by the existing semver ranges and refreshes the dependency tree. By default it does not rewrite the ranges for direct dependencies in package.json. The official npm update reference documents --save when changing those declared values is intentional.

Use a package name for a smaller change:

npm update mailslurp-client

Then review both package.json and package-lock.json. A small command can still move transitive packages while npm resolves peers and shared dependencies.

When npm-check-updates helps

npm-check-updates is a separate tool, not an npm CLI alias. Its default command shows newer versions that sit outside your current ranges:

npx npm-check-updates

That is a planning view. Adding -u rewrites dependency ranges in package.json; you still need to run npm install to update the installed tree and lockfile. Check the tool's current Node and npm requirements before adopting it in an older repository.

This is the practical split:

  • use npm outdated to understand the installed project under its current ranges;
  • use npm update <package> to install an allowed update; and
  • use npm-check-updates when you deliberately want to consider new ranges, including majors.

Give an email SDK upgrade a real smoke test

Version output tells you what changed on disk. It cannot tell you whether a customer can still finish a signup, password reset, invite, or OTP flow.

After upgrading mailslurp-client, or any package in the same email path:

  1. Review the package release notes and lockfile diff.
  2. Create a fresh MailSlurp test inbox.
  3. Trigger the real application action that sends the message.
  4. Wait for receipt and assert the sender, subject, links, or one-time code.
  5. Remove the temporary inbox when the test finishes.

The MailSlurp JavaScript SDK provides the inbox and wait methods. The Nodemailer npm guide includes a complete send-and-receive example, while Email Sandbox keeps upgrade checks away from customer inboxes.

A version check is a tidy beginning. The inbox result is the bit your users notice.

Quick answers

What command shows the latest npm package version?

Use npm view <package-name> version. It returns the version behind the latest dist-tag.

Are npm show and npm view the same command?

For this lookup, yes. show is an official alias for view.

Why are Wanted and Latest different?

Wanted must satisfy your package.json range. Latest follows the registry's latest tag. An exact version or a range that excludes a new major can keep Wanted behind Latest.

Does npm update install the newest published version?

It installs the highest allowed version selected under your current constraints and npm settings. It does not automatically move every direct dependency range to a new major.