1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
|
.\" Generated with Ronnjs/v0.1
.\" http://github.com/kapouer/ronnjs/
.
.TH "NPM\-FOLDERS" "1" "April 2011" "" ""
.
.SH "NAME"
\fBnpm-folders\fR \-\- Folder Structures Used by npm
.
.SH "DESCRIPTION"
npm puts various things on your computer\. That\'s its job\.
.
.P
This document will tell you what it puts where\.
.
.SS "prefix Configuration"
The \fBprefix\fR config defaults to node\'s \fBprocess\.installPrefix\fR\|\. On most
systems, this is \fB/usr/local\fR\|\.
.
.P
When 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\.
.
.SS "Node Modules"
Packages 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/path/to/sub/module")\fR to load other modules\.
.
.P
If you wish to install node modules globally which can be loaded via \fBrequire()\fR from anywhere, then add the \fBprefix/node_modules\fR folder to
your NODE_PATH environment variable\.
.
.SS "Executables"
When in global mode, executables are linked into \fBprefix/bin\fR\|\.
.
.P
When in local mode, executables are linked into \fBprefix/node_modules/\.bin\fR\|\.
.
.SS "Man Pages"
When in global mode, man pages are linked into \fBprefix/share/man\fR\|\.
.
.P
When in local node, man pages are not installed\.
.
.SS "Cache"
See \fBnpm help cache\fR\|\. Cache files are stored in \fB~/\.npm\fR on Posix, or \fB~/npm\-cache\fR on Windows\.
.
.P
This is controlled by the \fBcache\fR configuration param\.
.
.SS "Temp Files"
Temporary files are stored by default in the folder specified by the \fBtmp\fR config, which defaults to either the TMPDIR environment
variable, or \fB/tmp\fR\|\.
.
.P
Temp files are given a unique folder under this root for each run of the
program, and are deleted upon successful exit\.
.
.SH "More Information"
When you run \fBnpm install foo@1\.2\.3\fR it downloads and builds the
package, and then, if there is a package\.json file in the current
working directory, it copies it to \fB$PWD/node_modules/foo\fR, so that your
current package will get it when you do \fBrequire("foo")\fR\|\.
.
.P
When this is done, it also installs all of foo\'s dependencies to \fB\|\./node_modules/foo/node_modules/\fR, so that it will get its dependencies
appropriately when it calls \fBrequire()\fR\|\. If foo depends on bar, and bar
depends on baz, then there will also be a \fB\|\./node_modules/foo/node_modules/bar/node_modules/baz\fR, and so on\.
.
.P
If there is not a package\.json in the current working directory, then
npm walks up the working dir parent paths looking for a package\.json,
indicating the root of a package, or a node_modules folder,
indicating an npm package deployment location, and then take the party to that
location\. This behavior may be suppressed by setting the \fBseek\-root\fR
config value to false\.
.
.P
If no package root is found, then a global installation is performed\.
The global installation may be supressed by setting the \fBglobal\fR
configuration to false, in which case, the install will fail\.
.
.SS "Global Installation"
If the \fBglobal\fR configuration is set to true, or if it is not explicitly
set false and no suitable node_modules folder was found, then npm will
install packages "globally"\.
.
.P
This means that the module contents are symlinked (or, on windows,
copied) from \fBroot/<name>/<version>/package\fR to \fBroot/node_modules/<name>\fR\|\.
.
.SS "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\fImodules folders\. So, at every
stage, if a package is already installed in an ancestor node\fRmodules
folder, then it is not installed at the current location\.
.
.P
Consider 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: foo/node\fImodules/bar/node\fRmodules/baz, there\'s no need to
put another copy of bar into \.\.\./baz/node\fImodules, since when it calls
require("bar"), it will get the copy that is installed in
foo/node\fRmodules/bar\.
.
.P
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 \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\.
.
.P
Another optimization can be made by installing dependencies at the
highest level possible, below the localized "target" folder\.
.
.P
For example, consider this dependency graph:
.
.IP "" 4
.
.nf
foo
+\-\- bar@1\.2\.3
| +\-\- baz@2\.x
| | `\-\- quux@3\.x
| | `\-\- bar@1\.2\.3 (cycle)
| `\-\- asdf@*
`\-\- baz@1\.2\.3
`\-\- quux@3\.x
`\-\- bar
.
.fi
.
.IP "" 0
.
.P
In this case, we might expect a folder structure like this:
.
.IP "" 4
.
.nf
foo
+\-\- node_modules
+\-\- bar (1\.2\.3)
| +\-\- node_modules
| | `\-\- baz (2\.0\.2)
| | `\-\- node_modules
| | `\-\- quux (3\.2\.0)
| `\-\- asdf (2\.3\.4)
`\-\- baz (1\.2\.3)
`\-\- node_modules
`\-\- quux (3\.2\.0)
`\-\- node_modules
`\-\- bar (1\.2\.3)
`\-\- node_modules
`\-\- asdf (2\.3\.4)
.
.fi
.
.IP "" 0
.
.P
Since foo depends directly on bar@1\.2\.3 and baz@1\.2\.3, those are
installed in foo\'s node_modules folder\.
.
.P
Bar has dependencies on baz and asdf, so those are installed in bar\'s
node\fImodules folder\. Baz has a dependency on quux, so that is installed
in its node\fRmodules folder\.
.
.P
Underneath bar, the \fBbaz\->quux\->bar\fR dependency creates a cycle\.
However, because \fBbar\fR is already in \fBquux\fR\'s ancestry, it does not
unpack another copy of bar into that folder\.
.
.P
Similarly, underneath \fBfoo\->baz\fR, the same cycle is gradually prevented
because \fBbar\fR\'s \fBquux\fR dependency is satisfied by its parent folder\.
.
.P
For a graphical breakdown of what is installed where, use \fBnpm ls\fR\|\.
.
.SS "Publishing"
Upon publishing, npm will look in the node_modules folder\. If any of
the items there are on the "dependencies" or "devDependencies" list,
and are not in the \fBbundledDependencies\fR array, then they will not be
included in the package tarball\.
.
.P
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\.
|
