Efficient Package Management with npm-outdated and npm-owner Commands

In the last tutorial we looked at npm-ls and npm cli commands, in this tutorial we will examine two very important cli commands, the npm-outdated and npm-owner commands. While the npm-outdated checks for outdated packages, npm-owner helps you to manage package owners.

Npm-outdated

The npm-outdated command is used to check for outdated packages.

Synopsis

npm outdated [[<@scope>/]<pkg> ...]

Description

The npm-outdated command checks the registry to see if there is any (or, specific) installed packages are currently outdated.

In the output:

• Wanted this is the maximum version of the package that will satisfy the semver range that is specified in your package.json. In the case where there is no available semver range(that is when you are running npm outdated ?global, or the package is not included in the package.json), then wanted will show the currently-installed version.
• Latest this is the version of the package that is tagged as latest in the registry. When you run npm publish without a special configuration, it will publish the package with a dist-tag of latest. This could either be the maximum version of the package or not, or it could be the most recently published version of the package, depending on how the latest dist-tag is managed by the developer of the package.
• Location this command specifies the location of a package in the dependency tree. It should be noted that npm outdated will default to a depth of 0, hence, unless you override that, you will always be seeing only the top-level dependencies that are outdated.
• Package type (when you are using ?log/ -l) this command check to determine whether a package is a dependency or a devdependency. The packages that are not included in the package.json will always be marked as dependencies.
• Red this means that there is a newer version that matches your semver requirements, hence, you need to update now.
• Yellow this indicates that a newer version above your semver requirements exist (usually new major, or new 0.x minor) so you need to proceed with caution.

An example

$ npm outdated
Package      Current   Wanted   Latest  Location
glob          5.0.15   5.0.15    6.0.1  test-outdated-output
nothingness    0.0.3      git      git  test-outdated-output
npm            3.5.1    3.5.2    3.5.1  test-outdated-output
local-dev      0.0.3   linked   linked  test-outdated-output
once           1.3.2    1.3.3    1.3.3  test-outdated-output

with these dependencies:

{
  "glob": "^5.0.15",
  "nothingness": "github:othiym23/nothingness#master",
  "npm": "^3.5.1",
  "once": "^1.3.1"
}

Here are a few things that you should note:

• glob requires ^5, which will prevent npm from installing glob@6, that is outside the semver range.
• Git dependencies are always reinstalled, because of how they are specified. The installed committish may satisfy the dependency specifier (if it is something that is immutable, such as a commit SHA), or it might not, hence npm outdated and npm update will have to fetch Git repos to check. This is reason why currently doing a reinstall of a Git dependency will always force a new clone and install.
• [email protected] will be marked as "wanted", but "latest" will be [email protected] because npm will use dist-tags to manage its latest and next release channels. npm update installs the newest version, but npm install npm (with no semver range) installs whatever is tagged as latest.
• once this is plainly out of date. To bring it up to spec you need to reinstall node_modules from scratch or run npm update.

Configuration

json

This config option will display information in JSON format.

• Default: false
• Type: Boolean

Long

This option shows extended information

• Default: false
• Type: Boolean

parseable

• Default: false
• Type: Boolean

This will show parseable output instead of tree view.

global

• Default: false
• Type: Boolean

This will check packages in the global install prefix instead of in the current project.

depth

• Default: 0
• Type: Int

This defines the max depth for checking dependency tree.

npm-owner

The npm-owner cli option helps you to manage package owners.

Synopsis

npm owner add <user> [<@scope>/]<pkg>
npm owner rm <user> [<@scope>/]<pkg>
npm owner ls [<@scope>/]<pkg>

aliases: author

Description

This command manages the ownership of published packages.

• ls: Lists all the users who have access to modify a package and push new versions. It is very handy when you need to know who to bug for help.
• add: Adds a new user as a maintainer of a package. This user will be enabled to modify metadata, publish new versions, as well as adding other owners.
• rm: Removes a user from the package owner list. This will immediately revoke their privileges.

It should be noted that there is only one level of access. It is either you can modify a package or you can?t. future versions could contain more fine-grained access levels, However, that will not be implemented at this time.

If two-factor authentication is enabled with auth-and-writes then you will need to include an otp on the command line when changing ownership with ?otp.

Previous: Mastering npm-ls and npm CLI Commands for Effective Package Management.
Next: Mastering npm-pack, npm-ping, and npm-prefix Commands for Efficient Package Management.