3f419fa9cb26501ac338d40628ab63a73f7f40c9
[platform/upstream/nodejs.git] / deps / npm / man / man5 / npm-global.5
1 .\" Generated with Ronnjs 0.3.8
2 .\" http://github.com/kapouer/ronnjs/
3 .
4 .TH "NPM\-FOLDERS" "5" "November 2013" "" ""
5 .
6 .SH "NAME"
7 \fBnpm-folders\fR \-\- Folder Structures Used by npm
8 .
9 .SH "DESCRIPTION"
10 npm puts various things on your computer\.  That\'s its job\.
11 .
12 .P
13 This document will tell you what it puts where\.
14 .
15 .SS "tl;dr"
16 .
17 .IP "\(bu" 4
18 Local install (default): puts stuff in \fB\|\./node_modules\fR of the current
19 package root\.
20 .
21 .IP "\(bu" 4
22 Global install (with \fB\-g\fR): puts stuff in /usr/local or wherever node
23 is installed\.
24 .
25 .IP "\(bu" 4
26 Install it \fBlocally\fR if you\'re going to \fBrequire()\fR it\.
27 .
28 .IP "\(bu" 4
29 Install it \fBglobally\fR if you\'re going to run it on the command line\.
30 .
31 .IP "\(bu" 4
32 If you need both, then install it in both places, or use \fBnpm link\fR\|\.
33 .
34 .IP "" 0
35 .
36 .SS "prefix Configuration"
37 The \fBprefix\fR config defaults to the location where node is installed\.
38 On most systems, this is \fB/usr/local\fR, and most of the time is the same
39 as node\'s \fBprocess\.installPrefix\fR\|\.
40 .
41 .P
42 On windows, this is the exact location of the node\.exe binary\.  On Unix
43 systems, it\'s one level up, since node is typically installed at \fB{prefix}/bin/node\fR rather than \fB{prefix}/node\.exe\fR\|\.
44 .
45 .P
46 When the \fBglobal\fR flag is set, npm installs things into this prefix\.
47 When it is not set, it uses the root of the current package, or the
48 current working directory if not in a package already\.
49 .
50 .SS "Node Modules"
51 Packages are dropped into the \fBnode_modules\fR folder under the \fBprefix\fR\|\.
52 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\.
53 .
54 .P
55 Global installs on Unix systems go to \fB{prefix}/lib/node_modules\fR\|\.
56 Global installs on Windows go to \fB{prefix}/node_modules\fR (that is, no \fBlib\fR folder\.)
57 .
58 .P
59 If you wish to \fBrequire()\fR a package, then install it locally\.
60 .
61 .SS "Executables"
62 When in global mode, executables are linked into \fB{prefix}/bin\fR on Unix,
63 or directly into \fB{prefix}\fR on Windows\.
64 .
65 .P
66 When in local mode, executables are linked into \fB\|\./node_modules/\.bin\fR so that they can be made available to scripts run
67 through npm\.  (For example, so that a test runner will be in the path
68 when you run \fBnpm test\fR\|\.)
69 .
70 .SS "Man Pages"
71 When in global mode, man pages are linked into \fB{prefix}/share/man\fR\|\.
72 .
73 .P
74 When in local mode, man pages are not installed\.
75 .
76 .P
77 Man pages are not installed on Windows systems\.
78 .
79 .SS "Cache"
80 npm help See \fBnpm\-cache\fR\|\.  Cache files are stored in \fB~/\.npm\fR on Posix, or \fB~/npm\-cache\fR on Windows\.
81 .
82 .P
83 This is controlled by the \fBcache\fR configuration param\.
84 .
85 .SS "Temp Files"
86 Temporary files are stored by default in the folder specified by the \fBtmp\fR config, which defaults to the TMPDIR, TMP, or TEMP environment
87 variables, or \fB/tmp\fR on Unix and \fBc:\\windows\\temp\fR on Windows\.
88 .
89 .P
90 Temp files are given a unique folder under this root for each run of the
91 program, and are deleted upon successful exit\.
92 .
93 .SH "More Information"
94 When 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
95 to the sensible root of your package, even if you happen to have \fBcd\fRed
96 into some other folder\.
97 .
98 .P
99 Starting at the $PWD, npm will walk up the folder tree checking for a
100 folder that contains either a \fBpackage\.json\fR file, or a \fBnode_modules\fR
101 folder\.  If such a thing is found, then that is treated as the effective
102 "current directory" for the purpose of running npm commands\.  (This
103 behavior is inspired by and similar to git\'s \.git\-folder seeking
104 logic when running git commands in a working dir\.)
105 .
106 .P
107 If no package root is found, then the current folder is used\.
108 .
109 .P
110 When you run \fBnpm install foo@1\.2\.3\fR, then the package is loaded into
111 the cache, and then unpacked into \fB\|\./node_modules/foo\fR\|\.  Then, any of
112 foo\'s dependencies are similarly unpacked into \fB\|\./node_modules/foo/node_modules/\.\.\.\fR\|\.
113 .
114 .P
115 Any bin files are symlinked to \fB\|\./node_modules/\.bin/\fR, so that they may
116 be found by npm scripts when necessary\.
117 .
118 .SS "Global Installation"
119 If the \fBglobal\fR configuration is set to true, then npm will
120 install packages "globally"\.
121 .
122 .P
123 For global installation, packages are installed roughly the same way,
124 but using the folders described above\.
125 .
126 .SS "Cycles, Conflicts, and Folder Parsimony"
127 Cycles are handled using the property of node\'s module system that it
128 walks up the directories looking for \fBnode_modules\fR folders\.  So, at every
129 stage, if a package is already installed in an ancestor \fBnode_modules\fR
130 folder, then it is not installed at the current location\.
131 .
132 .P
133 Consider the case above, where \fBfoo \-> bar \-> baz\fR\|\.  Imagine if, in
134 addition to that, baz depended on bar, so you\'d have: \fBfoo \-> bar \-> baz \-> bar \-> baz \.\.\.\fR\|\.  However, since the folder
135 structure is: \fBfoo/node_modules/bar/node_modules/baz\fR, there\'s no need to
136 put another copy of bar into \fB\|\.\.\./baz/node_modules\fR, since when it calls
137 require("bar"), it will get the copy that is installed in \fBfoo/node_modules/bar\fR\|\.
138 .
139 .P
140 This shortcut is only used if the exact same
141 version would be installed in multiple nested \fBnode_modules\fR folders\.  It
142 is still possible to have \fBa/node_modules/b/node_modules/a\fR if the two
143 "a" packages are different versions\.  However, without repeating the
144 exact same package multiple times, an infinite regress will always be
145 prevented\.
146 .
147 .P
148 Another optimization can be made by installing dependencies at the
149 highest level possible, below the localized "target" folder\.
150 .
151 .SS "\fIExample\fR"
152 Consider this dependency graph:
153 .
154 .IP "" 4
155 .
156 .nf
157 foo
158 +\-\- blerg@1\.2\.5
159 +\-\- bar@1\.2\.3
160 |   +\-\- blerg@1\.x (latest=1\.3\.7)
161 |   +\-\- baz@2\.x
162 |   |   `\-\- quux@3\.x
163 |   |       `\-\- bar@1\.2\.3 (cycle)
164 |   `\-\- asdf@*
165 `\-\- baz@1\.2\.3
166     `\-\- quux@3\.x
167         `\-\- bar
168 .
169 .fi
170 .
171 .IP "" 0
172 .
173 .P
174 In this case, we might expect a folder structure like this:
175 .
176 .IP "" 4
177 .
178 .nf
179 foo
180 +\-\- node_modules
181     +\-\- blerg (1\.2\.5) <\-\-\-[A]
182     +\-\- bar (1\.2\.3) <\-\-\-[B]
183     |   `\-\- node_modules
184     |       +\-\- baz (2\.0\.2) <\-\-\-[C]
185     |       |   `\-\- node_modules
186     |       |       `\-\- quux (3\.2\.0)
187     |       `\-\- asdf (2\.3\.4)
188     `\-\- baz (1\.2\.3) <\-\-\-[D]
189         `\-\- node_modules
190             `\-\- quux (3\.2\.0) <\-\-\-[E]
191 .
192 .fi
193 .
194 .IP "" 0
195 .
196 .P
197 Since foo depends directly on \fBbar@1\.2\.3\fR and \fBbaz@1\.2\.3\fR, those are
198 installed in foo\'s \fBnode_modules\fR folder\.
199 .
200 .P
201 Even though the latest copy of blerg is 1\.3\.7, foo has a specific
202 dependency on version 1\.2\.5\.  So, that gets installed at [A]\.  Since the
203 parent installation of blerg satisfies bar\'s dependency on \fBblerg@1\.x\fR,
204 it does not install another copy under [B]\.
205 .
206 .P
207 Bar [B] also has dependencies on baz and asdf, so those are installed in
208 bar\'s \fBnode_modules\fR folder\.  Because it depends on \fBbaz@2\.x\fR, it cannot
209 re\-use the \fBbaz@1\.2\.3\fR installed in the parent \fBnode_modules\fR folder [D],
210 and must install its own copy [C]\.
211 .
212 .P
213 Underneath bar, the \fBbaz \-> quux \-> bar\fR dependency creates a cycle\.
214 However, because bar is already in quux\'s ancestry [B], it does not
215 unpack another copy of bar into that folder\.
216 .
217 .P
218 Underneath \fBfoo \-> baz\fR [D], quux\'s [E] folder tree is empty, because its
219 dependency on bar is satisfied by the parent folder copy installed at [B]\.
220 .
221 .P
222 For a graphical breakdown of what is installed where, use \fBnpm ls\fR\|\.
223 .
224 .SS "Publishing"
225 Upon publishing, npm will look in the \fBnode_modules\fR folder\.  If any of
226 the items there are not in the \fBbundledDependencies\fR array, then they will
227 not be included in the package tarball\.
228 .
229 .P
230 This allows a package maintainer to install all of their dependencies
231 (and dev dependencies) locally, but only re\-publish those items that
232 npm help  cannot be found elsewhere\.  See \fBpackage\.json\fR for more information\.
233 .
234 .SH "SEE ALSO"
235 .
236 .IP "\(bu" 4
237 npm help  faq
238 .
239 .IP "\(bu" 4
240 npm help  package\.json
241 .
242 .IP "\(bu" 4
243 npm help install
244 .
245 .IP "\(bu" 4
246 npm help pack
247 .
248 .IP "\(bu" 4
249 npm help cache
250 .
251 .IP "\(bu" 4
252 npm help config
253 .
254 .IP "\(bu" 4
255 npm help  npmrc
256 .
257 .IP "\(bu" 4
258 npm help  config
259 .
260 .IP "\(bu" 4
261 npm help publish
262 .
263 .IP "" 0
264