codekingpro/portable-devtools

1.TH "FOLDERS" "5" "March 2026" "NPM@11.12.1" ""
2.SH "NAME"
3\fBFolders\fR - Folder structures used by npm
4.SS "Description"
5.P
6npm puts various things on your computer. That's its job.
7.P
8This document will tell you what it puts where.
9.SS "tl;dr"
10.RS 0
11.IP \(bu 4
12Local install (default): puts stuff in \fB./node_modules\fR of the current package root.
13.IP \(bu 4
14Global install (with \fB-g\fR): puts stuff in /usr/local or wherever node is installed.
15.IP \(bu 4
16Install it \fBlocally\fR if you're going to \fBrequire()\fR it.
17.IP \(bu 4
18Install it \fBglobally\fR if you're going to run it on the command line.
19.IP \(bu 4
20If you need both, then install it in both places, or use \fBnpm link\fR.
21.RE 0
22
23.SS "prefix Configuration"
24.P
25The \fB\[rs]fBprefix\[rs]fR config\fR \fI\(la/using-npm/config#prefix\(ra\fR defaults to the location where node is installed. On most systems, this is \fB/usr/local\fR. On Windows, it's \fB%AppData%\[rs]npm\fR. On Unix systems, it's one level up, since node is typically installed at \fB{prefix}/bin/node\fR rather than \fB{prefix}/node.exe\fR.
26.P
27When the \fBglobal\fR 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.
28.SS "Node Modules"
29.P
30Packages are dropped into the \fBnode_modules\fR folder under the \fBprefix\fR. When installing locally, this means that you can \fBrequire("packagename")\fR to load its main module, or \fBrequire("packagename/lib/path/to/sub/module")\fR to load other modules.
31.P
32Global installs on Unix systems go to \fB{prefix}/lib/node_modules\fR. Global installs on Windows go to \fB{prefix}/node_modules\fR (that is, no \fBlib\fR folder.)
33.P
34Scoped packages are installed the same way, except they are grouped together in a sub-folder of the relevant \fBnode_modules\fR folder with the name of that scope prefix by the @ symbol, e.g. \fBnpm install @myorg/package\fR would place the package in \fB{prefix}/node_modules/@myorg/package\fR. See npm help scope for more details.
35.P
36If you wish to \fBrequire()\fR a package, then install it locally.
37.SS "Executables"
38.P
39When in global mode, executables are linked into \fB{prefix}/bin\fR on Unix, or directly into \fB{prefix}\fR on Windows. Ensure that path is in your terminal's \fBPATH\fR environment to run them.
40.P
41When in local mode, executables are linked into \fB./node_modules/.bin\fR so that they can be made available to scripts run through npm. (For example, so that a test runner will be in the path when you run \fBnpm test\fR.)
42.SS "Man Pages"
43.P
44When in global mode, man pages are linked into \fB{prefix}/share/man\fR.
45.P
46When in local mode, man pages are not installed.
47.P
48Man pages are not installed on Windows systems.
49.SS "Cache"
50.P
51See npm help cache. Cache files are stored in \fB~/.npm\fR on Posix, or \fB%LocalAppData%/npm-cache\fR on Windows.
52.P
53This is controlled by the \fB\[rs]fBcache\[rs]fR config\fR \fI\(la/using-npm/config#cache\(ra\fR param.
54.SS "More Information"
55.P
56When installing locally, npm first tries to find an appropriate \fBprefix\fR folder. This is so that \fBnpm install foo@1.2.3\fR will install to the sensible root of your package, even if you happen to have \fBcd\fRed into some other folder.
57.P
58Starting at the $PWD, npm will walk up the folder tree checking for a folder that contains either a \fBpackage.json\fR file, or a \fBnode_modules\fR 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.)
59.P
60If no package root is found, then the current folder is used.
61.P
62When you run \fBnpm install foo@1.2.3\fR, then the package is loaded into the cache, and then unpacked into \fB./node_modules/foo\fR. Then, any of foo's dependencies are similarly unpacked into \fB./node_modules/foo/node_modules/...\fR.
63.P
64Any bin files are symlinked to \fB./node_modules/.bin/\fR, so that they may be found by npm scripts when necessary.
65.SS "Global Installation"
66.P
67If the \fB\[rs]fBglobal\[rs]fR config\fR \fI\(la/using-npm/config#global\(ra\fR is set to true, then npm will install packages "globally".
68.P
69For global installation, packages are installed roughly the same way, but using the folders described above.
70.SS "Cycles, Conflicts, and Folder Parsimony"
71.P
72Cycles are handled using the property of node's module system that it walks up the directories looking for \fBnode_modules\fR folders. So, at every stage, if a package is already installed in an ancestor \fBnode_modules\fR folder, then it is not installed at the current location.
73.P
74Consider the case above, where \fBfoo -> bar -> baz\fR. Imagine if, in addition to that, baz depended on bar, so you'd have: \fBfoo -> bar -> baz -> bar -> baz ...\fR. However, since the folder structure is: \fBfoo/node_modules/bar/node_modules/baz\fR, there's no need to put another copy of bar into \fB.../baz/node_modules\fR, since when baz calls \fBrequire("bar")\fR, it will get the copy that is installed in \fBfoo/node_modules/bar\fR.
75.P
76This shortcut is only used if the exact same version would be installed in multiple nested \fBnode_modules\fR folders. It is still possible to have \fBa/node_modules/b/node_modules/a\fR if the two "a" packages are different versions. However, without repeating the exact same package multiple times, an infinite regress will always be prevented.
77.P
78Another optimization can be made by installing dependencies at the highest level possible, below the localized "target" folder (hoisting). Since version 3, npm hoists dependencies by default.
79.SS "Example"
80.P
81Consider this dependency graph:
82.P
83.RS 2
84.nf
85foo
86+-- blerg@1.2.5
87+-- bar@1.2.3
88|   +-- blerg@1.x (latest=1.3.7)
89|   +-- baz@2.x
90|   |   `-- quux@3.x
91|   |       `-- bar@1.2.3 (cycle)
92|   `-- asdf@*
93`-- baz@1.2.3
94    `-- quux@3.x
95        `-- bar
96.fi
97.RE
98.P
99In this case, we might expect a folder structure like this (with all dependencies hoisted to the highest level possible):
100.P
101.RS 2
102.nf
103foo
104+-- node_modules
105    +-- blerg (1.2.5) <---\[lB]A\[rB]
106    +-- bar (1.2.3) <---\[lB]B\[rB]
107    |   +-- node_modules
108    |       +-- baz (2.0.2) <---\[lB]C\[rB]
109    +-- asdf (2.3.4)
110    +-- baz (1.2.3) <---\[lB]D\[rB]
111    +-- quux (3.2.0) <---\[lB]E\[rB]
112.fi
113.RE
114.P
115Since foo depends directly on \fBbar@1.2.3\fR and \fBbaz@1.2.3\fR, those are installed in foo's \fBnode_modules\fR folder.
116.P
117Even 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 \[lB]A\[rB]. Since the parent installation of blerg satisfies bar's dependency on \fBblerg@1.x\fR, it does not install another copy under \[lB]B\[rB].
118.P
119Bar \[lB]B\[rB] also has dependencies on baz and asdf. Because it depends on \fBbaz@2.x\fR, it cannot re-use the \fBbaz@1.2.3\fR installed in the parent \fBnode_modules\fR folder \[lB]D\[rB], and must install its own copy \[lB]C\[rB]. In order to minimize duplication, npm hoists dependencies to the top level by default, so asdf is installed under \[lB]A\[rB].
120.P
121Underneath bar, the \fBbaz -> quux -> bar\fR dependency creates a cycle. However, because bar is already in quux's ancestry \[lB]B\[rB], it does not unpack another copy of bar into that folder. Likewise, quux's \[lB]E\[rB] folder tree is empty, because its dependency on bar is satisfied by the parent folder copy installed at \[lB]B\[rB].
122.P
123For a graphical breakdown of what is installed where, use \fBnpm ls\fR.
124.SS "Publishing"
125.P
126Upon publishing, npm will look in the \fBnode_modules\fR folder. If any of the items there are not in the \fBbundleDependencies\fR array, then they will not be included in the package tarball.
127.P
128This 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 \fB\[rs]fBpackage.json\[rs]fR\fR \fI\(la/configuring-npm/package-json\(ra\fR for more information.
129.SS "See also"
130.RS 0
131.IP \(bu 4
132\fBpackage.json\fR \fI\(la/configuring-npm/package-json\(ra\fR
133.IP \(bu 4
134npm help install
135.IP \(bu 4
136npm help pack
137.IP \(bu 4
138npm help cache
139.IP \(bu 4
140npm help config
141.IP \(bu 4
142npm help npmrc
143.IP \(bu 4
144npm help config
145.IP \(bu 4
146npm help publish
147.RE 0
148