Compares two package versions using their registry specifiers, e.g: \fBnpm diff --diff=pkg@1.0.0 --diff=pkg@^2.0.0\fR. It's also possible to compare across forks of any package, e.g: \fBnpm diff --diff=pkg@1.0.0 --diff=pkg-fork@1.0.0\fR.
.P
Any valid spec can be used, so that it's also possible to compare directories or git repositories, e.g: \fBnpm diff --diff=pkg@latest --diff=./packages/pkg\fR
.P
Here's an example comparing two different versions of a package named \fBabbrev\fR from the registry:
In the example above we can compare the contents from the package installed from the git repo at \fBgithub.com/npm/libnpmdiff\fR with the contents of the \fB./local-path\fR that contains a valid package, such as a modified copy of the original.
.IP\(bu4
\fBnpm diff\fR (in a package directory, no arguments):
.P
If the package is published to the registry, \fBnpm diff\fR will fetch the tarball version tagged as \fBlatest\fR (this value can be configured using the \fBtag\fR option) and proceed to compare the contents of files present in that tarball, with the current files in your local file system.
.P
This workflow provides a handy way for package authors to see what package-tracked files have been changed in comparison with the latest published version of that package.
.IP\(bu4
\fBnpm diff --diff=<pkg-name>\fR (in a package directory):
.P
When using a single package name (with no version or tag specifier) as an argument, \fBnpm diff\fR will work in a similar way to \fB\fBnpm-outdated\fR\fR\fI\(lanpm-outdated\(ra\fR and reach for the registry to figure out what current published version of the package named \fB<pkg-name>\fR will satisfy its dependent declared semver-range. Once that specific version is known \fBnpm diff\fR will print diff patches comparing the current version of \fB<pkg-name>\fR found in the local file system with that specific version returned by the registry.
.P
Given a package named \fBabbrev\fR that is currently installed:
That will request from the registry its most up to date version and will print a diff output comparing the currently installed version to this newer one if the version numbers are not the same.
.IP\(bu4
\fBnpm diff --diff=<spec-a>\fR (in a package directory):
.P
Similar to using only a single package name, it's also possible to declare a full registry specifier version if you wish to compare the local version of an installed package with the specific version/tag/semver-range provided in \fB<spec-a>\fR.
.P
An example: assuming \fBpkg@1.0.0\fR is installed in the current \fBnode_modules\fR folder, running:
It will effectively be an alias to \fBnpm diff --diff=pkg@1.0.0 --diff=pkg@2.0.0\fR.
.IP\(bu4
\fBnpm diff --diff=<semver-a> \[lB]--diff=<semver-b>\[rB]\fR (in a package directory):
.P
Using \fBnpm diff\fR along with semver-valid version numbers is a shorthand to compare different versions of the current package.
.P
It needs to be run from a package directory, such that for a package named \fBpkg\fR running \fBnpm diff --diff=1.0.0 --diff=1.0.1\fR is the same as running \fBnpm diff --diff=pkg@1.0.0 --diff=pkg@1.0.1\fR.
.P
If only a single argument \fB<version-a>\fR is provided, then the current local file system is going to be compared against that version.
.P
Here's an example comparing two specific versions (published to the configured registry) of the current project directory:
It's possible to also specify positional arguments using file names or globs pattern matching in order to limit the result of diff patches to only a subset of files for a given package, e.g:
In the example above the diff output is only going to print contents of files located within the folder \fB./lib/\fR and changed lines of code within the \fBCHANGELOG.md\fR file.
Operates in "global" mode, so that packages are installed into the \fBprefix\fR folder instead of the current working directory. See npm help folders for more on the differences in behavior.
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.
When set for the \fBnpm init\fR 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.
Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
