First, `npm link` in a package folder will create a symlink in the global folder

`{prefix}/lib/node_modules/<package>` that links to the package where the `npm

link` command was executed. It will also link any bins in the package to `{prefix}/bin/{name}`.

Note that `npm link` uses the global prefix (see `npm prefix -g` for its value).

symbolic link from globally-installed `package-name` to `node_modules/`

of the current folder.

Note that `package-name` is taken from `package.json`,

not from directory name.

The package name can be optionally prefixed with a scope. See [`scope`](/using-npm/scope).

The scope must be preceded by an @-symbol and followed by a slash.

"snapshotted" to their current state by resolving the symbolic links.

This is handy for installing your own stuff, so that you can work on it and

test it iteratively without having to continually rebuild.

cd ~/projects/node-redis # go into the package directory

npm link # creates global link

cd ~/projects/node-bloggy # go into some other package directory.

npm link redis # link-install the package

Now, any changes to ~/projects/node-redis will be reflected in

~/projects/node-bloggy/node_modules/node-redis/. Note that the link should

be to the package name, not the directory name for that package.

Note that in this case, you are referring to the directory name, `node-redis`,

rather than the package name `redis`.

If your linked package is scoped (see [`scope`](/using-npm/scope)) your link command must include that scope, e.g.

When logged into a registry that supports token-based authentication, tell the

server to end this token's session. This will invalidate the token everywhere

you're using it, not just for the current environment.

When logged into a legacy registry that uses username and password authentication, this will

clear the credentials in your user configuration. In this case, it will _only_ affect

the current environment.

installed, as well as their dependencies, in a tree-structure.

Positional arguments are `name@version-range` identifiers, which will

limit the results to only the paths to the packages named. Note that

nested packages will *also* show the paths to the specified packages.

For example, running `npm ls promzard` in npm's source tree will show:

npm@@VERSION@ /path/to/npm

└─┬ init-package-json@0.0.4

└── promzard@0.1.5

dependencies, not the physical layout of your node_modules folder.

You can use the `npm org` commands to manage and view users of an organization.

It supports adding and removing users, changing their roles, listing them, and

finding specific ones and their roles.

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 currently-installed version.

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](npm-dist-tag).

* `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

* 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.

* `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.

* ls:

List all the users who have access to modify a package and push new versions.

Handy when you need to know who to bug for help.

* add:

Add a new user as a maintainer of a package. This user is enabled to modify

metadata, publish new versions, and add other owners.

* rm:

Remove a user from the package owner list. This immediately revokes their

privileges.

If you have two-factor authentication enabled with `auth-and-writes` then

you'll need to include an otp on the command line when changing ownership

with `--otp`.

tarball url, name@tag, name@version, name, or scoped name), this

command will fetch it to the cache, and then copy the tarball to the

current working directory as `<name>-<version>.tgz`, and then write

the filenames out to stdout.

actually packing anything. Reports on what would have gone into the tarball.