36bcfa7913PR-URL: https://github.com/nodejs/node/pull/63857 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Jordan Harband <ljharb@gmail.com>
237 lines
8.5 KiB
Markdown
237 lines
8.5 KiB
Markdown
---
|
|
title: npm-outdated
|
|
section: 1
|
|
description: Check for outdated packages
|
|
---
|
|
|
|
### Synopsis
|
|
|
|
```bash
|
|
npm outdated [<package-spec> ...]
|
|
```
|
|
|
|
### 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 and direct dependencies of your configured *workspaces* are shown.
|
|
Use `--all` to find all outdated meta-dependencies as well.
|
|
|
|
In the output:
|
|
|
|
* `wanted` is the maximum version of the package that satisfies the semver range specified in `package.json`.
|
|
If there's no available semver range (i.e. you're running `npm outdated --global`, or the package isn't included in `package.json`), then `wanted` shows the latest version.
|
|
* `latest` is the version of the package tagged as latest in the registry.
|
|
Running `npm publish` with no special configuration will publish the package with a dist-tag of `latest`.
|
|
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](/commands/npm-dist-tag).
|
|
* `location` is where in the physical tree the package is located.
|
|
* `depended by` shows which package depends on the displayed dependency
|
|
* `package type` (when using `--long` / `-l`) tells you whether this package is a `dependency` or a dev/peer/optional dependency.
|
|
Packages not included in `package.json` are always marked `dependencies`.
|
|
* `homepage` (when using `--long` / `-l`) is the `homepage` value contained in the package's packument
|
|
* `depended by location` (when using `--long` / `-l`) shows location of the package that depends on the displayed dependency
|
|
* 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
|
|
|
|
```bash
|
|
$ 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`:
|
|
```json
|
|
{
|
|
"glob": "^5.0.15",
|
|
"nothingness": "github:othiym23/nothingness#master",
|
|
"npm": "^3.5.1",
|
|
"once": "^1.3.1"
|
|
}
|
|
```
|
|
|
|
A few things to note:
|
|
|
|
* `glob` requires `^5`, which prevents npm from installing `glob@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 outdated` and `npm update` 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.
|
|
* `npm@3.5.2` is marked as "wanted", but "latest" is `npm@3.5.1` because npm uses dist-tags to manage its `latest` and `next` release channels.
|
|
`npm update` will install the _newest_ version, but `npm install npm` (with no semver range) will install whatever's tagged as `latest`.
|
|
* `once` is just plain out of date.
|
|
Reinstalling `node_modules` from scratch or running `npm update` will bring it up to spec.
|
|
|
|
### Configuration
|
|
|
|
#### `all`
|
|
|
|
* Default: false
|
|
* Type: Boolean
|
|
|
|
Show or act on all packages, not just the ones your project directly depends
|
|
on. For `npm outdated` and `npm ls` this lists every outdated or installed
|
|
package. For `npm approve-scripts` and `npm deny-scripts` it selects every
|
|
package with pending install scripts.
|
|
|
|
|
|
|
|
#### `json`
|
|
|
|
* Default: false
|
|
* Type: Boolean
|
|
|
|
Whether or not to output JSON data, rather than the normal output.
|
|
|
|
* In `npm pkg set` it enables parsing set values with JSON.parse() before
|
|
saving them to your `package.json`.
|
|
|
|
Not supported by all npm commands.
|
|
|
|
|
|
|
|
#### `long`
|
|
|
|
* Default: false
|
|
* Type: Boolean
|
|
|
|
Show extended information in `ls`, `search`, and `help-search`.
|
|
|
|
|
|
|
|
#### `parseable`
|
|
|
|
* Default: false
|
|
* Type: Boolean
|
|
|
|
Output parseable results from commands that write to standard output. For
|
|
`npm search`, this will be tab-separated table format.
|
|
|
|
|
|
|
|
#### `global`
|
|
|
|
* Default: false
|
|
* Type: Boolean
|
|
|
|
Operates in "global" mode, so that packages are installed into the `prefix`
|
|
folder instead of the current working directory. See
|
|
[folders](/configuring-npm/folders) for more on the differences in behavior.
|
|
|
|
* packages are installed into the `{prefix}/lib/node_modules` folder, instead
|
|
of the current working directory.
|
|
* bin files are linked to `{prefix}/bin`
|
|
* man pages are linked to `{prefix}/share/man`
|
|
|
|
|
|
|
|
#### `workspace`
|
|
|
|
* Default:
|
|
* Type: String (can be set multiple times)
|
|
|
|
Enable running a command in the context of the configured workspaces of the
|
|
current project while filtering by running only the workspaces defined by
|
|
this configuration option.
|
|
|
|
Valid values for the `workspace` config are either:
|
|
|
|
* Workspace names
|
|
* Path to a workspace directory
|
|
* Path to a parent workspace directory (will result in selecting all
|
|
workspaces within that folder)
|
|
|
|
When set for the `npm init` command, this may be set to the folder of a
|
|
workspace which does not yet exist, to create the folder and set it up as a
|
|
brand new workspace within the project.
|
|
|
|
This value is not exported to the environment for child processes.
|
|
|
|
#### `before`
|
|
|
|
* Default: null
|
|
* Type: null or Date
|
|
|
|
If passed to `npm install`, will rebuild the npm tree such that only
|
|
versions that were available **on or before** the given date are installed.
|
|
If there are no versions available for the current set of dependencies, the
|
|
command will error.
|
|
|
|
If the requested version is a `dist-tag` and the given tag does not pass the
|
|
`--before` filter, the most recent version less than or equal to that tag
|
|
will be used. For example, `foo@latest` might install `foo@1.2` even though
|
|
`latest` is `2.0`.
|
|
|
|
If `before` and `min-release-age` are both set in the same source, `before`
|
|
wins (an explicit absolute date overrides a relative window). Across
|
|
sources, the standard precedence applies (cli > env > project > user >
|
|
global), so a higher-priority source can always relax or override a
|
|
lower-priority one.
|
|
|
|
Packages whose names match `min-release-age-exclude` are exempt from this
|
|
filter.
|
|
|
|
|
|
|
|
#### `min-release-age`
|
|
|
|
* Default: null
|
|
* Type: null or Number
|
|
|
|
If set, npm will build the npm tree such that only versions that were
|
|
available more than the given number of days ago will be installed. If there
|
|
are no versions available for the current set of dependencies, the command
|
|
will error.
|
|
|
|
This flag is a complement to `before`, which accepts an exact date instead
|
|
of a relative number of days. The two may coexist (e.g. `min-release-age` in
|
|
your `.npmrc` is preserved when npm internally spawns a sub-process with
|
|
`--before` while preparing a `git:` or `github:` dependency); when both
|
|
apply, `before` wins within a single source and across sources the standard
|
|
precedence rules apply.
|
|
|
|
Packages whose names match `min-release-age-exclude` are exempt from this
|
|
filter.
|
|
|
|
This value is not exported to the environment for child processes.
|
|
|
|
#### `min-release-age-exclude`
|
|
|
|
* Default:
|
|
* Type: String (can be set multiple times)
|
|
|
|
A list of package names or `minimatch` glob patterns that are exempt from
|
|
the `min-release-age` (and `before`) filter. A matching package can always
|
|
resolve to its newest version, even when a release-age window is set.
|
|
|
|
For example, to apply a release-age window to third-party dependencies while
|
|
letting internally maintained packages update immediately:
|
|
|
|
```
|
|
min-release-age=7
|
|
min-release-age-exclude[]=@myorg/*
|
|
min-release-age-exclude[]=my-internal-pkg
|
|
```
|
|
|
|
Only the named package is exempt; its own dependencies still follow the
|
|
release-age policy unless they also match a pattern. Patterns match against
|
|
the package name, so `@myorg/*` matches `@myorg/shared-utils`.
|
|
|
|
Excluding a package does not change which registry it is fetched from. You
|
|
should own your private scope on the public registry so that nobody else can
|
|
publish a package with the same name.
|
|
|
|
This value is not exported to the environment for child processes.
|
|
|
|
### See Also
|
|
|
|
* [package spec](/using-npm/package-spec)
|
|
* [npm update](/commands/npm-update)
|
|
* [npm dist-tag](/commands/npm-dist-tag)
|
|
* [npm registry](/using-npm/registry)
|
|
* [npm folders](/configuring-npm/folders)
|
|
* [npm workspaces](/using-npm/workspaces)
|