1--- 2title: npm-outdated 3section: 1 4description: Check for outdated packages 5--- 6 7### Synopsis 8 9```bash 10npm outdated [<package-spec> ...] 11``` 12 13### Description 14 15This command will check the registry to see if any (or, specific) installed 16packages are currently outdated. 17 18By default, only the direct dependencies of the root project and direct 19dependencies of your configured *workspaces* are shown. 20Use `--all` to find all outdated meta-dependencies as well. 21 22In the output: 23 24* `wanted` is the maximum version of the package that satisfies the semver 25 range specified in `package.json`. If there's no available semver range 26 (i.e. you're running `npm outdated --global`, or the package isn't 27 included in `package.json`), then `wanted` shows the currently-installed 28 version. 29* `latest` is the version of the package tagged as latest in the registry. 30 Running `npm publish` with no special configuration will publish the 31 package with a dist-tag of `latest`. This may or may not be the maximum 32 version of the package, or the most-recently published version of the 33 package, depending on how the package's developer manages the latest 34 [dist-tag](/commands/npm-dist-tag). 35* `location` is where in the physical tree the package is located. 36* `depended by` shows which package depends on the displayed dependency 37* `package type` (when using `--long` / `-l`) tells you whether this 38 package is a `dependency` or a dev/peer/optional dependency. Packages not 39 included in `package.json` are always marked `dependencies`. 40* `homepage` (when using `--long` / `-l`) is the `homepage` value contained 41 in the package's packument 42* Red means there's a newer version matching your semver requirements, so 43 you should update now. 44* Yellow indicates that there's a newer version _above_ your semver 45 requirements (usually new major, or new 0.x minor) so proceed with 46 caution. 47 48### An example 49 50```bash 51$ npm outdated 52Package Current Wanted Latest Location Depended by 53glob 5.0.15 5.0.15 6.0.1 node_modules/glob dependent-package-name 54nothingness 0.0.3 git git node_modules/nothingness dependent-package-name 55npm 3.5.1 3.5.2 3.5.1 node_modules/npm dependent-package-name 56local-dev 0.0.3 linked linked local-dev dependent-package-name 57once 1.3.2 1.3.3 1.3.3 node_modules/once dependent-package-name 58``` 59 60With these `dependencies`: 61```json 62{ 63 "glob": "^5.0.15", 64 "nothingness": "github:othiym23/nothingness#master", 65 "npm": "^3.5.1", 66 "once": "^1.3.1" 67} 68``` 69 70A few things to note: 71 72* `glob` requires `^5`, which prevents npm from installing `glob@6`, which 73 is outside the semver range. 74* Git dependencies will always be reinstalled, because of how they're 75 specified. The installed committish might satisfy the dependency 76 specifier (if it's something immutable, like a commit SHA), or it might 77 not, so `npm outdated` and `npm update` have to fetch Git repos to check. 78 This is why currently doing a reinstall of a Git dependency always forces 79 a new clone and install. 80* `npm@3.5.2` is marked as "wanted", but "latest" is `npm@3.5.1` because 81 npm uses dist-tags to manage its `latest` and `next` release channels. 82 `npm update` will install the _newest_ version, but `npm install npm` 83 (with no semver range) will install whatever's tagged as `latest`. 84* `once` is just plain out of date. Reinstalling `node_modules` from 85 scratch or running `npm update` will bring it up to spec. 86 87### Configuration 88 89#### `all` 90 91* Default: false 92* Type: Boolean 93 94When running `npm outdated` and `npm ls`, setting `--all` will show all 95outdated or installed packages, rather than only those directly depended 96upon by the current project. 97 98 99 100#### `json` 101 102* Default: false 103* Type: Boolean 104 105Whether or not to output JSON data, rather than the normal output. 106 107* In `npm pkg set` it enables parsing set values with JSON.parse() before 108 saving them to your `package.json`. 109 110Not supported by all npm commands. 111 112 113 114#### `long` 115 116* Default: false 117* Type: Boolean 118 119Show extended information in `ls`, `search`, and `help-search`. 120 121 122 123#### `parseable` 124 125* Default: false 126* Type: Boolean 127 128Output parseable results from commands that write to standard output. For 129`npm search`, this will be tab-separated table format. 130 131 132 133#### `global` 134 135* Default: false 136* Type: Boolean 137 138Operates in "global" mode, so that packages are installed into the `prefix` 139folder instead of the current working directory. See 140[folders](/configuring-npm/folders) for more on the differences in behavior. 141 142* packages are installed into the `{prefix}/lib/node_modules` folder, instead 143 of the current working directory. 144* bin files are linked to `{prefix}/bin` 145* man pages are linked to `{prefix}/share/man` 146 147 148 149#### `workspace` 150 151* Default: 152* Type: String (can be set multiple times) 153 154Enable running a command in the context of the configured workspaces of the 155current project while filtering by running only the workspaces defined by 156this configuration option. 157 158Valid values for the `workspace` config are either: 159 160* Workspace names 161* Path to a workspace directory 162* Path to a parent workspace directory (will result in selecting all 163 workspaces within that folder) 164 165When set for the `npm init` command, this may be set to the folder of a 166workspace which does not yet exist, to create the folder and set it up as a 167brand new workspace within the project. 168 169This value is not exported to the environment for child processes. 170 171### See Also 172 173* [package spec](/using-npm/package-spec) 174* [npm update](/commands/npm-update) 175* [npm dist-tag](/commands/npm-dist-tag) 176* [npm registry](/using-npm/registry) 177* [npm folders](/configuring-npm/folders) 178* [npm workspaces](/using-npm/workspaces) 179