1 .TH "NPM\-OUTDATED" "1" "October 2016" "" ""
3 \fBnpm-outdated\fR \- Check for outdated packages
8 npm outdated [<name> [<name> \.\.\.]]
13 This command will check the registry to see if any (or, specific) installed
14 packages are currently outdated\.
19 \fBwanted\fP is the maximum version of the package that satisfies the semver
20 range specified in \fBpackage\.json\fP\|\. If there's no available semver range (i\.e\.
21 you're running \fBnpm outdated \-\-global\fP, or the package isn't included in
22 \fBpackage\.json\fP), then \fBwanted\fP shows the currently\-installed version\.
24 \fBlatest\fP is the version of the package tagged as latest in the registry\.
25 Running \fBnpm publish\fP with no special configuration will publish the package
26 with a dist\-tag of \fBlatest\fP\|\. This may or may not be the maximum version of
27 the package, or the most\-recently published version of the package, depending
28 on how the package's developer manages the latest npm help dist\-tag\.
30 \fBlocation\fP is where in the dependency tree the package is located\. Note that
31 \fBnpm outdated\fP defaults to a depth of 0, so unless you override that, you'll
32 always be seeing only top\-level dependencies that are outdated\.
34 \fBpackage type\fP (when using \fB\-\-long\fP / \fB\-l\fP) tells you whether this package is
35 a \fBdependency\fP or a \fBdevDependency\fP\|\. Packages not included in \fBpackage\.json\fP
36 are always marked \fBdependencies\fP\|\.
44 Package Current Wanted Latest Location
45 glob 5\.0\.15 5\.0\.15 6\.0\.1 test\-outdated\-output
46 nothingness 0\.0\.3 git git test\-outdated\-output
47 npm 3\.5\.1 3\.5\.2 3\.5\.1 test\-outdated\-output
48 local\-dev 0\.0\.3 linked linked test\-outdated\-output
49 once 1\.3\.2 1\.3\.3 1\.3\.3 test\-outdated\-output
53 With these \fBdependencies\fP:
59 "nothingness": "github:othiym23/nothingness#master",
69 \fBglob\fP requires \fB^5\fP, which prevents npm from installing \fBglob@6\fP, which is
70 outside the semver range\.
72 Git dependencies will always be reinstalled, because of how they're specified\.
73 The installed committish might satisfy the dependency specifier (if it's
74 something immutable, like a commit SHA), or it might not, so \fBnpm outdated\fP and
75 \fBnpm update\fP have to fetch Git repos to check\. This is why currently doing a
76 reinstall of a Git dependency always forces a new clone and install\.
78 \fBnpm@3\.5\.2\fP is marked as "wanted", but "latest" is \fBnpm@3\.5\.1\fP because npm
79 uses dist\-tags to manage its \fBlatest\fP and \fBnext\fP release channels\. \fBnpm update\fP
80 will install the \fInewest\fR version, but \fBnpm install npm\fP (with no semver range)
81 will install whatever's tagged as \fBlatest\fP\|\.
83 \fBonce\fP is just plain out of date\. Reinstalling \fBnode_modules\fP from scratch or
84 running \fBnpm update\fP will bring it up to spec\.
97 Show information in JSON format\.
107 Show extended information\.
117 Show parseable output instead of tree view\.
127 Check packages in the global install prefix instead of in the current
138 Max depth for checking dependency tree\.