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.

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:
Currentis the version in the installed dependency tree.Wantedis the highest version that satisfies the range inpackage.json.Latestis the version carrying the registry'slatestdist-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 outdatedto understand the installed project under its current ranges; - use
npm update <package>to install an allowed update; and - use
npm-check-updateswhen 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:
- Review the package release notes and lockfile diff.
- Create a fresh MailSlurp test inbox.
- Trigger the real application action that sends the message.
- Wait for receipt and assert the sender, subject, links, or one-time code.
- 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.