.TH "NPM\-OUTDATED" "1" "August 2018" "" "" .SH "NAME" \fBnpm-outdated\fR \- Check for outdated packages .SH SYNOPSIS .P .RS 2 .nf npm outdated [[<@scope>/] \.\.\.] .fi .RE .SH DESCRIPTION .P This command will check the registry to see if any (or, specific) installed packages are currently outdated\. .P In the output: .RS 0 .IP \(bu 2 \fBwanted\fP is the maximum version of the package that satisfies the semver range specified in \fBpackage\.json\fP\|\. If there's no available semver range (i\.e\. you're running \fBnpm outdated \-\-global\fP, or the package isn't included in \fBpackage\.json\fP), then \fBwanted\fP shows the currently\-installed version\. .IP \(bu 2 \fBlatest\fP is the version of the package tagged as latest in the registry\. Running \fBnpm publish\fP with no special configuration will publish the package with a dist\-tag of \fBlatest\fP\|\. This may or may not be the maximum version of the package, or the most\-recently published version of the package, depending on how the package's developer manages the latest npm help dist\-tag\. .IP \(bu 2 \fBlocation\fP is where in the dependency tree the package is located\. Note that \fBnpm outdated\fP defaults to a depth of 0, so unless you override that, you'll always be seeing only top\-level dependencies that are outdated\. .IP \(bu 2 \fBpackage type\fP (when using \fB\-\-long\fP / \fB\-l\fP) tells you whether this package is a \fBdependency\fP or a \fBdevDependency\fP\|\. Packages not included in \fBpackage\.json\fP are always marked \fBdependencies\fP\|\. .IP \(bu 2 Red means there's a newer version matching your semver requirements, so you should update now\. .IP \(bu 2 Yellow indicates that there's a newer version above your semver requirements (usually new major, or new 0\.x minor) so proceed with caution\. .RE .SS An example .P .RS 2 .nf $ npm outdated Package Current Wanted Latest Location glob 5\.0\.15 5\.0\.15 6\.0\.1 test\-outdated\-output nothingness 0\.0\.3 git git test\-outdated\-output npm 3\.5\.1 3\.5\.2 3\.5\.1 test\-outdated\-output local\-dev 0\.0\.3 linked linked test\-outdated\-output once 1\.3\.2 1\.3\.3 1\.3\.3 test\-outdated\-output .fi .RE .P With these \fBdependencies\fP: .P .RS 2 .nf { "glob": "^5\.0\.15", "nothingness": "github:othiym23/nothingness#master", "npm": "^3\.5\.1", "once": "^1\.3\.1" } .fi .RE .P A few things to note: .RS 0 .IP \(bu 2 \fBglob\fP requires \fB^5\fP, which prevents npm from installing \fBglob@6\fP, which is outside the semver range\. .IP \(bu 2 Git dependencies will always be reinstalled, because of how they're specified\. The installed committish might satisfy the dependency specifier (if it's something immutable, like a commit SHA), or it might not, so \fBnpm outdated\fP and \fBnpm update\fP have to fetch Git repos to check\. This is why currently doing a reinstall of a Git dependency always forces a new clone and install\. .IP \(bu 2 \fBis marked as "wanted", but "latest" is\fP\fBbecause npm uses dist\-tags to manage its\fPlatest\fBand\fPnext\fBrelease channels\.\fPnpm update\fBwill install the _newest_ version, but\fPnpm install npm\fB(with no semver range) will install whatever's tagged as\fPlatest`\. .IP \(bu 2 \fBonce\fP is just plain out of date\. Reinstalling \fBnode_modules\fP from scratch or running \fBnpm update\fP will bring it up to spec\. .RE .SH CONFIGURATION .SS json .RS 0 .IP \(bu 2 Default: false .IP \(bu 2 Type: Boolean .RE .P Show information in JSON format\. .SS long .RS 0 .IP \(bu 2 Default: false .IP \(bu 2 Type: Boolean .RE .P Show extended information\. .SS parseable .RS 0 .IP \(bu 2 Default: false .IP \(bu 2 Type: Boolean .RE .P Show parseable output instead of tree view\. .SS global .RS 0 .IP \(bu 2 Default: false .IP \(bu 2 Type: Boolean .RE .P Check packages in the global install prefix instead of in the current project\. .SS depth .RS 0 .IP \(bu 2 Default: 0 .IP \(bu 2 Type: Int .RE .P Max depth for checking dependency tree\. .SH SEE ALSO .RS 0 .IP \(bu 2 npm help update .IP \(bu 2 npm help dist\-tag .IP \(bu 2 npm help 7 registry .IP \(bu 2 npm help 5 folders .RE