npm-outdated
Check for outdated packagesTable of contents
Synopsis
npm outdated [[<@scope>/]<pkg> ...]
Description
This command will check the registry to see if any (or, specific) installed packages are currently outdated.
By default, only the direct dependencies of the root project are shown.
Use --all to find all outdated meta-dependencies as well.
In the output:
wantedis the maximum version of the package that satisfies the semver range specified inpackage.json. If there’s no available semver range (i.e. you’re runningnpm outdated --global, or the package isn’t included inpackage.json), thenwantedshows the currently-installed version.latestis the version of the package tagged as latest in the registry. Runningnpm publishwith no special configuration will publish the package with a dist-tag oflatest. 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 dist-tag.locationis where in the physical tree the package is located.depended byshows which package depends on the displayed dependencypackage type(when using--long/-l) tells you whether this package is adependencyor a dev/peer/optional dependency. Packages not included inpackage.jsonare always markeddependencies.homepage(when using--long/-l) is thehomepagevalue contained in the package’s packument- Red means there’s a newer version matching your semver requirements, so you should update now.
- Yellow indicates that there’s a newer version above your semver requirements (usually new major, or new 0.x minor) so proceed with caution.
An example
$ 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
With these dependencies:
{
"glob": "^5.0.15",
"nothingness": "github:othiym23/nothingness#master",
"npm": "^3.5.1",
"once": "^1.3.1"
}
A few things to note:
globrequires^5, which prevents npm from installingglob@6, which is outside the semver range.- 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
npm outdatedandnpm updatehave to fetch Git repos to check. This is why currently doing a reinstall of a Git dependency always forces a new clone and install. npm@3.5.2is marked as “wanted”, but “latest” isnpm@3.5.1because npm uses dist-tags to manage itslatestandnextrelease channels.npm updatewill install the newest version, butnpm install npm(with no semver range) will install whatever’s tagged aslatest.onceis just plain out of date. Reinstallingnode_modulesfrom scratch or runningnpm updatewill bring it up to spec.
Configuration
json
- Default: false
- Type: Boolean
Show information in JSON format.
long
- Default: false
- Type: Boolean
Show extended information.
parseable
- Default: false
- Type: Boolean
Show parseable output instead of tree view.
global
- Default: false
- Type: Boolean
Check packages in the global install prefix instead of in the current project.
all
- Default: false
- Type: Boolean
Display all outdated dependencies on the tree.