.TH "NPM\-OUTDATED" "1" "November 2022" "9.1.1" .SH "NAME" \fBnpm-outdated\fR .SH Synopsis .SH Description .P This command will check the registry to see if any (or, specific) installed .br packages are currently outdated\. .P By default, only the direct dependencies of the root project and direct .br dependencies of your configured \fIworkspaces\fR are shown\. .br Use \fB\-\-all\fP to find all outdated meta\-dependencies as well\. .P In the output: .RS 1 .IP \(bu 2 \fBwanted\fP is the maximum version of the package that satisfies the semver .br range specified in \fBpackage\.json\fP\|\. If there's no available semver range .br (i\.e\. you're running \fBnpm outdated \-\-global\fP, or the package isn't .br included in \fBpackage\.json\fP), then \fBwanted\fP shows the currently\-installed .br version\. .IP \(bu 2 \fBlatest\fP is the version of the package tagged as latest in the registry\. .br Running \fBnpm publish\fP with no special configuration will publish the .br package with a dist\-tag of \fBlatest\fP\|\. This may or may not be the maximum .br version of the package, or the most\-recently published version of the .br package, depending on how the package's developer manages the latest .br dist\-tag\. .IP \(bu 2 \fBlocation\fP is where in the physical tree the package is located\. .IP \(bu 2 \fBdepended by\fP shows which package depends on the displayed dependency .IP \(bu 2 \fBpackage type\fP (when using \fB\-\-long\fP / \fB\-l\fP) tells you whether this .br package is a \fBdependency\fP or a dev/peer/optional dependency\. Packages not .br included in \fBpackage\.json\fP are always marked \fBdependencies\fP\|\. .IP \(bu 2 \fBhomepage\fP (when using \fB\-\-long\fP / \fB\-l\fP) is the \fBhomepage\fP value contained .br in the package's packument .IP \(bu 2 Red means there's a newer version matching your semver requirements, so .br you should update now\. .IP \(bu 2 Yellow indicates that there's a newer version \fIabove\fR your semver .br requirements (usually new major, or new 0\.x minor) so proceed with .br caution\. .RE .SH An example .RS 2 .nf $ npm outdated Package Current Wanted Latest Location Depended by glob 5\.0\.15 5\.0\.15 6\.0\.1 node_modules/glob dependent\-package\-name nothingness 0\.0\.3 git git node_modules/nothingness dependent\-package\-name npm 3\.5\.1 3\.5\.2 3\.5\.1 node_modules/npm dependent\-package\-name local\-dev 0\.0\.3 linked linked local\-dev dependent\-package\-name once 1\.3\.2 1\.3\.3 1\.3\.3 node_modules/once dependent\-package\-name .fi .RE .P With these \fBdependencies\fP: .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 1 .IP \(bu 2 \fBglob\fP requires \fB^5\fP, which prevents npm from installing \fBglob@6\fP, which .br is outside the semver range\. .IP \(bu 2 Git dependencies will always be reinstalled, because of how they're .br specified\. The installed committish might satisfy the dependency .br specifier (if it's something immutable, like a commit SHA), or it might .br not, so \fBnpm outdated\fP and \fBnpm update\fP have to fetch Git repos to check\. .br This is why currently doing a reinstall of a Git dependency always forces .br a new clone and install\. .IP \(bu 2 \fBnpm@3\.5\.2\fP is marked as "wanted", but "latest" is \fBnpm@3\.5\.1\fP because .br npm uses dist\-tags to manage its \fBlatest\fP and \fBnext\fP release channels\. .br \fBnpm update\fP will install the \fInewest\fR version, but \fBnpm install npm\fP .br (with no semver range) will install whatever's tagged as \fBlatest\fP\|\. .IP \(bu 2 \fBonce\fP is just plain out of date\. Reinstalling \fBnode_modules\fP from .br scratch or running \fBnpm update\fP will bring it up to spec\. .RE .SH Configuration .SH See Also .RS 1 .IP \(bu 2 package spec .IP \(bu 2 npm update .IP \(bu 2 npm dist\-tag .IP \(bu 2 npm registry .IP \(bu 2 npm folders .IP \(bu 2 npm workspaces .RE