npm-folders(1) -- Folder Structures Used by npm
npm puts various things on your computer. That's its job.
This document will tell you what it puts where.
- Local install (default): puts stuff in
- Global install (with
-g): puts stuff in /usr/local
- Install it locally if you're going to
- Install it globally if you're going to run it on the command line.
- If you need both, then install it in both places, or use
prefix config defaults to the location where node is installed.
On most systems, this is
/usr/local, and most of the time is the same
global flag is set, npm installs things into this prefix.
When it is not set, it uses the root of the current package, or the
current working directory if not in a package already.
Packages are dropped into the
node_modules folder under the
When installing locally, this means that you can
require("packagename") to load its main module, or
require("packagename/lib/path/to/sub/module") to load other modules.
If you wish to
require() a package, then install it locally.
When in global mode, executables are linked into
When in local mode, executables are linked into
When in global mode, man pages are linked into
When in local mode, man pages are not installed.
npm-cache(1). Cache files are stored in
~/.npm on Posix, or
~/npm-cache on Windows.
This is controlled by the
cache configuration param.
Temporary files are stored by default in the folder specified by the
tmp config, which defaults to either the TMPDIR environment
Temp files are given a unique folder under this root for each run of the program, and are deleted upon successful exit.
When doing local installings, npm first tries to find an appropriate
prefix folder. This is so that
npm install email@example.com will install
to the sensible root of your package, even if you happen to have
into some other folder.
Starting at the $PWD, npm will walk up the folder tree checking for a
folder that contains either a
package.json file, or a
folder. If such a thing is found, then that is treated as the effective
"current directory" for the purpose of running npm commands. (This
behavior is inspired by and similar to git's .git-folder seeking
logic when running git commands in a working dir.)
If no package root is found, then the current folder is used.
When you run
npm install firstname.lastname@example.org, then the package is loaded into
the cache, and then unpacked into
./node_modules/foo. Then, any of
foo's dependencies are similarly unpacked into
Any bin files are symlinked to
./node_modules/.bin/, so that they may
be found by npm scripts when necessary.
global configuration is set to true, then npm will
install packages "globally".
For global installation, packages are installed roughly the same way,
but the module root is
/usr/local/lib/node_modules, and bin files are
/usr/local/bin instead of
Cycles, Conflicts, and Folder Parsimony
Cycles are handled using the property of node's module system that it
walks up the directories looking for
node_modules folders. So, at every
stage, if a package is already installed in an ancestor
folder, then it is not installed at the current location.
Consider the case above, where
foo -> bar -> baz. Imagine if, in
addition to that, baz depended on bar, so you'd have:
foo -> bar -> baz -> bar -> baz .... However, since the folder
foo/node_modules/bar/node_modules/baz, there's no need to
put another copy of bar into
.../baz/node_modules, since when it calls
require("bar"), it will get the copy that is installed in
This shortcut is only used if the exact same
version would be installed in multiple nested
node_modules folders. It
is still possible to have
a/node_modules/b/node_modules/a if the two
"a" packages are different versions. However, without repeating the
exact same package multiple times, an infinite regress will always be
Another optimization can be made by installing dependencies at the highest level possible, below the localized "target" folder.
Consider this dependency graph:
foo +-- email@example.com +-- firstname.lastname@example.org | +-- email@example.com (latest=1.3.7) | +-- firstname.lastname@example.org | | `-- email@example.com | | `-- firstname.lastname@example.org (cycle) | `-- asdf@* `-- email@example.com `-- firstname.lastname@example.org `-- bar
In this case, we might expect a folder structure like this:
foo +-- node_modules +-- blerg (1.2.5) <---[A] +-- bar (1.2.3) <---[B] | +-- node_modules | | `-- baz (2.0.2) <---[C] | | `-- node_modules | | `-- quux (3.2.0) | `-- asdf (2.3.4) `-- baz (1.2.3) <---[D] `-- node_modules `-- quux (3.2.0) <---[E]
Since foo depends directly on email@example.com and firstname.lastname@example.org, those are
installed in foo's
Even though the latest copy of blerg is 1.3.7, foo has a specific dependency on version 1.2.5. So, that gets installed at [A]. Since the parent installation of blerg satisfie's bar's dependency on email@example.com, it does not install another copy under [B].
Bar [B] also has dependencies on baz and asdf, so those are installed in
node_modules folder. Because it depends on
firstname.lastname@example.org, it cannot
email@example.com installed in the parent
node_modules folder [D],
and must install its own copy [C].
Underneath bar, the
baz->quux->bar dependency creates a cycle.
bar is already in
quux's ancestry [B], it does not
unpack another copy of bar into that folder.
foo->baz [D], quux's [E] folder tree is empty, because its
dependency on bar is satisfied by the parent folder copy installed at [B].
For a graphical breakdown of what is installed where, use
Upon publishing, npm will look in the
node_modules folder. If any of
the items there are not in the
bundledDependencies array, then they will
not be included in the package tarball.
This allows a package maintainer to install all of their dependencies
(and dev dependencies) locally, but only re-publish those items that
cannot be found elsewhere. See
npm-json(1) for more information.