NPM-OUTDATED(1)

NAME
npm-outdated - Check for outdated packages

  Synopsis

    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 npm help 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

    $ 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:

    •   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 npm help 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

    •   npm help "package spec"

    •   npm help update

    •   npm help dist-tag

    •   npm help registry

    •   npm help folders

    •   npm help workspaces