mirror of https://github.com/lukechilds/node.git
isaacs
12 years ago
139 changed files with 1401 additions and 389 deletions
@ -0,0 +1,209 @@ |
|||
npm-folders(1) -- Folder Structures Used by npm |
|||
=============================================== |
|||
|
|||
## DESCRIPTION |
|||
|
|||
npm puts various things on your computer. That's its job. |
|||
|
|||
This document will tell you what it puts where. |
|||
|
|||
### tl;dr |
|||
|
|||
* Local install (default): puts stuff in `./node_modules` of the current |
|||
package root. |
|||
* Global install (with `-g`): puts stuff in /usr/local or wherever node |
|||
is installed. |
|||
* Install it **locally** if you're going to `require()` it. |
|||
* 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 `npm link`. |
|||
|
|||
### prefix Configuration |
|||
|
|||
The `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 |
|||
as node's `process.installPrefix`. |
|||
|
|||
On windows, this is the exact location of the node.exe binary. On Unix |
|||
systems, it's one level up, since node is typically installed at |
|||
`{prefix}/bin/node` rather than `{prefix}/node.exe`. |
|||
|
|||
When the `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. |
|||
|
|||
### Node Modules |
|||
|
|||
Packages are dropped into the `node_modules` folder under the `prefix`. |
|||
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. |
|||
|
|||
Global installs on Unix systems go to `{prefix}/lib/node_modules`. |
|||
Global installs on Windows go to `{prefix}/node_modules` (that is, no |
|||
`lib` folder.) |
|||
|
|||
If you wish to `require()` a package, then install it locally. |
|||
|
|||
### Executables |
|||
|
|||
When in global mode, executables are linked into `{prefix}/bin` on Unix, |
|||
or directly into `{prefix}` on Windows. |
|||
|
|||
When in local mode, executables are linked into |
|||
`./node_modules/.bin` 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 `npm test`.) |
|||
|
|||
### Man Pages |
|||
|
|||
When in global mode, man pages are linked into `{prefix}/share/man`. |
|||
|
|||
When in local mode, man pages are not installed. |
|||
|
|||
Man pages are not installed on Windows systems. |
|||
|
|||
### Cache |
|||
|
|||
See `npm-cache(1)`. Cache files are stored in `~/.npm` on Posix, or |
|||
`~/npm-cache` on Windows. |
|||
|
|||
This is controlled by the `cache` configuration param. |
|||
|
|||
### Temp Files |
|||
|
|||
Temporary files are stored by default in the folder specified by the |
|||
`tmp` config, which defaults to the TMPDIR, TMP, or TEMP environment |
|||
variables, or `/tmp` on Unix and `c:\windows\temp` on Windows. |
|||
|
|||
Temp files are given a unique folder under this root for each run of the |
|||
program, and are deleted upon successful exit. |
|||
|
|||
## More Information |
|||
|
|||
When installing locally, npm first tries to find an appropriate |
|||
`prefix` folder. This is so that `npm install foo@1.2.3` will install |
|||
to the sensible root of your package, even if you happen to have `cd`ed |
|||
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 `node_modules` |
|||
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 foo@1.2.3`, 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 |
|||
`./node_modules/foo/node_modules/...`. |
|||
|
|||
Any bin files are symlinked to `./node_modules/.bin/`, so that they may |
|||
be found by npm scripts when necessary. |
|||
|
|||
### Global Installation |
|||
|
|||
If the `global` configuration is set to true, then npm will |
|||
install packages "globally". |
|||
|
|||
For global installation, packages are installed roughly the same way, |
|||
but using the folders described above. |
|||
|
|||
### 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 `node_modules` |
|||
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 |
|||
structure is: `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 |
|||
`foo/node_modules/bar`. |
|||
|
|||
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 |
|||
prevented. |
|||
|
|||
Another optimization can be made by installing dependencies at the |
|||
highest level possible, below the localized "target" folder. |
|||
|
|||
#### Example |
|||
|
|||
Consider this dependency graph: |
|||
|
|||
foo |
|||
+-- blerg@1.2.5 |
|||
+-- bar@1.2.3 |
|||
| +-- blerg@1.x (latest=1.3.7) |
|||
| +-- baz@2.x |
|||
| | `-- quux@3.x |
|||
| | `-- bar@1.2.3 (cycle) |
|||
| `-- asdf@* |
|||
`-- baz@1.2.3 |
|||
`-- quux@3.x |
|||
`-- 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 bar@1.2.3 and baz@1.2.3, those are |
|||
installed in foo's `node_modules` folder. |
|||
|
|||
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 blerg@1.x, |
|||
it does not install another copy under [B]. |
|||
|
|||
Bar [B] also has dependencies on baz and asdf, so those are installed in |
|||
bar's `node_modules` folder. Because it depends on `baz@2.x`, it cannot |
|||
re-use the `baz@1.2.3` 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. |
|||
However, because `bar` is already in `quux`'s ancestry [B], it does not |
|||
unpack another copy of bar into that folder. |
|||
|
|||
Underneath `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 `npm ls`. |
|||
|
|||
### Publishing |
|||
|
|||
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. |
|||
|
|||
## SEE ALSO |
|||
|
|||
* npm-faq(1) |
|||
* npm-json(1) |
|||
* npm-install(1) |
|||
* npm-pack(1) |
|||
* npm-cache(1) |
|||
* npm-config(1) |
|||
* npm-publish(1) |
|||
@ -0,0 +1,19 @@ |
|||
npm-rm(1) -- Remove a package |
|||
============================= |
|||
|
|||
## SYNOPSIS |
|||
|
|||
npm rm <name> |
|||
npm uninstall <name> |
|||
|
|||
## DESCRIPTION |
|||
|
|||
This uninstalls a package, completely removing everything npm installed |
|||
on its behalf. |
|||
|
|||
## SEE ALSO |
|||
|
|||
* npm-prune(1) |
|||
* npm-install(1) |
|||
* npm-folders(1) |
|||
* npm-config(1) |
|||
@ -0,0 +1,240 @@ |
|||
<!doctype html> |
|||
<html> |
|||
<title>global</title> |
|||
<meta http-equiv="content-type" value="text/html;utf-8"> |
|||
<link rel="stylesheet" type="text/css" href="../static/style.css"> |
|||
|
|||
<body> |
|||
<div id="wrapper"> |
|||
<h1><a href="../doc/folders.html">folders</a></h1> <p>Folder Structures Used by npm</p> |
|||
|
|||
<h2 id="DESCRIPTION">DESCRIPTION</h2> |
|||
|
|||
<p>npm puts various things on your computer. That's its job.</p> |
|||
|
|||
<p>This document will tell you what it puts where.</p> |
|||
|
|||
<h3 id="tl-dr">tl;dr</h3> |
|||
|
|||
<ul><li>Local install (default): puts stuff in <code>./node_modules</code> of the current |
|||
package root.</li><li>Global install (with <code>-g</code>): puts stuff in /usr/local or wherever node |
|||
is installed.</li><li>Install it <strong>locally</strong> if you're going to <code>require()</code> it.</li><li>Install it <strong>globally</strong> if you're going to run it on the command line.</li><li>If you need both, then install it in both places, or use <code>npm link</code>.</li></ul> |
|||
|
|||
<h3 id="prefix-Configuration">prefix Configuration</h3> |
|||
|
|||
<p>The <code>prefix</code> config defaults to the location where node is installed. |
|||
On most systems, this is <code>/usr/local</code>, and most of the time is the same |
|||
as node's <code>process.installPrefix</code>.</p> |
|||
|
|||
<p>On windows, this is the exact location of the node.exe binary. On Unix |
|||
systems, it's one level up, since node is typically installed at |
|||
<code>{prefix}/bin/node</code> rather than <code>{prefix}/node.exe</code>.</p> |
|||
|
|||
<p>When the <code>global</code> 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.</p> |
|||
|
|||
<h3 id="Node-Modules">Node Modules</h3> |
|||
|
|||
<p>Packages are dropped into the <code>node_modules</code> folder under the <code>prefix</code>. |
|||
When installing locally, this means that you can |
|||
<code>require("packagename")</code> to load its main module, or |
|||
<code>require("packagename/lib/path/to/sub/module")</code> to load other modules.</p> |
|||
|
|||
<p>Global installs on Unix systems go to <code>{prefix}/lib/node_modules</code>. |
|||
Global installs on Windows go to <code>{prefix}/node_modules</code> (that is, no |
|||
<code>lib</code> folder.)</p> |
|||
|
|||
<p>If you wish to <code>require()</code> a package, then install it locally.</p> |
|||
|
|||
<h3 id="Executables">Executables</h3> |
|||
|
|||
<p>When in global mode, executables are linked into <code>{prefix}/bin</code> on Unix, |
|||
or directly into <code>{prefix}</code> on Windows.</p> |
|||
|
|||
<p>When in local mode, executables are linked into |
|||
<code>./node_modules/.bin</code> 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 <code>npm test</code>.)</p> |
|||
|
|||
<h3 id="Man-Pages">Man Pages</h3> |
|||
|
|||
<p>When in global mode, man pages are linked into <code>{prefix}/share/man</code>.</p> |
|||
|
|||
<p>When in local mode, man pages are not installed.</p> |
|||
|
|||
<p>Man pages are not installed on Windows systems.</p> |
|||
|
|||
<h3 id="Cache">Cache</h3> |
|||
|
|||
<p>See <code><a href="../doc/cache.html">cache(1)</a></code>. Cache files are stored in <code>~/.npm</code> on Posix, or |
|||
<code>~/npm-cache</code> on Windows.</p> |
|||
|
|||
<p>This is controlled by the <code>cache</code> configuration param.</p> |
|||
|
|||
<h3 id="Temp-Files">Temp Files</h3> |
|||
|
|||
<p>Temporary files are stored by default in the folder specified by the |
|||
<code>tmp</code> config, which defaults to the TMPDIR, TMP, or TEMP environment |
|||
variables, or <code>/tmp</code> on Unix and <code>c:\windows\temp</code> on Windows.</p> |
|||
|
|||
<p>Temp files are given a unique folder under this root for each run of the |
|||
program, and are deleted upon successful exit.</p> |
|||
|
|||
<h2 id="More-Information">More Information</h2> |
|||
|
|||
<p>When installing locally, npm first tries to find an appropriate |
|||
<code>prefix</code> folder. This is so that <code>npm install foo@1.2.3</code> will install |
|||
to the sensible root of your package, even if you happen to have <code>cd</code>ed |
|||
into some other folder.</p> |
|||
|
|||
<p>Starting at the $PWD, npm will walk up the folder tree checking for a |
|||
folder that contains either a <code>package.json</code> file, or a <code>node_modules</code> |
|||
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.)</p> |
|||
|
|||
<p>If no package root is found, then the current folder is used.</p> |
|||
|
|||
<p>When you run <code>npm install foo@1.2.3</code>, then the package is loaded into |
|||
the cache, and then unpacked into <code>./node_modules/foo</code>. Then, any of |
|||
foo's dependencies are similarly unpacked into |
|||
<code>./node_modules/foo/node_modules/...</code>.</p> |
|||
|
|||
<p>Any bin files are symlinked to <code>./node_modules/.bin/</code>, so that they may |
|||
be found by npm scripts when necessary.</p> |
|||
|
|||
<h3 id="Global-Installation">Global Installation</h3> |
|||
|
|||
<p>If the <code>global</code> configuration is set to true, then npm will |
|||
install packages "globally".</p> |
|||
|
|||
<p>For global installation, packages are installed roughly the same way, |
|||
but using the folders described above.</p> |
|||
|
|||
<h3 id="Cycles-Conflicts-and-Folder-Parsimony">Cycles, Conflicts, and Folder Parsimony</h3> |
|||
|
|||
<p>Cycles are handled using the property of node's module system that it |
|||
walks up the directories looking for <code>node_modules</code> folders. So, at every |
|||
stage, if a package is already installed in an ancestor <code>node_modules</code> |
|||
folder, then it is not installed at the current location.</p> |
|||
|
|||
<p>Consider the case above, where <code>foo -> bar -> baz</code>. Imagine if, in |
|||
addition to that, baz depended on bar, so you'd have: |
|||
<code>foo -> bar -> baz -> bar -> baz ...</code>. However, since the folder |
|||
structure is: <code>foo/node_modules/bar/node_modules/baz</code>, there's no need to |
|||
put another copy of bar into <code>.../baz/node_modules</code>, since when it calls |
|||
require("bar"), it will get the copy that is installed in |
|||
<code>foo/node_modules/bar</code>.</p> |
|||
|
|||
<p>This shortcut is only used if the exact same |
|||
version would be installed in multiple nested <code>node_modules</code> folders. It |
|||
is still possible to have <code>a/node_modules/b/node_modules/a</code> 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> |
|||
|
|||
<p>Another optimization can be made by installing dependencies at the |
|||
highest level possible, below the localized "target" folder.</p> |
|||
|
|||
<h4 id="Example">Example</h4> |
|||
|
|||
<p>Consider this dependency graph:</p> |
|||
|
|||
<pre><code>foo |
|||
+-- blerg@1.2.5 |
|||
+-- bar@1.2.3 |
|||
| +-- blerg@1.x (latest=1.3.7) |
|||
| +-- baz@2.x |
|||
| | `-- quux@3.x |
|||
| | `-- bar@1.2.3 (cycle) |
|||
| `-- asdf@* |
|||
`-- baz@1.2.3 |
|||
`-- quux@3.x |
|||
`-- bar</code></pre> |
|||
|
|||
<p>In this case, we might expect a folder structure like this:</p> |
|||
|
|||
<pre><code>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]</code></pre> |
|||
|
|||
<p>Since foo depends directly on bar@1.2.3 and baz@1.2.3, those are |
|||
installed in foo's <code>node_modules</code> folder.</p> |
|||
|
|||
<p>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 blerg@1.x, |
|||
it does not install another copy under [B].</p> |
|||
|
|||
<p>Bar [B] also has dependencies on baz and asdf, so those are installed in |
|||
bar's <code>node_modules</code> folder. Because it depends on <code>baz@2.x</code>, it cannot |
|||
re-use the <code>baz@1.2.3</code> installed in the parent <code>node_modules</code> folder [D], |
|||
and must install its own copy [C].</p> |
|||
|
|||
<p>Underneath bar, the <code>baz->quux->bar</code> dependency creates a cycle. |
|||
However, because <code>bar</code> is already in <code>quux</code>'s ancestry [B], it does not |
|||
unpack another copy of bar into that folder.</p> |
|||
|
|||
<p>Underneath <code>foo->baz</code> [D], quux's [E] folder tree is empty, because its |
|||
dependency on bar is satisfied by the parent folder copy installed at [B].</p> |
|||
|
|||
<p>For a graphical breakdown of what is installed where, use <code>npm ls</code>.</p> |
|||
|
|||
<h3 id="Publishing">Publishing</h3> |
|||
|
|||
<p>Upon publishing, npm will look in the <code>node_modules</code> folder. If any of |
|||
the items there are not in the <code>bundledDependencies</code> array, then they will |
|||
not be included in the package tarball.</p> |
|||
|
|||
<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. See <code><a href="../doc/json.html">json(1)</a></code> for more information.</p> |
|||
|
|||
<h2 id="SEE-ALSO">SEE ALSO</h2> |
|||
|
|||
<ul><li><a href="../doc/faq.html">faq(1)</a></li><li><a href="../doc/json.html">json(1)</a></li><li><a href="../doc/install.html">install(1)</a></li><li><a href="../doc/pack.html">pack(1)</a></li><li><a href="../doc/cache.html">cache(1)</a></li><li><a href="../doc/config.html">config(1)</a></li><li><a href="../doc/publish.html">publish(1)</a></li></ul> |
|||
</div> |
|||
<p id="footer">global — npm@1.2.3</p> |
|||
<script> |
|||
;(function () { |
|||
var wrapper = document.getElementById("wrapper") |
|||
var els = Array.prototype.slice.call(wrapper.getElementsByTagName("*"), 0) |
|||
.filter(function (el) { |
|||
return el.parentNode === wrapper |
|||
&& el.tagName.match(/H[1-6]/) |
|||
&& el.id |
|||
}) |
|||
var l = 2 |
|||
, toc = document.createElement("ul") |
|||
toc.innerHTML = els.map(function (el) { |
|||
var i = el.tagName.charAt(1) |
|||
, out = "" |
|||
while (i > l) { |
|||
out += "<ul>" |
|||
l ++ |
|||
} |
|||
while (i < l) { |
|||
out += "</ul>" |
|||
l -- |
|||
} |
|||
out += "<li><a href='#" + el.id + "'>" + |
|||
( el.innerText || el.text || el.innerHTML) |
|||
+ "</a>" |
|||
return out |
|||
}).join("\n") |
|||
toc.id = "toc" |
|||
document.body.appendChild(toc) |
|||
})() |
|||
</script> |
|||
</body></html> |
|||
@ -0,0 +1,57 @@ |
|||
<!doctype html> |
|||
<html> |
|||
<title>rm</title> |
|||
<meta http-equiv="content-type" value="text/html;utf-8"> |
|||
<link rel="stylesheet" type="text/css" href="../static/style.css"> |
|||
|
|||
<body> |
|||
<div id="wrapper"> |
|||
<h1><a href="../doc/rm.html">rm</a></h1> <p>Remove a package</p> |
|||
|
|||
<h2 id="SYNOPSIS">SYNOPSIS</h2> |
|||
|
|||
<pre><code>npm rm <name> |
|||
npm uninstall <name></code></pre> |
|||
|
|||
<h2 id="DESCRIPTION">DESCRIPTION</h2> |
|||
|
|||
<p>This uninstalls a package, completely removing everything npm installed |
|||
on its behalf.</p> |
|||
|
|||
<h2 id="SEE-ALSO">SEE ALSO</h2> |
|||
|
|||
<ul><li><a href="../doc/prune.html">prune(1)</a></li><li><a href="../doc/install.html">install(1)</a></li><li><a href="../doc/folders.html">folders(1)</a></li><li><a href="../doc/config.html">config(1)</a></li></ul> |
|||
</div> |
|||
<p id="footer">rm — npm@1.2.3</p> |
|||
<script> |
|||
;(function () { |
|||
var wrapper = document.getElementById("wrapper") |
|||
var els = Array.prototype.slice.call(wrapper.getElementsByTagName("*"), 0) |
|||
.filter(function (el) { |
|||
return el.parentNode === wrapper |
|||
&& el.tagName.match(/H[1-6]/) |
|||
&& el.id |
|||
}) |
|||
var l = 2 |
|||
, toc = document.createElement("ul") |
|||
toc.innerHTML = els.map(function (el) { |
|||
var i = el.tagName.charAt(1) |
|||
, out = "" |
|||
while (i > l) { |
|||
out += "<ul>" |
|||
l ++ |
|||
} |
|||
while (i < l) { |
|||
out += "</ul>" |
|||
l -- |
|||
} |
|||
out += "<li><a href='#" + el.id + "'>" + |
|||
( el.innerText || el.text || el.innerHTML) |
|||
+ "</a>" |
|||
return out |
|||
}).join("\n") |
|||
toc.id = "toc" |
|||
document.body.appendChild(toc) |
|||
})() |
|||
</script> |
|||
</body></html> |
|||
Some files were not shown because too many files changed in this diff
Loading…
Reference in new issue