deps: throw StackOverflow in JSON.parse

Backport of:

fc6343a79274b6a1e99037ebb131096e2da05306

from v8 upstream.

Original commit message:

    Catch stack overflow in JSON.parse.

    BUG=

    Review URL: https://chromiumcodereview.appspot.com/11275039

    git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@12816 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Reviewed-By: Fedor Indutny <fedor@indutny.com>

AUTHORS

@@ -356,3 +356,33 @@ Gil Pedersen <git@gpost.dk>
 Tyler Neylon <tylerneylon@gmail.com>
 Golo Roden <webmaster@goloroden.de>
 Ron Korving <rkorving@wizcorp.jp>
+Brandon Wilson <chlavois@gmail.com>
+Bearice Ren <bearice@gmail.com>
+Ankur Oberoi <aoberoi@gmail.com>
+Atsuya Takagi <atsuya.takagi@gmail.com>
+Pooya Karimian <pkarimian@sencha.com>
+Frédéric Germain <frederic.germain@gmail.com>
+Robin Lee <cheeselee@fedoraproject.org>
+Adam Blackburn <regality@gmail.com>
+Willi Eggeling <email@wje-online.de>
+Andrew Paprocki <andrew@ishiboo.com>
+Max Ogden <max@maxogden.com>
+Olivier Lalonde <olalonde@gmail.com>
+Francois Marier <francois@mozilla.com>
+Trevor Norris <trev.norris@gmail.com>
+Joshua Erickson <josh@snoj.us>
+Kai Sasaki Lewuathe <sasaki_kai@lewuathe.sakura.ne.jp>
+Nicolas Chambrier <naholyr@gmail.com>
+Tim Bradshaw <tfb@cley.com>
+Johannes Ewald <mail@johannesewald.de>
+Chris Dent <chris.dent@gmail.com>
+Dan Milon <danmilon@gmail.com>
+Jacob Gable <jacob.gable@gmail.com>
+Rick Yakubowski <richard@orpha-systems.com>
+Dan Kohn <dan@dankohn.com>
+Timothy J Fontaine <tjfontaine@gmail.com>
+Eugene Girshov <eugene.girshov@nixu.com>
+Raymond Feng <enjoyjava@gmail.com>
+Tobias Müllerleile <tobias@muellerleile.net>
+Daniel Chatfield <chatfielddaniel@gmail.com>
+cjihrig <cjihrig@gmail.com>

CONTRIBUTING.md

@@ -0,0 +1,145 @@
+# CONTRIBUTING
+
+The node.js project welcomes new contributors.  This document will guide you
+through the process.
+
+
+### FORK
+
+Fork the project [on GitHub](https://github.com/joyent/node) and check out
+your copy.
+
+```
+$ git clone git@github.com:username/node.git
+$ cd node
+$ git remote add upstream git://github.com/joyent/node.git
+```
+
+Now decide if you want your feature or bug fix to go into the master branch
+or the stable branch.  As a rule of thumb, bug fixes go into the stable branch
+while new features go into the master branch.
+
+The stable branch is effectively frozen; patches that change the node.js
+API/ABI or affect the run-time behavior of applications get rejected.
+
+The rules for the master branch are less strict; consult the
+[stability index page][] for details.
+
+In a nutshell, modules are at varying levels of API stability.  Bug fixes are
+always welcome but API or behavioral  changes to modules at stability level 3
+and up are off-limits.
+
+Node.js has several bundled dependencies in the deps/ and the tools/
+directories that are not part of the project proper.  Any changes to files
+in those directories or its subdirectories should be sent to their respective
+projects.  Do not send your patch to us, we cannot accept it.
+
+In case of doubt, open an issue in the [issue tracker][], post your question
+to the [node.js mailing list][] or contact one of the [project maintainers][]
+on [IRC][].
+
+Especially do so if you plan to work on something big.  Nothing is more
+frustrating than seeing your hard work go to waste because your vision
+does not align with that of a project maintainer.
+
+
+### BRANCH
+
+Okay, so you have decided on the proper branch.  Create a feature branch
+and start hacking:
+
+```
+$ git checkout -b my-feature-branch -t origin/v0.8
+```
+
+(Where v0.8 is the latest stable branch as of this writing.)
+
+
+### COMMIT
+
+Make sure git knows your name and email address:
+
+```
+$ git config --global user.name "J. Random User"
+$ git config --global user.email "j.random.user@example.com"
+```
+
+Writing good commit logs is important.  A commit log should describe what
+changed and why.  Follow these guidelines when writing one:
+
+1. The first line should be 50 characters or less and contain a short
+   description of the change.
+2. Keep the second line blank.
+3. Wrap all other lines at 72 columns.
+
+A good commit log looks like this:
+
+```
+Header line: explaining the commit in one line
+
+Body of commit message is a few lines of text, explaining things
+in more detail, possibly giving some background about the issue
+being fixed, etc etc.
+
+The body of the commit message can be several paragraphs, and
+please do proper word-wrap and keep columns shorter than about
+72 characters or so. That way `git log` will show things
+nicely even when it is indented.
+```
+
+The header line should be meaningful; it is what other people see when they
+run `git shortlog` or `git log --oneline`.
+
+Have a look at `git log` for inspiration.
+
+
+### REBASE
+
+Use `git rebase` (not `git merge`) to sync your work from time to time.
+
+```
+$ git fetch upstream
+$ git rebase upstream/v0.8  # or upstream/master
+```
+
+
+### TEST
+
+Bug fixes and features should come with tests.  Add your tests in the
+test/simple/ directory.  Look at other tests to see how they should be
+structured (license boilerplate, common includes, etc.).
+
+```
+$ make jslint test
+```
+
+Make sure the linter is happy and that all tests pass.  Please, do not submit
+patches that fail either check.
+
+
+### PUSH
+
+```
+$ git push origin my-feature-branch
+```
+
+Go to https://github.com/username/node and select your feature branch.  Click
+the 'Pull Request' button and fill out the form.
+
+Pull requests are usually reviewed within a few days.  If there are comments
+to address, apply your changes in a separate commit and push that to your
+feature branch.  Post a comment in the pull request afterwards; GitHub does
+not send out notifications when you add commits.
+
+
+### CONTRIBUTOR LICENSE AGREEMENT
+
+Please visit http://nodejs.org/cla.html and sign the Contributor License
+Agreement.  You only need to do that once.
+
+
+[stability index page]: https://github.com/joyent/node/blob/master/doc/api/documentation.markdown
+[issue tracker]: https://github.com/joyent/node/issues
+[node.js mailing list]: http://groups.google.com/group/nodejs
+[IRC]: http://webchat.freenode.net/?channels=node.js
+[project maintainers]: https://github.com/joyent/node/wiki/Project-Organization

ChangeLog

@@ -1,4 +1,289 @@
-2012.09.11, Version 0.8.9 (Stable)
+2014.07.31, Version 0.8.28 (maintenance)
+
+* v8: Interrupts must not mask stack overflow. (Fedor Indutny)
+
+
+2014.06.09, Version 0.8.27 (maintenance), a69205346b09eb3fd21e9530a75868b92102e039
+
+* openssl: update to 1.0.0m (CVE-2014-0224)
+
+* utf8: Prevent Node from sending invalid UTF-8 (Felix Geisendörfer)
+  - *NOTE* this introduces a breaking change, previously you could construct
+    invalid UTF-8 and invoke an error in a client that was expecting valid
+    UTF-8, now unmatched surrogate pairs are replaced with the unknown UTF-8
+    character. To restore the old functionality simply have NODE_INVALID_UTF8
+    environment variable set.
+
+* tls: fix pool usage race (Fedor Indutny)
+
+* fs: close file if fstat() fails in readFile() (cjihrig)
+
+
+2013.10.13, Version 0.8.26 (maintenance), 6d391bbbe18217ce20c15c3da2bad71ef836922c
+
+* v8: Upgrade to 3.11.10.26
+
+* crypto: clear openssl error stack when handled (Ben Noordhuis)
+
+* crypto: clear errors from verify failure (Timothy J Fontaine)
+
+* crypto: fix memory leak in LoadPKCS12 (Fedor Indutny)
+
+* http: provide backpressure for pipeline flood (isaacs)
+
+* http_parser: expose pause/resume method for parser (Timothy J Fontaine)
+
+* readline: pause stdin before turning off terminal raw mode (Daniel Chatfield)
+
+
+2013.06.13, Version 0.8.25 (maintenance), 0b9bdb2bc7e1c872f0ea4713517fda22a4b0b202
+
+* npm: Upgrade to 1.2.30
+
+* child_process: fix handle delivery (Ben Noordhuis)
+
+
+2013.06.04, Version 0.8.24 (maintenance), c1a1ab067721ea17ef7b05ec5c68b01321017f05
+
+* npm: Upgrade to v1.2.24
+
+* url: Properly parse certain oddly formed urls (isaacs)
+
+* http: Don't try to destroy nonexistent sockets (isaacs)
+
+* handle_wrap: fix NULL pointer dereference (Ben Noordhuis)
+
+
+2013.04.09, Version 0.8.23 (maintenance), c67f8d0500fe15637a623eb759d2ad7eb9fb3b0b
+
+* npm: Upgrade to v1.2.18
+
+* http: Avoid EE warning on ECONNREFUSED handling (isaacs)
+
+* tls: Re-enable check of CN-ID in cert verification (Tobias Müllerleile)
+
+* child_process: fix sending utf-8 to child process (Ben Noordhuis)
+
+* crypto: check key type in GetPeerCertificate() (Ben Noordhuis)
+
+* win/openssl: mark assembled object files as seh safe (Bert Belder)
+
+* windows/msi: fix msi build issue with WiX 3.7/3.8 (Raymond Feng)
+
+
+2013.03.07, Version 0.8.22 (Stable), 67a4cb4fe8c2346e30ffb83f7178e205cc2dab33
+
+* npm: Update to 1.2.14
+
+* cluster: propagate bind errors (Ben Noordhuis)
+
+* crypto: don't assert when calling Cipher#final() twice (Ben Noordhuis)
+
+* build, windows: disable SEH (Ben Noordhuis)
+
+
+2013.02.25, Version 0.8.21 (Stable), 530d8c05d4c546146f18e5ba811d7eb3b7b7c0c5
+
+* http: Do not free the wrong parser on socket close (isaacs)
+
+* http: Handle hangup writes more gently (isaacs)
+
+* zlib: fix assert on bad input (Ben Noordhuis)
+
+* test: add TAP output to the test runner (Timothy J Fontaine)
+
+* unix: Handle EINPROGRESS from domain sockets (Ben Noordhuis)
+
+
+2013.02.15, Version 0.8.20 (Stable), e10c75579b536581ddd7ae4e2c3bf8a9d550d343
+
+* npm: Upgrade to v1.2.11
+
+* http: Do not let Agent hand out destroyed sockets (isaacs)
+
+* http: Raise hangup error on destroyed socket write (isaacs)
+
+* http: protect against response splitting attacks (Bert Belder)
+
+
+2013.02.06, Version 0.8.19 (Stable), 53978bdf420622ff0121c63c0338c9e7c2e60869
+
+* npm: Upgrade to v1.2.10
+
+* zlib: pass object size hint to V8 (Ben Noordhuis)
+
+* zlib: reduce memory consumption, release early (Ben Noordhuis)
+
+* buffer: slow buffer copy compatibility fix (Trevor Norris)
+
+* zlib: don't assert on malformed dictionary (Ben Noordhuis)
+
+* zlib: don't assert on missing dictionary (Ben Noordhuis)
+
+* windows: better ipv6 support (Bert Belder)
+
+* windows: add error mappings related to unsupported protocols (Bert Belder)
+
+* windows: map ERROR_DIRECTORY to UV_ENOENT (Bert Belder)
+
+
+2013.01.18, Version 0.8.18 (Stable), 2c4eef0d972838c51999d32c0d251857a713dc18
+
+* npm: Upgrade to v1.2.2
+
+* dns: make error message match errno (Dan Milon)
+
+* tls: follow RFC6125 more stricly (Fedor Indutny)
+
+* buffer: reject negative SlowBuffer offsets (Ben Noordhuis)
+
+* install: add simplejson fallback (Chris Dent)
+
+* http: fix "Cannot call method 'emit' of null" (Ben Noordhuis)
+
+
+2013.01.09, Version 0.8.17 (Stable), c50c33e9397d7a0a8717e8ce7530572907c054ad
+
+* npm: Upgrade to v1.2.0
+  - peerDependencies (Domenic Denicola)
+  - node-gyp v0.8.2 (Nathan Rajlich)
+  - Faster installs from github user/project shorthands (Nathan Zadoks)
+
+* typed arrays: fix 32 bit size/index overflow (Ben Noordhuis)
+
+* http: Improve performance of single-packet responses (Ben Noordhuis)
+
+* install: fix openbsd man page location (Ben Noordhuis)
+
+* http: bubble up parser errors to ClientRequest (Brian White)
+
+
+2012.12.13, Version 0.8.16 (Stable), 1c9c6277d5cfcaaac8569c0c8f7daa64292048a9
+
+* npm: Upgrade to 1.1.69
+
+* fs: fix WriteStream/ReadStream fd leaks (Ben Noordhuis)
+
+* crypto: fix leak in GetPeerCertificate (Fedor Indutny)
+
+* buffer: Don't double-negate numeric buffer arg (Trevor Norris)
+
+* net: More accurate IP address validation and IPv6 dotted notation. (Joshua Erickson)
+
+
+2012.11.26, Version 0.8.15 (Stable), fdf91afb494a7a2fff2913d817f589c191a2c88f
+
+* npm: Upgrade to 1.1.66 (isaacs)
+
+* linux: use /proc/cpuinfo for CPU frequency (Ben Noordhuis)
+
+* windows: map WSAESHUTDOWN to UV_EPIPE (Ben Noordhuis)
+
+* windows: map ERROR_GEN_FAILURE to UV_EIO (Bert Belder)
+
+* unix: do not set environ unless one is provided (Charlie McConnell)
+
+* domains: don't crash if domain is set to null (Bert Belder)
+
+* windows: fix the x64 debug build (Bert Belder)
+
+* net, tls: fix connect() resource leak (Ben Noordhuis)
+
+
+2012.10.25, Version 0.8.14 (Stable), b00527fcf05c3d9f/b5d5d790f9472906a59fe218
+
+* events: Don't clobber pre-existing _events obj in EE ctor (isaacs)
+
+
+2012.10.25, Version 0.8.13 (Stable), ff4c974873f9a7cc6a5b042eb9b6389bb8dde6d6
+
+* V8: Upgrade to 3.11.10.25
+
+* npm: Upgrade to 1.1.65
+
+* url: parse hostnames that start with - or _ (Ben Noordhuis)
+
+* repl: Fix Windows 8 terminal issue (Bert Belder)
+
+* typed arrays: use signed char for signed int8s (Aaron Jacobs)
+
+* crypto: fix bugs in DiffieHellman (Ben Noordhuis)
+
+* configure: turn on VFPv3 on ARMv7 (Ben Noordhuis)
+
+* Re-enable OpenSSL UI for entering passphrases via tty (Ben Noordhuis)
+
+* repl: ensure each REPL instance gets its own "context" (Nathan Rajlich)
+
+
+2012.10.12, Version 0.8.12 (Stable), 38c72d4e29574dec5205bcf23c2a85efe65331a4
+
+* npm: Upgrade to 1.1.63
+
+* crypto: Reduce stability index to 2-Unstable (isaacs)
+
+* windows: fix handle leak in uv_fs_utime (Bert Belder)
+
+* windows: fix application crashed popup in debug version (Bert Belder)
+
+* buffer: report proper retained size in profiler (Ben Noordhuis)
+
+* buffer: fix byteLength with UTF-16LE (koichik)
+
+* repl: make "end of input" JSON.parse() errors throw in the REPL (Nathan Rajlich)
+
+* repl: make invalid RegExp modifiers throw in the REPL (Nathan Rajlich)
+
+* http: handle multiple Proxy-Authenticate values (Willi Eggeling)
+
+
+2012.09.27, Version 0.8.11 (Stable), e1f39468fa580c1e4cb15fac621f87944ee625dc
+
+* fs: Fix stat() size reporting for large files (Ben Noordhuis)
+
+
+2012.09.25, Version 0.8.10 (Stable), 0bc273da4fcaa79b209ed755ad249a3e7be626a6
+
+* npm: Upgrade to 1.1.62
+
+* repl: make invalid RegExps throw in the REPL (Nathan Rajlich)
+
+* v8: loosen artificial mmap constraint (Bryan Cantrill)
+
+* process: fix setuid() and setgid() error reporting (Ben Noordhuis)
+
+* domain: Properly exit() on domain disposal (isaacs)
+
+* fs: fix watchFile() missing deletion events (Ben Noordhuis)
+
+* fs: fix assert in fs.watch() (Ben Noordhuis)
+
+* fs: don't segfault on deeply recursive stat() (Ben Noordhuis)
+
+* http: Remove timeout handler when data arrives (Frédéric Germain)
+
+* http: make the client "res" object gets the same domain as "req" (Nathan Rajlich)
+
+* windows: don't blow up when an invalid FD is used (Bert Belder)
+
+* unix: map EDQUOT to UV_ENOSPC (Charlie McConnell)
+
+* linux: improve /proc/cpuinfo parser (Ben Noordhuis)
+
+* win/tty: reset background brightness when color is set to default (Bert Belder)
+
+* unix: put child process stdio fds in blocking mode (Ben Noordhuis)
+
+* unix: fix EMFILE busy loop (Ben Noordhuis)
+
+* sunos: don't set TCP_KEEPALIVE (Ben Noordhuis)
+
+* tls: Use slab allocator for memory management (Fedor Indutny)
+
+* openssl: Use optimized assembly code for x86 and x64 (Bert Belder)
+
+
+2012.09.11, Version 0.8.9 (Stable), b88c3902b241cf934e75443b934f2033ad3915b1
 
 * v8: upgrade to 3.11.10.22
 
@@ -719,7 +1004,7 @@
 * Bug fixes
 
 
-2012.07.10 Version 0.6.20 (maintenance)
+2012.07.10 Version 0.6.20 (maintenance), 952e513379169ec1b40909d1db056e9bf4294899
 
 * npm: Upgrade to 1.1.37 (isaacs)
 
@@ -1082,7 +1367,7 @@
 * crypto: don't ignore DH init errors (Ben Noordhuis)
 
 
-2011.12.14, Version 0.6.6
+2011.12.14, Version 0.6.6 (stable), 9a059ea69e1f6ebd8899246682d8ca257610b8ab
 
 * npm update to 1.1.0-beta-4 (Isaac Z. Schlueter)
 
@@ -1319,7 +1604,7 @@ koichik, Maciej Małecki, Guglielmo Ferri, isaacs)
 * Upgrade GYP to r1081
 
 
-2011.10.10, Version 0.5.9 (unstable)
+2011.10.10, Version 0.5.9 (unstable), 3bd9b08fb125b606f97a4079b147accfdeebb07d
 
 * fs.watch interface backed by kqueue, inotify, and ReadDirectoryChangesW
   (Igor Zinkovsky, Ben Noordhuis)
@@ -1403,7 +1688,7 @@ koichik, Maciej Małecki, Guglielmo Ferri, isaacs)
 * #1719 Drain OpenSSL error queue
 
 
-2011.09.08, Version 0.5.6 (unstable)
+2011.09.08, Version 0.5.6 (unstable), b49bec55806574a47403771bce1ee379c2b09ca2
 
 * #345, #1635, #1648 Documentation improvements (Thomas Shinnick,
   Abimanyu Raja, AJ ONeal, Koichi Kobayashi, Michael Jackson, Logan Smyth,
@@ -1691,7 +1976,7 @@ koichik, Maciej Małecki, Guglielmo Ferri, isaacs)
 * DTrace probes: support X-Forwarded-For (Dave Pacheco)
 
 
-2011.09.15, Version 0.4.12 (stable)
+2011.09.15, Version 0.4.12 (stable), 771ba34ca7b839add2ef96879e1ffc684813cf7c
 
 * Improve docs
 
@@ -1740,7 +2025,7 @@ koichik, Maciej Małecki, Guglielmo Ferri, isaacs)
 * Doc improvments (koichik, Logan Smyth, Ben Noordhuis, Arnout Kazemier)
 
 
-2011.07.19, Version 0.4.10 (stable)
+2011.07.19, Version 0.4.10 (stable), 1b8dd65d6e3b82b6863ef38835cc436c5d30c1d5
 
 * #394 Fix Buffer drops last null character in UTF-8
 
@@ -1767,7 +2052,7 @@ koichik, Maciej Małecki, Guglielmo Ferri, isaacs)
 * Doc improvements
 
 
-2011.06.29, Version 0.4.9 (stable)
+2011.06.29, Version 0.4.9 (stable), de44eafd7854d06cd85006f509b7051e8540589b
 
 * Improve documentation
 
@@ -1841,7 +2126,7 @@ koichik, Maciej Małecki, Guglielmo Ferri, isaacs)
 * Upgrade V8 to 3.1.8.16.
 
 
-2011.04.22, Version 0.4.7 (stable)
+2011.04.22, Version 0.4.7 (stable), c85455a954411b38232e79752d4abb61bb75031b
 
 * Don't emit error on ECONNRESET from read() #670
 
@@ -1859,7 +2144,7 @@ koichik, Maciej Małecki, Guglielmo Ferri, isaacs)
 * Improve docs.
 
 
-2011.04.13, Version 0.4.6 (stable)
+2011.04.13, Version 0.4.6 (stable), 58002d56bc79410c5ff397fc0e1ffec0665db38a
 
 * Don't error on ENOTCONN from shutdown() #670
 
@@ -1889,7 +2174,7 @@ koichik, Maciej Małecki, Guglielmo Ferri, isaacs)
 * Upgrade v8 to 3.1.8.10
 
 
-2011.04.01, Version 0.4.5 (stable)
+2011.04.01, Version 0.4.5 (stable), 787a343b588de26784fef97f953420b53a6e1d73
 
 * Fix listener leak in stream.pipe() (Mikeal Rogers)
 
@@ -2022,7 +2307,7 @@ koichik, Maciej Małecki, Guglielmo Ferri, isaacs)
 * Upgrade V8 to 3.1.5, libev to 4.4.
 
 
-2011.02.10, Version 0.4.0 (stable)
+2011.02.10, Version 0.4.0 (stable), eb155ea6f6a6aa341aa8c731dca8da545c6a4008
 
 * require() improvements (isaacs)
   - understand package.json (isaacs)
@@ -2055,7 +2340,7 @@ koichik, Maciej Małecki, Guglielmo Ferri, isaacs)
 * Upgrade V8 to 3.1.2
 
 
-2011.02.04, Version 0.3.8 (unstable)
+2011.02.04, Version 0.3.8 (unstable), 9493b7563bff31525b4080df5aeef09747782d5e
 
 * Add req.abort() for client side requests.
 
@@ -2077,7 +2362,7 @@ koichik, Maciej Małecki, Guglielmo Ferri, isaacs)
 
 * Upgrade V8 to 3.1.1
 
-2011.01.27, Version 0.3.7 (unstable)
+2011.01.27, Version 0.3.7 (unstable), d8579c6afdbe868de6dffa8db78bbe4ba2d03e0e
 
 * Expose agent in http and https client. (Mikeal Rogers)
 
@@ -2139,7 +2424,7 @@ koichik, Maciej Małecki, Guglielmo Ferri, isaacs)
 * Don't stat() on cached modules. (Felix Geisendörfer)
 
 
-2011.01.08, Version 0.3.4 (unstable)
+2011.01.08, Version 0.3.4 (unstable), 73f53e12e4a5b9ef7dbb4792bd5f8ad403094441
 
 * Primordial mingw build (Bert Belder)
 
@@ -2357,7 +2642,7 @@ koichik, Maciej Małecki, Guglielmo Ferri, isaacs)
 * Upgrade V8 to 2.3.8
 
 
-2010.08.13, Version 0.1.104
+2010.08.13, Version 0.1.104, b14dd49222687c12f3e8eac597cff4f2674f84e8
 
 * Various bug fixes (console, querystring, require)
 

Makefile

@@ -248,7 +248,7 @@ $(PKG): release-only
 	rm -rf out/deps out/Release
 	./configure --prefix=$(PKGDIR)/usr/local --without-snapshot --dest-cpu=x64
 	$(MAKE) install V=$(V)
-	SIGN="$(SIGN)" PKGDIR="$(PKGDIR)" bash tools/osx-codesign.sh
+	SIGN="$(APP_SIGN)" PKGDIR="$(PKGDIR)" bash tools/osx-codesign.sh
 	lipo $(PKGDIR)/32/usr/local/bin/node \
 		$(PKGDIR)/usr/local/bin/node \
 		-output $(PKGDIR)/usr/local/bin/node-universal \
@@ -259,7 +259,7 @@ $(PKG): release-only
 		--id "org.nodejs.Node" \
 		--doc tools/osx-pkg.pmdoc \
 		--out $(PKG)
-	SIGN="$(SIGN)" PKG="$(PKG)" bash tools/osx-productsign.sh
+	SIGN="$(INT_SIGN)" PKG="$(PKG)" bash tools/osx-productsign.sh
 
 $(TARBALL): release-only node doc
 	git archive --format=tar --prefix=$(TARNAME)/ HEAD | tar xf -
@@ -278,7 +278,7 @@ tar: $(TARBALL)
 $(BINARYTAR): release-only
 	rm -rf $(BINARYNAME)
 	rm -rf out/deps out/Release
-	./configure --prefix=/ --without-snapshot --dest-cpu=$(DESTCPU)
+	./configure --prefix=/ --without-snapshot --dest-cpu=$(DESTCPU) $(CONFIG_FLAGS)
 	$(MAKE) install DESTDIR=$(BINARYNAME) V=$(V) PORTABLE=1
 	cp README.md $(BINARYNAME)
 	cp LICENSE $(BINARYNAME)

README.md

@@ -15,6 +15,14 @@ Unix/Macintosh:
     make
     make install
 
+If your python binary is in a non-standard location or has a
+non-standard name, run the following instead:
+
+    export PYTHON=/path/to/python
+    $PYTHON ./configure
+    make
+    make install
+
 Windows:
 
     vcbuild.bat

benchmark/http.sh

@@ -1,12 +1,43 @@
 #!/bin/bash
 cd "$(dirname "$(dirname $0)")"
-sudo sysctl -w net.inet.ip.portrange.first=12000
-sudo sysctl -w net.inet.tcp.msl=1000
-sudo sysctl -w kern.maxfiles=1000000 kern.maxfilesperproc=1000000
+
+if type sysctl &>/dev/null; then
+  # darwin and linux
+  sudo sysctl -w net.ipv4.ip_local_port_range="12000 65535"
+  sudo sysctl -w net.inet.ip.portrange.first=12000
+  sudo sysctl -w net.inet.tcp.msl=1000
+  sudo sysctl -w kern.maxfiles=1000000 kern.maxfilesperproc=1000000
+elif type /usr/sbin/ndd &>/dev/null; then
+  # sunos
+  /usr/sbin/ndd -set /dev/tcp tcp_smallest_anon_port 12000
+  /usr/sbin/ndd -set /dev/tcp tcp_largest_anon_port 65535
+  /usr/sbin/ndd -set /dev/tcp tcp_max_buf 2097152
+  /usr/sbin/ndd -set /dev/tcp tcp_xmit_hiwat 1048576
+  /usr/sbin/ndd -set /dev/tcp tcp_recv_hiwat 1048576
+fi
+
 ulimit -n 100000
 
-./node benchmark/http_simple.js || exit 1 &
+k=${KEEPALIVE}
+if [ "$k" = "no" ]; then
+  k=""
+else
+  k="-k"
+fi
+node=${NODE:-./node}
+
+$node benchmark/http_simple.js &
+npid=$!
+
 sleep 1
 
-ab -n 30000 -c 100 http://127.0.0.1:8000/${TYPE:-bytes}/${LENGTH:-1024} | grep Req
-killall node
+if [ "$k" = "-k" ]; then
+  echo "using keepalive"
+fi
+
+for i in a a a a a a a a a a a a a a a a a a a a; do
+  ab $k -t 10 -c 100 http://127.0.0.1:8000/${TYPE:-bytes}/${LENGTH:-1024} \
+    2>&1 | grep Req | egrep -o '[0-9\.]+'
+done
+
+kill $npid

benchmark/http_simple.js

@@ -96,13 +96,12 @@ var server = http.createServer(function (req, res) {
                             'Transfer-Encoding': 'chunked' });
     // send body in chunks
     var len = body.length;
-    var step = ~~(len / n_chunks) || len;
+    var step = Math.floor(len / n_chunks) || 1;
 
-    for (var i = 0; i < len; i += step) {
-      res.write(body.slice(i, i + step));
+    for (var i = 0, n = (n_chunks - 1); i < n; ++i) {
+      res.write(body.slice(i * step, i * step + step));
     }
-
-    res.end();
+    res.end(body.slice((n_chunks - 1) * step));
   } else {
     var content_length = body.length.toString();
 

benchmark/http_simple_auto.js

@@ -77,13 +77,12 @@ var server = http.createServer(function (req, res) {
                             "Transfer-Encoding": "chunked" });
     // send body in chunks
     var len = body.length;
-    var step = ~~(len / n_chunks) || len;
+    var step = Math.floor(len / n_chunks) || 1;
 
-    for (var i = 0; i < len; i += step) {
-      res.write(body.slice(i, i + step));
+    for (var i = 0, n = (n_chunks - 1); i < n; ++i) {
+      res.write(body.slice(i * step, i * step + step));
     }
-
-    res.end();
+    res.end(body.slice((n_chunks - 1) * step));
   } else {
     var content_length = body.length.toString();
 

configure

@@ -176,6 +176,17 @@ parser.add_option("--with-arm-float-abi",
     help="Specifies which floating-point ABI to use. Valid values are: "
          "soft, softfp, hard")
 
+# Using --unsafe-optimizations voids your warranty.
+parser.add_option("--unsafe-optimizations",
+    action="store_true",
+    dest="unsafe_optimizations",
+    help=optparse.SUPPRESS_HELP)
+
+parser.add_option("--tag",
+    action="store",
+    dest="tag",
+    help="Custom build tag")
+
 (options, args) = parser.parse_args()
 
 
@@ -322,12 +333,31 @@ def compiler_version():
   return (version, is_clang)
 
 
+def configure_arm(o):
+  # V8 on ARM requires that armv7 is set. CPU Model detected by
+  # the presence of __ARM_ARCH_7__ and the like defines in compiler
+  if options.arm_float_abi:
+    hard_float = options.arm_float_abi == 'hard'
+  else:
+    hard_float = arm_hard_float_abi()
+  o['variables']['v8_use_arm_eabi_hardfloat'] = b(hard_float)
+
+  armv7 = is_arch_armv7()
+  if armv7:
+    # CHECKME VFPv3 implies ARMv7+ but is the reverse true as well?
+    o['variables']['arm_fpu'] = 'vfpv3'
+    o['variables']['arm_neon'] = 0
+  o['variables']['armv7'] = int(armv7)
+
+
 def configure_node(o):
   # TODO add gdb
   o['variables']['v8_no_strict_aliasing'] = 1 # work around compiler bugs
   o['variables']['node_prefix'] = os.path.expanduser(options.prefix or '')
   o['variables']['node_install_npm'] = b(not options.without_npm)
   o['variables']['node_install_waf'] = b(not options.without_waf)
+  o['variables']['node_unsafe_optimizations'] = (
+    1 if options.unsafe_optimizations else 0)
   o['default_configuration'] = 'Debug' if options.debug else 'Release'
 
   host_arch = host_arch_win() if os.name == 'nt' else host_arch_cc()
@@ -335,15 +365,8 @@ def configure_node(o):
   o['variables']['host_arch'] = host_arch
   o['variables']['target_arch'] = target_arch
 
-  # V8 on ARM requires that armv7 is set. CPU Model detected by
-  # the presence of __ARM_ARCH_7__ and the like defines in compiler
   if target_arch == 'arm':
-    if options.arm_float_abi:
-      hard_float = options.arm_float_abi == 'hard'
-    else:
-      hard_float = arm_hard_float_abi()
-    o['variables']['v8_use_arm_eabi_hardfloat'] = b(hard_float)
-    o['variables']['armv7'] = 1 if is_arch_armv7() else 0
+    configure_arm(o)
 
   cc_version, is_clang = compiler_version()
   o['variables']['clang'] = 1 if is_clang else 0
@@ -376,6 +399,11 @@ def configure_node(o):
   else:
     o['variables']['node_use_etw'] = 'false'
 
+  if options.tag:
+    o['variables']['node_tag'] = '-' + options.tag
+  else:
+    o['variables']['node_tag'] = ''
+
 
 def configure_libz(o):
   o['variables']['node_shared_zlib'] = b(options.shared_zlib)

deps/npm/.npmignore

@@ -1,4 +1,5 @@
 *.swp
+.*.swp
 npm-debug.log
 /test/bin
 /test/output.log
@@ -20,3 +21,5 @@ html/*.png
 !.npmignore
 
 /npm-*.tgz
+
+*.pyc

deps/npm/.tern-project

@@ -0,0 +1,7 @@
+{
+  "libs": [
+  ],
+  "plugins": {
+    "node": {}
+  }
+}

deps/npm/AUTHORS

@@ -71,9 +71,22 @@ Domenic Denicola <domenic@domenicdenicola.com>
 James Halliday <mail@substack.net>
 Jeremy Cantrell <jmcantrell@gmail.com>
 Ribettes <patlogan29@gmail.com>
+Einar Otto Stangvik <einaros@gmail.com>
 Don Park <donpark@docuverse.com>
 Kei Son <heyacct@gmail.com>
 Nicolas Morel <marsup@gmail.com>
 Mark Dube <markisdee@gmail.com>
+Nathan Rajlich <nathan@tootallnate.net>
 Maxim Bogushevich <boga1@mail.ru>
 Justin Beckwith <justbe@microsoft.com>
+Meaglin <Meaglin.wasabi@gmail.com>
+Ben Evans <ben@bensbit.co.uk>
+Nathan Zadoks <nathan@nathan7.eu>
+Brian White <mscdex@gmail.com>
+Jed Schmidt <tr@nslator.jp>
+Ian Livingstone <ianl@cs.dal.ca>
+Patrick Pfeiffer <patrick@buzzle.at>
+Paul Miller <paul@paulmillr.com>
+seebees <seebees@gmail.com>
+Carl Lange <carl@flax.ie>
+Jan Lehnardt <jan@apache.org>

deps/npm/LICENSE

@@ -1,4 +1,4 @@
-Copyright 2009-2012, Isaac Z. Schlueter (the "Original Author")
+Copyright (c) Isaac Z. Schlueter (the "Original Author")
 All rights reserved.
 
 MIT +no-false-attribs License
@@ -42,23 +42,24 @@ Original Author, when distributed with the Software.
 part of the Node.js project, and is neither owned by nor
 officially affiliated with Joyent, Inc.
 
-Packages published in the npm registry are not part of npm
-itself, are the sole property of their respective maintainers,
-and are not covered by this license.
+Packages published in the npm registry (other than the Software and
+its included dependencies) are not part of npm itself, are the sole
+property of their respective maintainers, and are not covered by
+this license.
 
 "npm Logo" created by Mathias Pettersson and Brian Hammond,
 used with permission.
 
 "Gubblebum Blocky" font
-Copyright (c) 2007 by Tjarda Koster, http://jelloween.deviantart.com
+Copyright (c) by Tjarda Koster, http://jelloween.deviantart.com
 included for use in the npm website and documentation,
 used with permission.
 
-This program uses "node-uuid", Copyright (c) 2010 Robert Kieffer,
-according to the terms of the MIT license.
-
-This program uses "request", Copyright (c) 2011 Mikeal Rogers,
+This program uses "request", Copyright (c) Mikeal Rogers,
 according to the terms of the Apache license.
 
-This program uses "mkdirp",  Copyright (c) 2010 James Halliday,
+This program uses "mkdirp",  Copyright (c) James Halliday,
 according to the terms of the MIT/X11 license.
+
+This program uses "opener", Copyright (c) Domenic Denicola,
+according to the terms of the DWTFPL2 license.

deps/npm/Makefile

@@ -92,7 +92,7 @@ doc/cli/index.md: $(markdowns) scripts/index-build.js scripts/doc-build.sh packa
 	node scripts/index-build.js > $@
 
 node_modules/.bin/ronn:
-	node cli.js install
+	node cli.js install ronn
 
 doc: man
 
@@ -120,10 +120,10 @@ doc-publish: doc
 		html/api/ \
 		node@npmjs.org:/home/node/npm-www/api
 	rsync -vazu --stats --no-implied-dirs --delete \
-		html/webfonts/ \
+		html/static/webfonts/ \
 		node@npmjs.org:/home/node/npm-www/static/webfonts
 	rsync -vazu --stats --no-implied-dirs --delete \
-		html/style.css \
+		html/static/style.css \
 		node@npmjs.org:/home/node/npm-www/static/
 
 zip-publish: release

deps/npm/README.md

@@ -9,7 +9,7 @@ Much more info available via `npm help` once it's installed.
 
 ## IMPORTANT
 
-**You need node v0.6 or higher to run this program.**
+**You need node v0.8 or higher to run this program.**
 
 To install an old **and unsupported** version of npm that works on node 0.3
 and prior, clone the git repo and dig through the old tags and branches.
@@ -42,11 +42,11 @@ There's a pretty robust install script at
 
 You can set any npm configuration params with that script:
 
-npm_config_prefix=/some/path sh install.sh
+    npm_config_prefix=/some/path sh install.sh
 
 Or, you can run it in uber-debuggery mode:
 
-npm_debug=1 sh install.sh
+    npm_debug=1 sh install.sh
 
 ### Even Fancier
 
@@ -60,7 +60,7 @@ for testing, or running stuff without actually installing npm itself.)
 
 ## Fancy Windows Install
 
-You can download a zip file from <http://npmjs.org/dist/>, and unpack it
+You can download a zip file from <https://npmjs.org/dist/>, and unpack it
 in the same folder where node.exe lives.
 
 If that's not fancy enough for you, then you can fetch the code with
@@ -169,13 +169,13 @@ help config` to learn about all the options you can set there.
 
 ## More Docs
 
-Check out the [docs](http://npmjs.org/doc/),
-especially the [faq](http://npmjs.org/doc/faq.html).
+Check out the [docs](https://npmjs.org/doc/),
+especially the [faq](https://npmjs.org/doc/faq.html).
 
 You can use the `npm help` command to read any of them.
 
 If you're a developer, and you want to use npm to publish your program,
-you should [read this](http://npmjs.org/doc/developers.html)
+you should [read this](https://npmjs.org/doc/developers.html)
 
 ## Legal Stuff
 
@@ -221,7 +221,7 @@ If this concerns you, inspect the source before using packages.
 When you find issues, please report them:
 
 * web:
-  <http://github.com/isaacs/npm/issues>
+  <https://github.com/isaacs/npm/issues>
 * email:
   <npm-@googlegroups.com>
 

deps/npm/doc/api/deprecate.md

@@ -25,6 +25,8 @@ The 'args' parameter must have exactly two elements:
 Note that you must be the package owner to deprecate something.  See the
 `owner` and `adduser` help topics.
 
+To un-deprecate a package, specify an empty string (`""`) for the `message` argument.
+
 ## SEE ALSO
 
 * npm-publish(3)

deps/npm/doc/api/npm.md

@@ -4,7 +4,7 @@ npm(3) -- node package manager
 ## SYNOPSIS
 
     var npm = require("npm")
-    npm.load(configObject, function (er, npm) {
+    npm.load([configObject,] function (er, npm) {
       // use the npm object, now that it's loaded.
 
       npm.config.set(key, val)
@@ -25,12 +25,13 @@ This is the API documentation for npm.
 To find documentation of the command line
 client, see `npm(1)`.
 
-Prior to using npm's commands,
-`npm.load()` must be called with an object hash of
-top-level configs.  In the npm command line client,
-this set of configs is parsed from the command line options.  Additional
-configuration params are loaded from two configuration files.  See
-`npm-config(1)` for more information.
+Prior to using npm's commands, `npm.load()` must be called.
+If you provide `configObject` as an object hash of top-level
+configs, they override the values stored in the various config
+locations. In the npm command line client, this set of configs
+is parsed from the command line options. Additional configuration
+params are loaded from two configuration files. See `npm-config(1)`
+for more information.
 
 After that, each of the functions are accessible in the
 commands object: `npm.commands.<cmd>`.  See `npm-index(1)` for a list of

deps/npm/doc/cli/bugs.md

@@ -15,7 +15,7 @@ config param.
 
 ### browser
 
-* Default: OS X: `"open"`, others: `"google-chrome"`
+* Default: OS X: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
 * Type: String
 
 The browser that is called by the `npm bugs` command to open websites.

deps/npm/doc/cli/coding-style.md

@@ -10,6 +10,8 @@ designed to reduce visual clutter and make bugs more apparent.
 If you want to contribute to npm (which is very encouraged), you should
 make your code conform to npm's style.
 
+Note: this concerns npm's code not the specific packages at npmjs.org
+
 ## Line Length
 
 Keep lines shorter than 80 characters.  It's better for lines to be

deps/npm/doc/cli/config.md

@@ -36,11 +36,15 @@ work the same.
 `$HOME/.npmrc` (or the `userconfig` param, if set above)
 
 This file is an ini-file formatted list of `key = value` parameters.
+Environment variables can be replaced using `${VARIABLE_NAME}`. For example:
+
+    prefix = ${HOME}/.npm-packages
 
 ### Global config file
 
 `$PREFIX/etc/npmrc` (or the `globalconfig` param, if set above):
-This file is an ini-file formatted list of `key = value` parameters
+This file is an ini-file formatted list of `key = value` parameters.
+Environment variables can be replaced as above.
 
 ### Built-in config file
 
@@ -112,7 +116,6 @@ The following shorthands are parsed on the command-line:
 * `-reg`: `--registry`
 * `-v`: `--version`
 * `-f`: `--force`
-* `-l`: `--long`
 * `-desc`: `--description`
 * `-S`: `--save`
 * `-D`: `--save-dev`
@@ -168,9 +171,21 @@ then the user could change the behavior by doing:
 Force npm to always require authentication when accessing the registry,
 even for `GET` requests.
 
+### bin-links
+
+* Default: `true`
+* Type: Boolean
+
+Tells npm to create symlinks (or `.cmd` shims on Windows) for package
+executables.
+
+Set to false to have it not do this.  This can be used to work around
+the fact that some file systems don't support symlinks, even on
+ostensibly Unix systems.
+
 ### browser
 
-* Default: OS X: `"open"`, others: `"google-chrome"`
+* Default: OS X: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
 * Type: String
 
 The browser that is called by the `npm docs` command to open websites.
@@ -229,7 +244,7 @@ explicitly used, and that only GET requests use the cache.
 
 ### cache-min
 
-* Default: 0
+* Default: 10
 * Type: Number
 
 The minimum time (in seconds) to keep items in the registry cache before
@@ -358,10 +373,10 @@ Operates in "global" mode, so that packages are installed into the
 `prefix` folder instead of the current working directory.  See
 `npm-folders(1)` for more on the differences in behavior.
 
-* packages are installed into the `prefix/node_modules` folder, instead of the
+* packages are installed into the `{prefix}/lib/node_modules` folder, instead of the
   current working directory.
-* bin files are linked to `prefix/bin`
-* man pages are linked to `prefix/share/man`
+* bin files are linked to `{prefix}/bin`
+* man pages are linked to `{prefix}/share/man`
 
 ### globalconfig
 
@@ -399,7 +414,7 @@ A proxy to use for outgoing https requests.
 
 ### user-agent
 
-* Default: npm/{npm.version} node/{process.version}
+* Default: node/{process.version} {process.platform} {process.arch}
 * Type: String
 
 Sets a User-Agent to the request header
@@ -569,7 +584,7 @@ standard output.
 
 ### prefix
 
-* Default: node's process.installPrefix
+* Default: see npm-folders(1)
 * Type: path
 
 The location to install global items.  If set on the command line, then
@@ -706,6 +721,14 @@ character to indicate reverse sort.
 
 The shell to run for the `npm explore` command.
 
+### shrinkwrap
+
+* Default: true
+* Type: Boolean
+
+If set to false, then ignore `npm-shrinkwrap.json` files when
+installing.
+
 ### sign-git-tag
 
 * Default: false

deps/npm/doc/cli/deprecate.md

@@ -18,6 +18,8 @@ something like this:
 Note that you must be the package owner to deprecate something.  See the
 `owner` and `adduser` help topics.
 
+To un-deprecate a package, specify an empty string (`""`) for the `message` argument.
+
 ## SEE ALSO
 
 * npm-publish(1)

deps/npm/doc/cli/developers.md

@@ -97,10 +97,34 @@ more info.
 ## Keeping files *out* of your package
 
 Use a `.npmignore` file to keep stuff out of your package.  If there's
-no .npmignore file, but there *is* a .gitignore file, then npm will
-ignore the stuff matched by the .gitignore file.  If you *want* to
-include something that is excluded by your .gitignore file, you can
-create an empty .npmignore file to override it.
+no `.npmignore` file, but there *is* a `.gitignore` file, then npm will
+ignore the stuff matched by the `.gitignore` file.  If you *want* to
+include something that is excluded by your `.gitignore` file, you can
+create an empty `.npmignore` file to override it.
+
+By default, the following paths and files are ignored, so there's no
+need to add them to `.npmignore` explicitly:
+
+* `.*.swp`
+* `._*`
+* `.DS_Store`
+* `.git`
+* `.hg`
+* `.lock-wscript`
+* `.svn`
+* `.wafpickle-*`
+* `CVS`
+* `npm-debug.log`
+
+Additionally, everything in `node_modules` is ignored, except for
+bundled dependencies. npm automatically handles this for you, so don't
+bother adding `node_modules` to `.npmignore`.
+
+The following paths and files are never ignored, so adding them to
+`.npmignore` is pointless:
+
+* `package.json`
+* `README.*`
 
 ## Link Packages
 

deps/npm/doc/cli/disputes.md

@@ -4,8 +4,10 @@ npm-disputes(1) -- Handling Module Name Disputes
 ## SYNOPSIS
 
 1. Get the author email with `npm owner ls <pkgname>`
-1. Email the author, CC <i@izs.me>.
-2. After a few weeks, if there's no resolution, we'll sort it out.
+2. Email the author, CC <i@izs.me>.
+3. After a few weeks, if there's no resolution, we'll sort it out.
+
+Don't squat on package names.  Publish code or move out of the way.
 
 ## DESCRIPTION
 
@@ -13,9 +15,9 @@ There sometimes arise cases where a user publishes a module, and then
 later, some other user wants to use that name.  Here are some common
 ways that happens (each of these is based on actual events.)
 
-1. Bob writes a JavaScript module `foo`, which is not node-specific.
-   Bob doesn't use node at all.  Joe wants to use `foo` in node, so he
-   wraps it in an npm module.  Some time later, Bob starts using node,
+1. Joe writes a JavaScript module `foo`, which is not node-specific.
+   Joe doesn't use node at all.  Bob   wants to use `foo` in node, so he
+   wraps it in an npm module.  Some time later, Joe starts using node,
    and wants to take over management of his program.
 2. Bob writes an npm module `foo`, and publishes it.  Perhaps much
    later, Joe finds a bug in `foo`, and fixes it.  He sends a pull
@@ -40,14 +42,15 @@ Joe's appropriate course of action in each case is the same.
 
 1. `npm owner ls foo`.  This will tell Joe the email address of the
    owner (Bob).
-2. Joe emails Bob, explaining the situation **as respecfully as possible**,
+2. Joe emails Bob, explaining the situation **as respectfully as possible**,
    and what he would like to do with the module name.  He adds
    isaacs <i@izs.me> to the CC list of the email.  Mention in the email
    that Bob can run `npm owner add joe foo` to add Joe as an owner of
    the `foo` package.
 3. After a reasonable amount of time, if Bob has not responded, or if
    Bob and Joe can't come to any sort of resolution, email isaacs
-   <i@izs.me> and we'll sort it out.
+   <i@izs.me> and we'll sort it out.  ("Reasonable" is usually about 4
+   weeks, but extra time is allowed around common holidays.)
 
 ## REASONING
 
@@ -69,12 +72,23 @@ Some things are not allowed, and will be removed without discussion if
 they are brought to the attention of the npm registry admins, including
 but not limited to:
 
-1. Malware (that is, a module designed to exploit or harm the machine on
-   which it is installed)
+1. Malware (that is, a package designed to exploit or harm the machine on
+   which it is installed).
 2. Violations of copyright or licenses (for example, cloning an
    MIT-licensed program, and then removing or changing the copyright and
-   license statement)
+   license statement).
 3. Illegal content.
+4. "Squatting" on a package name that you *plan* to use, but aren't
+   actually using.  Sorry, I don't care how great the name is, or how
+   perfect a fit it is for the thing that someday might happen.  If
+   someone wants to use it today, and you're just taking up space with
+   an empty tarball, you're going to be evicted.
+5. Putting empty packages in the registry.  Packages must have SOME
+   functionality.  It can be silly, but it can't be *nothing*.  (See
+   also: squatting.)
+6. Doing weird things with the registry, like using it as your own
+   personal application database or otherwise putting non-packagey
+   things into it.
 
 If you see bad behavior like this, please report it right away.
 

deps/npm/doc/cli/docs.md

@@ -16,7 +16,7 @@ config param.
 
 ### browser
 
-* Default: OS X: `"open"`, others: `"google-chrome"`
+* Default: OS X: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
 * Type: String
 
 The browser that is called by the `npm docs` command to open websites.

deps/npm/doc/cli/faq.md

@@ -3,7 +3,7 @@ npm-faq(1) -- Frequently Asked Questions
 
 ## Where can I find these docs in HTML?
 
-<http://npmjs.org/doc/>, or run:
+<https://npmjs.org/doc/>, or run:
 
     npm config set viewer browser
 
@@ -72,6 +72,52 @@ Write your own package manager, then.  It's not that hard.
 
 npm will not help you do something that is known to be a bad idea.
 
+## `"node_modules"` is the name of my deity's arch-rival, and a Forbidden Word in my religion.  Can I configure npm to use a different folder?
+
+No.  This will never happen.  This question comes up sometimes,
+because it seems silly from the outside that npm couldn't just be
+configured to put stuff somewhere else, and then npm could load them
+from there.  It's an arbitrary spelling choice, right?  What's the big
+deal?
+
+At the time of this writing, the string `'node_modules'` appears 151
+times in 53 separate files in npm and node core (excluding tests and
+documentation).
+
+Some of these references are in node's built-in module loader.  Since
+npm is not involved **at all** at run-time, node itself would have to
+be configured to know where you've decided to stick stuff.  Complexity
+hurdle #1.  Since the Node module system is locked, this cannot be
+changed, and is enough to kill this request.  But I'll continue, in
+deference to your deity's delicate feelings regarding spelling.
+
+Many of the others are in dependencies that npm uses, which are not
+necessarily tightly coupled to npm (in the sense that they do not read
+npm's configuration files, etc.)  Each of these would have to be
+configured to take the name of the `node_modules` folder as a
+parameter.  Complexity hurdle #2.
+
+Furthermore, npm has the ability to "bundle" dependencies by adding
+the dep names to the `"bundledDependencies"` list in package.json,
+which causes the folder to be included in the package tarball.  What
+if the author of a module bundles its dependencies, and they use a
+different spelling for `node_modules`?  npm would have to rename the
+folder at publish time, and then be smart enough to unpack it using
+your locally configured name.  Complexity hurdle #3.
+
+Furthermore, what happens when you *change* this name?  Fine, it's
+easy enough the first time, just rename the `node_modules` folders to
+`./blergyblerp/` or whatever name you choose.  But what about when you
+change it again?  npm doesn't currently track any state about past
+configuration settings, so this would be rather difficult to do
+properly.  It would have to track every previous value for this
+config, and always accept any of them, or else yesterday's install may
+be broken tomorrow.  Complexity hurdle #5.
+
+Never going to happen.  The folder is named `node_modules`.  It is
+written indelibly in the Node Way, handed down from the ancient times
+of Node 0.3.
+
 ## Should I check my `node_modules` folder into git?
 
 Mikeal Rogers answered this question very well:
@@ -144,7 +190,7 @@ command.)
 
 In those cases, you can do this:
 
-    curl http://npmjs.org/install.sh | sh
+    curl https://npmjs.org/install.sh | sh
 
 ## What is a `package`?
 
@@ -175,12 +221,19 @@ an argument to `git checkout`.  The default is `master`.
 
 ## How do I install node with npm?
 
-You don't.  Try one of these:
+You don't.  Try one of these node version managers:
+
+Unix:
 
 * <http://github.com/isaacs/nave>
 * <http://github.com/visionmedia/n>
 * <http://github.com/creationix/nvm>
 
+Windows:
+
+* <http://github.com/marcelklehr/nodist>
+* <https://github.com/hakobera/nvmw>
+
 ## How can I use npm for development?
 
 See `npm-developers(1)` and `npm-json(1)`.
@@ -245,7 +298,7 @@ There is not sufficient need to impose namespace rules on everyone.
 Discuss it on the mailing list, or post an issue.
 
 * <npm-@googlegroups.com>
-* <http://github.com/isaacs/npm/issues>
+* <https://github.com/isaacs/npm/issues>
 
 ## Why does npm hate me?
 

deps/npm/doc/cli/folders.md

@@ -157,21 +157,21 @@ In this case, we might expect a folder structure like this:
     +-- 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)
+        |   `-- 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
+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,
+parent installation of blerg satisfies 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
@@ -179,11 +179,11 @@ 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
+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
+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`.

deps/npm/doc/cli/global.md

@@ -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)

deps/npm/doc/cli/index.md

@@ -82,6 +82,10 @@ npm-index(1) -- Index of all npm documentation
 
  Folder Structures Used by npm
 
+## npm-global(1)
+
+ Folder Structures Used by npm
+
 ## npm-help-search(1)
 
  Search npm help documentation
@@ -154,6 +158,10 @@ npm-index(1) -- Index of all npm documentation
 
  Start a package
 
+## npm-rm(1)
+
+ Remove a package
+
 ## npm-root(1)
 
  Display npm root
@@ -182,6 +190,10 @@ npm-index(1) -- Index of all npm documentation
 
  Mark your favorite packages
 
+## npm-stars(1)
+
+ View packages marked as favorites
+
 ## npm-start(1)
 
  Start a package

deps/npm/doc/cli/install.md

@@ -165,6 +165,15 @@ rather than locally.  See `npm-folders(1)`.
 The `--link` argument will cause npm to link global installs into the
 local space in some cases.
 
+The `--no-bin-links` argument will prevent npm from creating symlinks for
+any binaries the package might contain.
+
+The `--no-shrinkwrap` argument, which will ignore an available
+shrinkwrap file and use the package.json instead.
+
+The `--nodedir=/path/to/node/source` argument will allow npm to find the
+node source code so that npm can compile native modules.
+
 See `npm-config(1)`.  Many of the configuration params have some
 effect on installation, since that's most of what npm does.
 

deps/npm/doc/cli/json.md

@@ -118,6 +118,27 @@ you can specify the value for "bugs" as a simple string instead of an object.
 
 If a url is provided, it will be used by the `npm bugs` command.
 
+## license
+
+You should specify a license for your package so that people know how they are
+permitted to use it, and any restrictions you're placing on it.
+
+The simplest way, assuming you're using a common license such as BSD or MIT, is
+to just specify the name of the license you're using, like this:
+
+    { "license" : "BSD" }
+
+If you have more complex licensing terms, or you want to provide more detail
+in your package.json file, you can use the more verbose plural form, like this:
+
+    "licenses" : [
+      { "type" : "MyLicense"
+      , "url" : "http://github.com/owner/project/path/to/license"
+      }
+    ]
+
+It's also a good idea to include a license file at the top level in your package.
+
 ## people fields: author, contributors
 
 The "author" is one person.  "contributors" is an array of people.  A "person"
@@ -366,8 +387,8 @@ a version in the following fashion.
 For example, the following are equivalent:
 
 * `"~1.2.3" = ">=1.2.3 <1.3.0"`
-* `"~1.2" = ">=1.2.0 <2.0.0"`
-* `"~1" = ">=1.0.0 <2.0.0"`
+* `"~1.2" = ">=1.2.0 <1.3.0"`
+* `"~1" = ">=1.0.0 <1.1.0"`
 
 ### X Version Ranges
 
@@ -416,9 +437,9 @@ In this case, it's best to list these additional items in a
 `devDependencies` hash.
 
 These things will be installed whenever the `--dev` configuration flag
-is set.  This flag is set automatically when doing `npm link`, and can
-be managed like any other npm configuration param.  See `npm-config(1)`
-for more on the topic.
+is set.  This flag is set automatically when doing `npm link` or when doing
+`npm install` from the root of a package, and can be managed like any other npm
+configuration param.  See `npm-config(1)` for more on the topic.
 
 ## bundledDependencies
 

deps/npm/doc/cli/link.md

@@ -16,6 +16,9 @@ symbolic link from `prefix/package-name` to the current folder.
 Next, in some other location, `npm link package-name` will create a
 symlink from the local `node_modules` folder to the global symlink.
 
+Note that `package-name` is taken from `package.json` ,
+not from directory name.
+
 When creating tarballs for `npm publish`, the linked packages are
 "snapshotted" to their current state by resolving the symbolic links.
 

deps/npm/doc/cli/registry.md

@@ -82,9 +82,7 @@ ask for help on the <npm-@googlegroups.com> mailing list.
 
 ## Is there a website or something to see package docs and such?
 
-No, but such a thing is planned, and a tiny bit developed.
-
-Stay tuned!
+Yes, head over to <https://npmjs.org/>
 
 ## SEE ALSO
 

deps/npm/doc/cli/rm.md

@@ -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)

deps/npm/doc/cli/scripts.md

@@ -6,6 +6,11 @@ npm-scripts(1) -- How npm handles the "scripts" field
 npm supports the "scripts" member of the package.json script, for the
 following scripts:
 
+* prepublish:
+  Run BEFORE the package is published.  (Also run on local `npm
+  install` without any arguments.)
+* publish, postpublish:
+  Run AFTER the package is published.
 * preinstall:
   Run BEFORE the package is installed
 * install, postinstall:
@@ -18,10 +23,6 @@ following scripts:
   Run BEFORE the package is updated with the update command.
 * update, postupdate:
   Run AFTER the package is updated with the update command.
-* prepublish:
-  Run BEFORE the package is published.
-* publish, postpublish:
-  Run AFTER the package is published.
 * pretest, test, posttest:
   Run by the `npm test` command.
 * prestop, stop, poststop:
@@ -35,6 +36,50 @@ following scripts:
 Additionally, arbitrary scrips can be run by doing
 `npm run-script <stage> <pkg>`.
 
+## NOTE: INSTALL SCRIPTS ARE AN ANTIPATTERN
+
+**tl;dr** Don't use `install`.  Use a `.gyp` file for compilation, and
+`prepublish` for anything else.
+
+You should almost never have to explicitly set a `preinstall` or
+`install` script.  If you are doing this, please consider if there is
+another option.
+
+The only valid use of `install` or `preinstall` scripts is for
+compilation which must be done on the target architecture.  In early
+versions of node, this was often done using the `node-waf` scripts, or
+a standalone `Makefile`, and early versions of npm required that it be
+explicitly set in package.json.  This was not portable, and harder to
+do properly.
+
+In the current version of node, the standard way to do this is using a
+`.gyp` file.  If you have a file with a `.gyp` extension in the root
+of your package, then npm will run the appropriate `node-gyp` commands
+automatically at install time.  This is the only officially supported
+method for compiling binary addons, and does not require that you add
+anything to your package.json file.
+
+If you have to do other things before your package is used, in a way
+that is not dependent on the operating system or architecture of the
+target system, then use a `prepublish` script instead.  This includes
+tasks such as:
+
+* Compile CoffeeScript source code into JavaScript.
+* Create minified versions of JavaScript source code.
+* Fetching remote resources that your package will use.
+
+The advantage of doing these things at `prepublish` time instead of
+`preinstall` or `install` time is that they can be done once, in a
+single place, and thus greatly reduce complexity and variability.
+Additionally, this means that:
+
+* You can depend on `coffee-script` as a `devDependency`, and thus
+  your users don't need to have it installed.
+* You don't need to include the minifiers in your package, reducing
+  the size for your users.
+* You don't need to rely on your users having `curl` or `wget` or
+  other system tools on the target machines.
+
 ## DEFAULT VALUES
 
 npm will default some script values based on package contents.

deps/npm/doc/cli/semver.md

@@ -11,8 +11,8 @@ As a node module:
 
     $ npm install semver
 
-    semver.valid('1.2.3') // true
-    semver.valid('a.b.c') // false
+    semver.valid('1.2.3') // '1.2.3'
+    semver.valid('a.b.c') // null
     semver.clean('  =v1.2.3   ') // '1.2.3'
     semver.satisfies('1.2.3', '1.x || >=2.5.0 || 5.0.0 - 7.2.3') // true
     semver.gt('1.2.3', '9.8.7') // false
@@ -83,7 +83,7 @@ The following range styles are supported:
 * `<1.2.3` Less than
 * `1.2.3 - 2.3.4` := `>=1.2.3 <=2.3.4`
 * `~1.2.3` := `>=1.2.3 <1.3.0`
-* `~1.2` := `>=1.2.0 <2.0.0`
+* `~1.2` := `>=1.2.0 <1.3.0`
 * `~1` := `>=1.0.0 <2.0.0`
 * `1.2.x` := `>=1.2.0 <1.3.0`
 * `1.x` := `>=1.0.0 <2.0.0`

deps/npm/doc/cli/shrinkwrap.md

@@ -7,68 +7,72 @@ npm-shrinkwrap(1) -- Lock down dependency versions
 
 ## DESCRIPTION
 
-This command locks down the versions of a package's dependencies so that you can
-control exactly which versions of each dependency will be used when your package
-is installed.
+This command locks down the versions of a package's dependencies so
+that you can control exactly which versions of each dependency will be
+used when your package is installed. The "package.json" file is still
+required if you want to use "npm install".
 
-By default, "npm install" recursively installs the target's dependencies (as
-specified in package.json), choosing the latest available version that satisfies
-the dependency's semver pattern. In some situations, particularly when shipping
-software where each change is tightly managed, it's desirable to fully specify
-each version of each dependency recursively so that subsequent builds and
-deploys do not inadvertently pick up newer versions of a dependency that satisfy
-the semver pattern. Specifying specific semver patterns in each dependency's
-package.json would facilitate this, but that's not always possible or desirable,
-as when another author owns the npm package. It's also possible to check
-dependencies directly into source control, but that may be undesirable for other
-reasons.
+By default, "npm install" recursively installs the target's
+dependencies (as specified in package.json), choosing the latest
+available version that satisfies the dependency's semver pattern. In
+some situations, particularly when shipping software where each change
+is tightly managed, it's desirable to fully specify each version of
+each dependency recursively so that subsequent builds and deploys do
+not inadvertently pick up newer versions of a dependency that satisfy
+the semver pattern. Specifying specific semver patterns in each
+dependency's package.json would facilitate this, but that's not always
+possible or desirable, as when another author owns the npm package.
+It's also possible to check dependencies directly into source control,
+but that may be undesirable for other reasons.
 
 As an example, consider package A:
 
     {
-        "name": "A",
-        "version": "0.1.0",
-        "dependencies": {
-            "B": "<0.1.0"
-        }
+      "name": "A",
+      "version": "0.1.0",
+      "dependencies": {
+        "B": "<0.1.0"
+      }
     }
 
 package B:
 
     {
-        "name": "B",
-        "version": "0.0.1",
-        "dependencies": {
-            "C": "<0.1.0"
-        }
+      "name": "B",
+      "version": "0.0.1",
+      "dependencies": {
+        "C": "<0.1.0"
+      }
     }
 
 and package C:
 
     {
-        "name": "C,
-        "version": "0.0.1"
+      "name": "C,
+      "version": "0.0.1"
     }
 
-If these are the only versions of A, B, and C available in the registry, then
-a normal "npm install A" will install:
+If these are the only versions of A, B, and C available in the
+registry, then a normal "npm install A" will install:
 
     A@0.1.0
     `-- B@0.0.1
         `-- C@0.0.1
 
-However, if B@0.0.2 is published, then a fresh "npm install A" will install:
+However, if B@0.0.2 is published, then a fresh "npm install A" will
+install:
 
     A@0.1.0
     `-- B@0.0.2
         `-- C@0.0.1
 
-assuming the new version did not modify B's dependencies. Of course, the new
-version of B could include a new version of C and any number of new
-dependencies. If such changes are undesirable, the author of A could specify a
-dependency on B@0.0.1. However, if A's author and B's author are not the same
-person, there's no way for A's author to say that he or she does not want to
-pull in newly published versions of C when B hasn't changed at all.
+assuming the new version did not modify B's dependencies. Of course,
+the new version of B could include a new version of C and any number
+of new dependencies. If such changes are undesirable, the author of A
+could specify a dependency on B@0.0.1. However, if A's author and B's
+author are not the same person, there's no way for A's author to say
+that he or she does not want to pull in newly published versions of C
+when B hasn't changed at all.
 
 In this case, A's author can run
 
@@ -91,78 +95,88 @@ This generates npm-shrinkwrap.json, which will look something like this:
       }
     }
 
-The shrinkwrap command has locked down the dependencies based on what's
-currently installed in node_modules.  When "npm install" installs a package with
-a npm-shrinkwrap.json file in the package root, the shrinkwrap file (rather than
-package.json files) completely drives the installation of that package and all
-of its dependencies (recursively).  So now the author publishes A@0.1.0, and
-subsequent installs of this package will use B@0.0.1 and C@0.1.0, regardless the
-dependencies and versions listed in A's, B's, and C's package.json files.
+The shrinkwrap command has locked down the dependencies based on
+what's currently installed in node_modules.  When "npm install"
+installs a package with a npm-shrinkwrap.json file in the package
+root, the shrinkwrap file (rather than package.json files) completely
+drives the installation of that package and all of its dependencies
+(recursively).  So now the author publishes A@0.1.0, and subsequent
+installs of this package will use B@0.0.1 and C@0.1.0, regardless the
+dependencies and versions listed in A's, B's, and C's package.json
+files.
 
 
 ### Using shrinkwrapped packages
 
-Using a shrinkwrapped package is no different than using any other package: you
-can "npm install" it by hand, or add a dependency to your package.json file and
-"npm install" it.
+Using a shrinkwrapped package is no different than using any other
+package: you can "npm install" it by hand, or add a dependency to your
+package.json file and "npm install" it.
 
 ### Building shrinkwrapped packages
 
 To shrinkwrap an existing package:
 
-1. Run "npm install" in the package root to install the current versions of all
-   dependencies.
+1. Run "npm install" in the package root to install the current
+   versions of all dependencies.
 2. Validate that the package works as expected with these versions.
-3. Run "npm shrinkwrap", add npm-shrinkwrap.json to git, and publish your
-   package.
+3. Run "npm shrinkwrap", add npm-shrinkwrap.json to git, and publish
+   your package.
 
 To add or update a dependency in a shrinkwrapped package:
 
-1. Run "npm install" in the package root to install the current versions of all
+1. Run "npm install" in the package root to install the current
+   versions of all dependencies.
+2. Add or update dependencies. "npm install" each new or updated
+   package individually and then update package.json.  Note that they
+   must be explicitly named in order to be installed: running `npm
+   install` with no arguments will merely reproduce the existing
+   shrinkwrap.
+3. Validate that the package works as expected with the new
    dependencies.
-2. Add or update dependencies. "npm install" each new or updated package
-   individually and then update package.json.  Note that they must be
-   explicitly named in order to be installed: running `npm install` with
-   no arguments will merely reproduce the existing shrinkwrap.
-3. Validate that the package works as expected with the new dependencies.
-4. Run "npm shrinkwrap", commit the new npm-shrinkwrap.json, and publish your
-   package.
+4. Run "npm shrinkwrap", commit the new npm-shrinkwrap.json, and
+   publish your package.
 
-You can use npm-outdated(1) to view dependencies with newer versions available.
+You can use npm-outdated(1) to view dependencies with newer versions
+available.
 
 ### Other Notes
 
-Since "npm shrinkwrap" uses the locally installed packages to construct the
-shrinkwrap file, devDependencies will be included if and only if you've
-installed them already when you make the shrinkwrap.
+A shrinkwrap file must be consistent with the package's package.json
+file. "npm shrinkwrap" will fail if required dependencies are not
+already installed, since that would result in a shrinkwrap that
+wouldn't actually work. Similarly, the command will fail if there are
+extraneous packages (not referenced by package.json), since that would
+indicate that package.json is not correct.
 
-A shrinkwrap file must be consistent with the package's package.json file. "npm
-shrinkwrap" will fail if required dependencies are not already installed, since
-that would result in a shrinkwrap that wouldn't actually work. Similarly, the
-command will fail if there are extraneous packages (not referenced by
-package.json), since that would indicate that package.json is not correct.
+Since "npm shrinkwrap" is intended to lock down your dependencies for
+production use, `devDependencies` will not be included unless you
+explicitly set the `--dev` flag when you run `npm shrinkwrap`.  If
+installed `devDependencies` are excluded, then npm will print a
+warning.  If you want them to be installed with your module by
+default, please consider adding them to `dependencies` instead.
 
-If shrinkwrapped package A depends on shrinkwrapped package B, B's shrinkwrap
-will not be used as part of the installation of A. However, because A's
-shrinkwrap is constructed from a valid installation of B and recursively
-specifies all dependencies, the contents of B's shrinkwrap will implicitly be
-included in A's shrinkwrap.
+If shrinkwrapped package A depends on shrinkwrapped package B, B's
+shrinkwrap will not be used as part of the installation of A. However,
+because A's shrinkwrap is constructed from a valid installation of B
+and recursively specifies all dependencies, the contents of B's
+shrinkwrap will implicitly be included in A's shrinkwrap.
 
 ### Caveats
 
-Shrinkwrap files only lock down package versions, not actual package contents.
-While discouraged, a package author can republish an existing version of a
-package, causing shrinkwrapped packages using that version to pick up different
-code than they were before. If you want to avoid any risk that a byzantine
-author replaces a package you're using with code that breaks your application,
-you could modify the shrinkwrap file to use git URL references rather than
-version numbers so that npm always fetches all packages from git.
+Shrinkwrap files only lock down package versions, not actual package
+contents.  While discouraged, a package author can republish an
+existing version of a package, causing shrinkwrapped packages using
+that version to pick up different code than they were before. If you
+want to avoid any risk that a byzantine author replaces a package
+you're using with code that breaks your application, you could modify
+the shrinkwrap file to use git URL references rather than version
+numbers so that npm always fetches all packages from git.
 
 If you wish to lock down the specific bytes included in a package, for
-example to have 100% confidence in being able to reproduce a deployment
-or build, then you ought to check your dependencies into source control,
-or pursue some other mechanism that can verify contents rather than
-versions.
+example to have 100% confidence in being able to reproduce a
+deployment or build, then you ought to check your dependencies into
+source control, or pursue some other mechanism that can verify
+contents rather than versions.
 
 ## SEE ALSO
 

deps/npm/doc/cli/stars.md

@@ -0,0 +1,22 @@
+npm-stars(1) -- View packages marked as favorites
+=================================================
+
+## SYNOPSIS
+
+    npm stars
+    npm stars [username]
+
+## DESCRIPTION
+
+If you have starred a lot of neat things and want to find them again
+quickly this command lets you do just that.
+
+You may also want to see your friend's favorite packages, in this case
+you will most certainly enjoy this command.
+
+## SEE ALSO
+
+* npm-star(1)
+* npm-view(1)
+* npm-whoami(1)
+* npm-adduser(1)

deps/npm/doc/cli/update.md

@@ -3,7 +3,7 @@ npm-update(1) -- Update a package
 
 ## SYNOPSIS
 
-    npm update [<name> [<name> ...]]
+    npm update [-g] [<name> [<name> ...]]
 
 ## DESCRIPTION
 
@@ -12,6 +12,9 @@ This command will update all the packages listed to the latest version
 
 It will also install missing packages.
 
+If the `-g` flag is specified, this command will update globally installed packages.
+If no package name is specified, all packages in the specified location (global or local) will be updated.
+
 ## SEE ALSO
 
 * npm-install(1)

deps/npm/doc/cli/version.md

@@ -27,7 +27,16 @@ resulting version number.  For example:
 
 If the `sign-git-tag` config is set, then the tag will be signed using
 the `-s` flag to git.  Note that you must have a default GPG key set up
-in your git config for this to work properly.
+in your git config for this to work properly.  For example:
+
+    $ npm config set sign-git-tag true
+    $ npm version patch
+
+    You need a passphrase to unlock the secret key for
+    user: "isaacs (http://blog.izs.me/) <i@izs.me>"
+    2048-bit RSA key, ID 6C481CF6, created 2010-08-31
+
+    Enter passphrase:
 
 ## SEE ALSO
 

deps/npm/doc/cli/view.md

@@ -69,7 +69,9 @@ was required by each matching version of yui3:
 
 If only a single string field for a single version is output, then it
 will not be colorized or quoted, so as to enable piping the output to
-another command.
+another command. If the field is an object, it will be output as a JavaScript object literal.
+
+If the --json flag is given, the outputted fields will be JSON.
 
 If the version range matches multiple versions, than each printed value
 will be prefixed with the version it applies to.

deps/npm/html/api/bin.html

@@ -19,7 +19,7 @@
 <p>This function should not be used programmatically.  Instead, just refer
 to the <code>npm.bin</code> member.</p>
 </div>
-<p id="footer">bin &mdash; npm@1.1.61</p>
+<p id="footer">bin &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/bugs.html

@@ -25,7 +25,7 @@ optional version number.</p>
 <p>This command will launch a browser, so this command may not be the most
 friendly for programmatic use.</p>
 </div>
-<p id="footer">bugs &mdash; npm@1.1.61</p>
+<p id="footer">bugs &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/commands.html

@@ -28,7 +28,7 @@ usage, or <code>man 3 npm-&lt;command&gt;</code> for programmatic usage.</p>
 
 <ul><li><a href="../doc/index.html">index(1)</a></li></ul>
 </div>
-<p id="footer">commands &mdash; npm@1.1.61</p>
+<p id="footer">commands &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/config.html

@@ -33,7 +33,7 @@ functions instead.</p>
 
 <ul><li><a href="../api/npm.html">npm(3)</a></li></ul>
 </div>
-<p id="footer">config &mdash; npm@1.1.61</p>
+<p id="footer">config &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/deprecate.html

@@ -26,11 +26,13 @@ install the package.</p></li></ul>
 <p>Note that you must be the package owner to deprecate something.  See the
 <code>owner</code> and <code>adduser</code> help topics.</p>
 
+<p>To un-deprecate a package, specify an empty string (<code>&quot;&quot;</code>) for the <code>message</code> argument.</p>
+
 <h2 id="SEE-ALSO">SEE ALSO</h2>
 
 <ul><li><a href="../api/publish.html">publish(3)</a></li><li><a href="../api/unpublish.html">unpublish(3)</a></li><li><a href="../doc/registry.html">registry(1)</a></li></ul>
 </div>
-<p id="footer">deprecate &mdash; npm@1.1.61</p>
+<p id="footer">deprecate &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/docs.html

@@ -25,7 +25,7 @@ optional version number.</p>
 <p>This command will launch a browser, so this command may not be the most
 friendly for programmatic use.</p>
 </div>
-<p id="footer">docs &mdash; npm@1.1.61</p>
+<p id="footer">docs &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/edit.html

@@ -30,7 +30,7 @@ to open. The package can optionally have a version number attached.</p>
 <p>Since this command opens an editor in a new process, be careful about where
 and how this is used.</p>
 </div>
-<p id="footer">edit &mdash; npm@1.1.61</p>
+<p id="footer">edit &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/explore.html

@@ -24,7 +24,7 @@ sure to use <code>npm rebuild &lt;pkg&gt;</code> if you make any changes.</p>
 
 <p>The first element in the &#39;args&#39; parameter must be a package name.  After that is the optional command, which can be any number of strings. All of the strings will be combined into one, space-delimited command.</p>
 </div>
-<p id="footer">explore &mdash; npm@1.1.61</p>
+<p id="footer">explore &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/help-search.html

@@ -32,7 +32,7 @@ Name of the file that matched</li></ul>
 
 <p>The silent parameter is not neccessary not used, but it may in the future.</p>
 </div>
-<p id="footer">help-search &mdash; npm@1.1.61</p>
+<p id="footer">help-search &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/init.html

@@ -35,7 +35,7 @@ then go ahead and use this programmatically.</p>
 
 <p><a href="../doc/json.html">json(1)</a></p>
 </div>
-<p id="footer">init &mdash; npm@1.1.61</p>
+<p id="footer">init &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/install.html

@@ -25,7 +25,7 @@ the name of a package to be installed.</p>
 <p>Finally, &#39;callback&#39; is a function that will be called when all packages have been
 installed or when an error has been encountered.</p>
 </div>
-<p id="footer">install &mdash; npm@1.1.61</p>
+<p id="footer">install &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/link.html

@@ -39,7 +39,7 @@ npm.commands.link(&#39;redis&#39;, cb)  # link-install the package</code></pre>
 <p>Now, any changes to the redis package will be reflected in
 the package in the current working directory</p>
 </div>
-<p id="footer">link &mdash; npm@1.1.61</p>
+<p id="footer">link &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/load.html

@@ -32,7 +32,7 @@ config object.</p>
 
 <p>For a list of all the available command-line configs, see <code>npm help config</code></p>
 </div>
-<p id="footer">load &mdash; npm@1.1.61</p>
+<p id="footer">load &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/ls.html

@@ -59,7 +59,7 @@ project.</p>
 This means that if a submodule a same dependency as a parent module, then the
 dependency will only be output once.</p>
 </div>
-<p id="footer">ls &mdash; npm@1.1.61</p>
+<p id="footer">ls &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/npm.html

@@ -11,7 +11,7 @@
 <h2 id="SYNOPSIS">SYNOPSIS</h2>
 
 <pre><code>var npm = require(&quot;npm&quot;)
-npm.load(configObject, function (er, npm) {
+npm.load([configObject,] function (er, npm) {
   // use the npm object, now that it&#39;s loaded.
 
   npm.config.set(key, val)
@@ -24,7 +24,7 @@ npm.load(configObject, function (er, npm) {
 
 <h2 id="VERSION">VERSION</h2>
 
-<p>1.1.61</p>
+<p>1.2.30</p>
 
 <h2 id="DESCRIPTION">DESCRIPTION</h2>
 
@@ -32,12 +32,13 @@ npm.load(configObject, function (er, npm) {
 To find documentation of the command line
 client, see <code><a href="../doc/npm.html">npm(1)</a></code>.</p>
 
-<p>Prior to using npm&#39;s commands,
-<code>npm.load()</code> must be called with an object hash of
-top-level configs.  In the npm command line client,
-this set of configs is parsed from the command line options.  Additional
-configuration params are loaded from two configuration files.  See
-<code><a href="../doc/config.html">config(1)</a></code> for more information.</p>
+<p>Prior to using npm&#39;s commands, <code>npm.load()</code> must be called.
+If you provide <code>configObject</code> as an object hash of top-level
+configs, they override the values stored in the various config
+locations. In the npm command line client, this set of configs
+is parsed from the command line options. Additional configuration
+params are loaded from two configuration files. See <code><a href="../doc/config.html">config(1)</a></code>
+for more information.</p>
 
 <p>After that, each of the functions are accessible in the
 commands object: <code>npm.commands.&lt;cmd&gt;</code>.  See <code><a href="../doc/index.html">index(1)</a></code> for a list of
@@ -91,7 +92,7 @@ method names.  Use the <code>npm.deref</code> method to find the real name.</p>
 
 <pre><code>var cmd = npm.deref(&quot;unp&quot;) // cmd === &quot;unpublish&quot;</code></pre>
 </div>
-<p id="footer">npm &mdash; npm@1.1.61</p>
+<p id="footer">npm &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/outdated.html

@@ -19,7 +19,7 @@ currently outdated.</p>
 
 <p>If the &#39;packages&#39; parameter is left out, npm will check all packages.</p>
 </div>
-<p id="footer">outdated &mdash; npm@1.1.61</p>
+<p id="footer">outdated &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/owner.html

@@ -34,7 +34,7 @@ that is not implemented at this time.</p>
 
 <ul><li><a href="../api/publish.html">publish(3)</a></li><li><a href="../doc/registry.html">registry(1)</a></li></ul>
 </div>
-<p id="footer">owner &mdash; npm@1.1.61</p>
+<p id="footer">owner &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/pack.html

@@ -25,7 +25,7 @@ overwritten the second time.</p>
 
 <p>If no arguments are supplied, then npm packs the current package folder.</p>
 </div>
-<p id="footer">pack &mdash; npm@1.1.61</p>
+<p id="footer">pack &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/prefix.html

@@ -21,7 +21,7 @@
 
 <p>This function is not useful programmatically</p>
 </div>
-<p id="footer">prefix &mdash; npm@1.1.61</p>
+<p id="footer">prefix &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/prune.html

@@ -23,7 +23,7 @@
 <p>Extraneous packages are packages that are not listed on the parent
 package&#39;s dependencies list.</p>
 </div>
-<p id="footer">prune &mdash; npm@1.1.61</p>
+<p id="footer">prune &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/publish.html

@@ -32,7 +32,7 @@ the registry.  Overwrites when the "force" environment variable is set
 
 <ul><li><a href="../doc/registry.html">registry(1)</a></li><li><a href="../doc/adduser.html">adduser(1)</a></li><li><a href="../api/owner.html">owner(3)</a></li></ul>
 </div>
-<p id="footer">publish &mdash; npm@1.1.61</p>
+<p id="footer">publish &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/rebuild.html

@@ -22,7 +22,7 @@ the new binary. If no 'packages' parameter is specify, every package wil
 
 <p>See <code>npm help build</code></p>
 </div>
-<p id="footer">rebuild &mdash; npm@1.1.61</p>
+<p id="footer">rebuild &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/restart.html

@@ -27,7 +27,7 @@ in the <code>packages</code> parameter.</p>
 
 <ul><li><a href="../api/start.html">start(3)</a></li><li><a href="../api/stop.html">stop(3)</a></li></ul>
 </div>
-<p id="footer">restart &mdash; npm@1.1.61</p>
+<p id="footer">restart &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/root.html

@@ -21,7 +21,7 @@
 
 <p>This function is not useful programmatically.</p>
 </div>
-<p id="footer">root &mdash; npm@1.1.61</p>
+<p id="footer">root &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/run-script.html

@@ -29,7 +29,7 @@ assumed to be the command to run. All other elements are ignored.</p>
 
 <ul><li><a href="../doc/scripts.html">scripts(1)</a></li><li><a href="../api/test.html">test(3)</a></li><li><a href="../api/start.html">start(3)</a></li><li><a href="../api/restart.html">restart(3)</a></li><li><a href="../api/stop.html">stop(3)</a></li></ul>
 </div>
-<p id="footer">run-script &mdash; npm@1.1.61</p>
+<p id="footer">run-script &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/search.html

@@ -32,7 +32,7 @@ excluded term (the "searchexclude" config). The search is case insensi
 and doesn't try to read your mind (it doesn't do any verb tense matching or the
 like).</p>
 </div>
-<p id="footer">search &mdash; npm@1.1.61</p>
+<p id="footer">search &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/shrinkwrap.html

@@ -26,7 +26,7 @@ but the shrinkwrap file will still be written.</p>
 <p>Finally, &#39;callback&#39; is a function that will be called when the shrinkwrap has
 been saved.</p>
 </div>
-<p id="footer">shrinkwrap &mdash; npm@1.1.61</p>
+<p id="footer">shrinkwrap &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/start.html

@@ -19,7 +19,7 @@
 <p>npm can run tests on multiple packages. Just specify multiple packages
 in the <code>packages</code> parameter.</p>
 </div>
-<p id="footer">start &mdash; npm@1.1.61</p>
+<p id="footer">start &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/stop.html

@@ -19,7 +19,7 @@
 <p>npm can run stop on multiple packages. Just specify multiple packages
 in the <code>packages</code> parameter.</p>
 </div>
-<p id="footer">stop &mdash; npm@1.1.61</p>
+<p id="footer">stop &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/submodule.html

@@ -33,7 +33,7 @@ dependencies into the submodule folder.</p>
 
 <ul><li>npm help json</li><li>git help submodule</li></ul>
 </div>
-<p id="footer">submodule &mdash; npm@1.1.61</p>
+<p id="footer">submodule &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/tag.html

@@ -29,7 +29,7 @@ parameter is missing or falsey (empty), the default froom the config will be
 used. For more information about how to set this config, check
 <code>man 3 npm-config</code> for programmatic usage or <code>man npm-config</code> for cli usage.</p>
 </div>
-<p id="footer">tag &mdash; npm@1.1.61</p>
+<p id="footer">tag &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/test.html

@@ -22,7 +22,7 @@ true.</p>
 <p>npm can run tests on multiple packages. Just specify multiple packages
 in the <code>packages</code> parameter.</p>
 </div>
-<p id="footer">test &mdash; npm@1.1.61</p>
+<p id="footer">test &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/uninstall.html

@@ -22,7 +22,7 @@ the name of a package to be uninstalled.</p>
 <p>Finally, &#39;callback&#39; is a function that will be called when all packages have been
 uninstalled or when an error has been encountered.</p>
 </div>
-<p id="footer">uninstall &mdash; npm@1.1.61</p>
+<p id="footer">uninstall &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/unpublish.html

@@ -26,7 +26,7 @@ is what is meant.</p>
 <p>If no version is specified, or if all versions are removed then
 the root package entry is removed from the registry entirely.</p>
 </div>
-<p id="footer">unpublish &mdash; npm@1.1.61</p>
+<p id="footer">unpublish &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/update.html

@@ -18,7 +18,7 @@
 
 <p>The &#39;packages&#39; argument is an array of packages to update. The &#39;callback&#39; parameter will be called when done or when an error occurs.</p>
 </div>
-<p id="footer">update &mdash; npm@1.1.61</p>
+<p id="footer">update &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/version.html

@@ -24,7 +24,7 @@ fail if the repo is not clean.</p>
 parameter. The difference, however, is this function will fail if it does
 not have exactly one element. The only element should be a version number.</p>
 </div>
-<p id="footer">version &mdash; npm@1.1.61</p>
+<p id="footer">version &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/view.html

@@ -99,7 +99,7 @@ the field name.</p>
 
 <p>corresponding to the list of fields selected.</p>
 </div>
-<p id="footer">view &mdash; npm@1.1.61</p>
+<p id="footer">view &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/api/whoami.html

@@ -21,7 +21,7 @@
 
 <p>This function is not useful programmatically</p>
 </div>
-<p id="footer">whoami &mdash; npm@1.1.61</p>
+<p id="footer">whoami &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/doc/README.html

@@ -16,7 +16,7 @@
 
 <h2 id="IMPORTANT">IMPORTANT</h2>
 
-<p><strong>You need node v0.6 or higher to run this program.</strong></p>
+<p><strong>You need node v0.8 or higher to run this program.</strong></p>
 
 <p>To install an old <strong>and unsupported</strong> version of npm that works on node 0.3
 and prior, clone the git repo and dig through the old tags and branches.</p>
@@ -49,11 +49,11 @@ paths, etc.) then read on.</p>
 
 <p>You can set any npm configuration params with that script:</p>
 
-<p>npm<em>config</em>prefix=/some/path sh install.sh</p>
+<pre><code>npm_config_prefix=/some/path sh install.sh</code></pre>
 
 <p>Or, you can run it in uber-debuggery mode:</p>
 
-<p>npm_debug=1 sh install.sh</p>
+<pre><code>npm_debug=1 sh install.sh</code></pre>
 
 <h3 id="Even-Fancier">Even Fancier</h3>
 
@@ -67,7 +67,7 @@ for testing, or running stuff without actually installing npm itself.)</p>
 
 <h2 id="Fancy-Windows-Install">Fancy Windows Install</h2>
 
-<p>You can download a zip file from <a href="http://npmjs.org/dist/">http://npmjs.org/dist/</a>, and unpack it
+<p>You can download a zip file from <a href="https://npmjs.org/dist/">https://npmjs.org/dist/</a>, and unpack it
 in the same folder where node.exe lives.</p>
 
 <p>If that&#39;s not fancy enough for you, then you can fetch the code with
@@ -175,13 +175,13 @@ help config</code> to learn about all the options you can set there.</p>
 
 <h2 id="More-Docs">More Docs</h2>
 
-<p>Check out the <a href="http://npmjs.org/doc/">docs</a>,
-especially the <a href="http://npmjs.org/doc/faq.html">faq</a>.</p>
+<p>Check out the <a href="https://npmjs.org/doc/">docs</a>,
+especially the <a href="https://npmjs.org/doc/faq.html">faq</a>.</p>
 
 <p>You can use the <code>npm help</code> command to read any of them.</p>
 
 <p>If you&#39;re a developer, and you want to use npm to publish your program,
-you should <a href="http://npmjs.org/doc/developers.html">read this</a></p>
+you should <a href="https://npmjs.org/doc/developers.html">read this</a></p>
 
 <h2 id="Legal-Stuff">Legal Stuff</h2>
 
@@ -227,7 +227,7 @@ process for published modules.</p>
 <p>When you find issues, please report them:</p>
 
 <ul><li>web:
-<a href="http://github.com/isaacs/npm/issues">http://github.com/isaacs/npm/issues</a></li><li>email:
+<a href="https://github.com/isaacs/npm/issues">https://github.com/isaacs/npm/issues</a></li><li>email:
 <a href="mailto:npm-@googlegroups.com">npm-@googlegroups.com</a></li></ul>
 
 <p>Be sure to include <em>all</em> of the output from the npm command that didn&#39;t work
@@ -240,7 +240,7 @@ will no doubt tell you to put the output in a gist or email.</p>
 
 <ul><li><a href="../doc/npm.html">npm(1)</a></li><li><a href="../doc/faq.html">faq(1)</a></li><li><a href="../doc/help.html">help(1)</a></li><li><a href="../doc/index.html">index(1)</a></li></ul>
 </div>
-<p id="footer"><a href="../doc/README.html">README</a> &mdash; npm@1.1.61</p>
+<p id="footer"><a href="../doc/README.html">README</a> &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/doc/adduser.html

@@ -39,7 +39,7 @@ authorize on a new machine.</p>
 
 <ul><li><a href="../doc/registry.html">registry(1)</a></li><li><a href="../doc/config.html">config(1)</a></li><li><a href="../doc/owner.html">owner(1)</a></li><li><a href="../doc/whoami.html">whoami(1)</a></li></ul>
 </div>
-<p id="footer">adduser &mdash; npm@1.1.61</p>
+<p id="footer">adduser &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/doc/bin.html

@@ -20,7 +20,7 @@
 
 <ul><li><a href="../doc/prefix.html">prefix(1)</a></li><li><a href="../doc/root.html">root(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">bin &mdash; npm@1.1.61</p>
+<p id="footer">bin &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/doc/bugs.html

@@ -22,7 +22,7 @@ config param.</p>
 
 <h3 id="browser">browser</h3>
 
-<ul><li>Default: OS X: <code>&quot;open&quot;</code>, others: <code>&quot;google-chrome&quot;</code></li><li>Type: String</li></ul>
+<ul><li>Default: OS X: <code>&quot;open&quot;</code>, Windows: <code>&quot;start&quot;</code>, Others: <code>&quot;xdg-open&quot;</code></li><li>Type: String</li></ul>
 
 <p>The browser that is called by the <code>npm bugs</code> command to open websites.</p>
 
@@ -36,7 +36,7 @@ config param.</p>
 
 <ul><li><a href="../doc/docs.html">docs(1)</a></li><li><a href="../doc/view.html">view(1)</a></li><li><a href="../doc/publish.html">publish(1)</a></li><li><a href="../doc/registry.html">registry(1)</a></li><li><a href="../doc/config.html">config(1)</a></li><li><a href="../doc/json.html">json(1)</a></li></ul>
 </div>
-<p id="footer">bugs &mdash; npm@1.1.61</p>
+<p id="footer">bugs &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/doc/build.html

@@ -25,7 +25,7 @@ A folder containing a <code>package.json</code> file in its root.</li></ul>
 
 <ul><li><a href="../doc/install.html">install(1)</a></li><li><a href="../doc/link.html">link(1)</a></li><li><a href="../doc/scripts.html">scripts(1)</a></li><li><a href="../doc/json.html">json(1)</a></li></ul>
 </div>
-<p id="footer">build &mdash; npm@1.1.61</p>
+<p id="footer">build &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/doc/bundle.html

@@ -20,7 +20,7 @@ install packages into the local space.</p>
 
 <ul><li><a href="../doc/install.html">install(1)</a></li></ul>
 </div>
-<p id="footer">bundle &mdash; npm@1.1.61</p>
+<p id="footer">bundle &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/doc/cache.html

@@ -66,7 +66,7 @@ they do not make an HTTP request to the registry.</p>
 
 <ul><li><a href="../doc/folders.html">folders(1)</a></li><li><a href="../doc/config.html">config(1)</a></li><li><a href="../doc/install.html">install(1)</a></li><li><a href="../doc/publish.html">publish(1)</a></li><li><a href="../doc/pack.html">pack(1)</a></li></ul>
 </div>
-<p id="footer">cache &mdash; npm@1.1.61</p>
+<p id="footer">cache &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/doc/changelog.html

@@ -65,7 +65,7 @@
 
 <ul><li><a href="../doc/npm.html">npm(1)</a></li><li><a href="../doc/faq.html">faq(1)</a></li></ul>
 </div>
-<p id="footer">changelog &mdash; npm@1.1.61</p>
+<p id="footer">changelog &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/doc/coding-style.html

@@ -17,6 +17,8 @@ designed to reduce visual clutter and make bugs more apparent.</p>
 <p>If you want to contribute to npm (which is very encouraged), you should
 make your code conform to npm&#39;s style.</p>
 
+<p>Note: this concerns npm&#39;s code not the specific packages at npmjs.org</p>
+
 <h2 id="Line-Length">Line Length</h2>
 
 <p>Keep lines shorter than 80 characters.  It&#39;s better for lines to be
@@ -180,7 +182,7 @@ set to anything.&quot;</p>
 
 <ul><li><a href="../doc/developers.html">developers(1)</a></li><li><a href="../doc/faq.html">faq(1)</a></li><li><a href="../doc/npm.html">npm(1)</a></li></ul>
 </div>
-<p id="footer">coding-style &mdash; npm@1.1.61</p>
+<p id="footer">coding-style &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/doc/completion.html

@@ -33,7 +33,7 @@ completions based on the arguments.</p>
 
 <ul><li><a href="../doc/developers.html">developers(1)</a></li><li><a href="../doc/faq.html">faq(1)</a></li><li><a href="../doc/npm.html">npm(1)</a></li></ul>
 </div>
-<p id="footer">completion &mdash; npm@1.1.61</p>
+<p id="footer">completion &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/doc/config.html

@@ -42,12 +42,16 @@ work the same.</p>
 
 <p><code>$HOME/.npmrc</code> (or the <code>userconfig</code> param, if set above)</p>
 
-<p>This file is an ini-file formatted list of <code>key = value</code> parameters.</p>
+<p>This file is an ini-file formatted list of <code>key = value</code> parameters.
+Environment variables can be replaced using <code>${VARIABLE_NAME}</code>. For example:</p>
+
+<pre><code>prefix = ${HOME}/.npm-packages</code></pre>
 
 <h3 id="Global-config-file">Global config file</h3>
 
 <p><code>$PREFIX/etc/npmrc</code> (or the <code>globalconfig</code> param, if set above):
-This file is an ini-file formatted list of <code>key = value</code> parameters</p>
+This file is an ini-file formatted list of <code>key = value</code> parameters.
+Environment variables can be replaced as above.</p>
 
 <h3 id="Built-in-config-file">Built-in config file</h3>
 
@@ -105,7 +109,7 @@ global config.</p>
 
 <p>The following shorthands are parsed on the command-line:</p>
 
-<ul><li><code>-v</code>: <code>--version</code></li><li><code>-h</code>, <code>-?</code>, <code>--help</code>, <code>-H</code>: <code>--usage</code></li><li><code>-s</code>, <code>--silent</code>: <code>--loglevel silent</code></li><li><code>-q</code>, <code>--quiet</code>: <code>--loglevel warn</code></li><li><code>-d</code>: <code>--loglevel info</code></li><li><code>-dd</code>, <code>--verbose</code>: <code>--loglevel verbose</code></li><li><code>-ddd</code>: <code>--loglevel silly</code></li><li><code>-g</code>: <code>--global</code></li><li><code>-l</code>: <code>--long</code></li><li><code>-m</code>: <code>--message</code></li><li><code>-p</code>, <code>--porcelain</code>: <code>--parseable</code></li><li><code>-reg</code>: <code>--registry</code></li><li><code>-v</code>: <code>--version</code></li><li><code>-f</code>: <code>--force</code></li><li><code>-l</code>: <code>--long</code></li><li><code>-desc</code>: <code>--description</code></li><li><code>-S</code>: <code>--save</code></li><li><code>-D</code>: <code>--save-dev</code></li><li><code>-O</code>: <code>--save-optional</code></li><li><code>-B</code>: <code>--save-bundle</code></li><li><code>-y</code>: <code>--yes</code></li><li><code>-n</code>: <code>--yes false</code></li><li><code>ll</code> and <code>la</code> commands: <code>ls --long</code></li></ul>
+<ul><li><code>-v</code>: <code>--version</code></li><li><code>-h</code>, <code>-?</code>, <code>--help</code>, <code>-H</code>: <code>--usage</code></li><li><code>-s</code>, <code>--silent</code>: <code>--loglevel silent</code></li><li><code>-q</code>, <code>--quiet</code>: <code>--loglevel warn</code></li><li><code>-d</code>: <code>--loglevel info</code></li><li><code>-dd</code>, <code>--verbose</code>: <code>--loglevel verbose</code></li><li><code>-ddd</code>: <code>--loglevel silly</code></li><li><code>-g</code>: <code>--global</code></li><li><code>-l</code>: <code>--long</code></li><li><code>-m</code>: <code>--message</code></li><li><code>-p</code>, <code>--porcelain</code>: <code>--parseable</code></li><li><code>-reg</code>: <code>--registry</code></li><li><code>-v</code>: <code>--version</code></li><li><code>-f</code>: <code>--force</code></li><li><code>-desc</code>: <code>--description</code></li><li><code>-S</code>: <code>--save</code></li><li><code>-D</code>: <code>--save-dev</code></li><li><code>-O</code>: <code>--save-optional</code></li><li><code>-B</code>: <code>--save-bundle</code></li><li><code>-y</code>: <code>--yes</code></li><li><code>-n</code>: <code>--yes false</code></li><li><code>ll</code> and <code>la</code> commands: <code>ls --long</code></li></ul>
 
 <p>If the specified configuration param resolves unambiguously to a known
 configuration parameter, then it is expanded to that configuration
@@ -152,9 +156,20 @@ the package.json has this:</p>
 <p>Force npm to always require authentication when accessing the registry,
 even for <code>GET</code> requests.</p>
 
+<h3 id="bin-links">bin-links</h3>
+
+<ul><li>Default: <code>true</code></li><li>Type: Boolean</li></ul>
+
+<p>Tells npm to create symlinks (or <code>.cmd</code> shims on Windows) for package
+executables.</p>
+
+<p>Set to false to have it not do this.  This can be used to work around
+the fact that some file systems don&#39;t support symlinks, even on
+ostensibly Unix systems.</p>
+
 <h3 id="browser">browser</h3>
 
-<ul><li>Default: OS X: <code>&quot;open&quot;</code>, others: <code>&quot;google-chrome&quot;</code></li><li>Type: String</li></ul>
+<ul><li>Default: OS X: <code>&quot;open&quot;</code>, Windows: <code>&quot;start&quot;</code>, Others: <code>&quot;xdg-open&quot;</code></li><li>Type: String</li></ul>
 
 <p>The browser that is called by the <code>npm docs</code> command to open websites.</p>
 
@@ -206,7 +221,7 @@ explicitly used, and that only GET requests use the cache.</p>
 
 <h3 id="cache-min">cache-min</h3>
 
-<ul><li>Default: 0</li><li>Type: Number</li></ul>
+<ul><li>Default: 10</li><li>Type: Number</li></ul>
 
 <p>The minimum time (in seconds) to keep items in the registry cache before
 re-checking against the registry.</p>
@@ -317,8 +332,8 @@ the git binary.</p>
 <code>prefix</code> folder instead of the current working directory.  See
 <code><a href="../doc/folders.html">folders(1)</a></code> for more on the differences in behavior.</p>
 
-<ul><li>packages are installed into the <code>prefix/node_modules</code> folder, instead of the
-current working directory.</li><li>bin files are linked to <code>prefix/bin</code></li><li>man pages are linked to <code>prefix/share/man</code></li></ul>
+<ul><li>packages are installed into the <code>{prefix}/lib/node_modules</code> folder, instead of the
+current working directory.</li><li>bin files are linked to <code>{prefix}/bin</code></li><li>man pages are linked to <code>{prefix}/share/man</code></li></ul>
 
 <h3 id="globalconfig">globalconfig</h3>
 
@@ -352,7 +367,7 @@ user.</p>
 
 <h3 id="user-agent">user-agent</h3>
 
-<ul><li>Default: npm/{npm.version} node/{process.version}</li><li>Type: String</li></ul>
+<ul><li>Default: node/{process.version} {process.platform} {process.arch}</li><li>Type: String</li></ul>
 
 <p>Sets a User-Agent to the request header</p>
 
@@ -501,7 +516,7 @@ standard output.</p>
 
 <h3 id="prefix">prefix</h3>
 
-<ul><li>Default: node&#39;s process.installPrefix</li><li>Type: path</li></ul>
+<ul><li>Default: see <a href="../doc/folders.html">folders(1)</a></li><li>Type: path</li></ul>
 
 <p>The location to install global items.  If set on the command line, then
 it forces non-global commands to run in the specified folder.</p>
@@ -621,6 +636,13 @@ Windows</li><li>Type: path</li></ul>
 
 <p>The shell to run for the <code>npm explore</code> command.</p>
 
+<h3 id="shrinkwrap">shrinkwrap</h3>
+
+<ul><li>Default: true</li><li>Type: Boolean</li></ul>
+
+<p>If set to false, then ignore <code>npm-shrinkwrap.json</code> files when
+installing.</p>
+
 <h3 id="sign-git-tag">sign-git-tag</h3>
 
 <ul><li>Default: false</li><li>Type: Boolean</li></ul>
@@ -756,7 +778,7 @@ then answer &quot;no&quot; to any prompt.</p>
 
 <ul><li><a href="../doc/folders.html">folders(1)</a></li><li><a href="../doc/npm.html">npm(1)</a></li></ul>
 </div>
-<p id="footer">config &mdash; npm@1.1.61</p>
+<p id="footer">config &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/doc/dedupe.html

@@ -57,7 +57,7 @@ registry.</p>
 
 <ul><li><a href="../doc/ls.html">ls(1)</a></li><li><a href="../doc/update.html">update(1)</a></li><li><a href="../doc/install.html">install(1)</a></li></ul>
 </div>
-<p id="footer">dedupe &mdash; npm@1.1.61</p>
+<p id="footer">dedupe &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/doc/deprecate.html

@@ -25,11 +25,13 @@ something like this:</p>
 <p>Note that you must be the package owner to deprecate something.  See the
 <code>owner</code> and <code>adduser</code> help topics.</p>
 
+<p>To un-deprecate a package, specify an empty string (<code>&quot;&quot;</code>) for the <code>message</code> argument.</p>
+
 <h2 id="SEE-ALSO">SEE ALSO</h2>
 
 <ul><li><a href="../doc/publish.html">publish(1)</a></li><li><a href="../doc/registry.html">registry(1)</a></li></ul>
 </div>
-<p id="footer">deprecate &mdash; npm@1.1.61</p>
+<p id="footer">deprecate &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/doc/developers.html

@@ -82,10 +82,24 @@ more info.</p>
 <h2 id="Keeping-files-out-of-your-package">Keeping files <em>out</em> of your package</h2>
 
 <p>Use a <code>.npmignore</code> file to keep stuff out of your package.  If there&#39;s
-no .npmignore file, but there <em>is</em> a .gitignore file, then npm will
-ignore the stuff matched by the .gitignore file.  If you <em>want</em> to
-include something that is excluded by your .gitignore file, you can
-create an empty .npmignore file to override it.</p>
+no <code>.npmignore</code> file, but there <em>is</em> a <code>.gitignore</code> file, then npm will
+ignore the stuff matched by the <code>.gitignore</code> file.  If you <em>want</em> to
+include something that is excluded by your <code>.gitignore</code> file, you can
+create an empty <code>.npmignore</code> file to override it.</p>
+
+<p>By default, the following paths and files are ignored, so there&#39;s no
+need to add them to <code>.npmignore</code> explicitly:</p>
+
+<ul><li><code>.*.swp</code></li><li><code>._*</code></li><li><code>.DS_Store</code></li><li><code>.git</code></li><li><code>.hg</code></li><li><code>.lock-wscript</code></li><li><code>.svn</code></li><li><code>.wafpickle-*</code></li><li><code>CVS</code></li><li><code>npm-debug.log</code></li></ul>
+
+<p>Additionally, everything in <code>node_modules</code> is ignored, except for
+bundled dependencies. npm automatically handles this for you, so don&#39;t
+bother adding <code>node_modules</code> to <code>.npmignore</code>.</p>
+
+<p>The following paths and files are never ignored, so adding them to
+<code>.npmignore</code> is pointless:</p>
+
+<ul><li><code>package.json</code></li><li><code><a href="../doc/README.html">README</a>.*</code></li></ul>
 
 <h2 id="Link-Packages">Link Packages</h2>
 
@@ -160,7 +174,7 @@ from a fresh checkout.</p>
 
 <ul><li><a href="../doc/faq.html">faq(1)</a></li><li><a href="../doc/npm.html">npm(1)</a></li><li><a href="../doc/init.html">init(1)</a></li><li><a href="../doc/json.html">json(1)</a></li><li><a href="../doc/scripts.html">scripts(1)</a></li><li><a href="../doc/publish.html">publish(1)</a></li><li><a href="../doc/adduser.html">adduser(1)</a></li><li><a href="../doc/registry.html">registry(1)</a></li></ul>
 </div>
-<p id="footer">developers &mdash; npm@1.1.61</p>
+<p id="footer">developers &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/doc/disputes.html

@@ -12,15 +12,17 @@
 
 <ol><li>Get the author email with <code>npm owner ls &lt;pkgname&gt;</code></li><li>Email the author, CC <a href="mailto:i@izs.me">i@izs.me</a>.</li><li>After a few weeks, if there&#39;s no resolution, we&#39;ll sort it out.</li></ol>
 
+<p>Don&#39;t squat on package names.  Publish code or move out of the way.</p>
+
 <h2 id="DESCRIPTION">DESCRIPTION</h2>
 
 <p>There sometimes arise cases where a user publishes a module, and then
 later, some other user wants to use that name.  Here are some common
 ways that happens (each of these is based on actual events.)</p>
 
-<ol><li>Bob writes a JavaScript module <code>foo</code>, which is not node-specific.
-Bob doesn&#39;t use node at all.  Joe wants to use <code>foo</code> in node, so he
-wraps it in an npm module.  Some time later, Bob starts using node,
+<ol><li>Joe writes a JavaScript module <code>foo</code>, which is not node-specific.
+Joe doesn&#39;t use node at all.  Bob   wants to use <code>foo</code> in node, so he
+wraps it in an npm module.  Some time later, Joe starts using node,
 and wants to take over management of his program.</li><li>Bob writes an npm module <code>foo</code>, and publishes it.  Perhaps much
 later, Joe finds a bug in <code>foo</code>, and fixes it.  He sends a pull
 request to Bob, but Bob doesn&#39;t have the time to deal with it,
@@ -41,13 +43,14 @@ but can&#39;t publish, because Bob&#39;s <code>foo</code> is in the way.</li></o
 Joe&#39;s appropriate course of action in each case is the same.</p>
 
 <ol><li><code>npm owner ls foo</code>.  This will tell Joe the email address of the
-owner (Bob).</li><li>Joe emails Bob, explaining the situation <strong>as respecfully as possible</strong>,
+owner (Bob).</li><li>Joe emails Bob, explaining the situation <strong>as respectfully as possible</strong>,
 and what he would like to do with the module name.  He adds
 isaacs <a href="mailto:i@izs.me">i@izs.me</a> to the CC list of the email.  Mention in the email
 that Bob can run <code>npm owner add joe foo</code> to add Joe as an owner of
 the <code>foo</code> package.</li><li>After a reasonable amount of time, if Bob has not responded, or if
 Bob and Joe can&#39;t come to any sort of resolution, email isaacs
-<a href="mailto:i@izs.me">i@izs.me</a> and we&#39;ll sort it out.</li></ol>
+<a href="mailto:i@izs.me">i@izs.me</a> and we&#39;ll sort it out.  (&quot;Reasonable&quot; is usually about 4
+weeks, but extra time is allowed around common holidays.)</li></ol>
 
 <h2 id="REASONING">REASONING</h2>
 
@@ -69,10 +72,18 @@ feeling good about the interaction.</p>
 they are brought to the attention of the npm registry admins, including
 but not limited to:</p>
 
-<ol><li>Malware (that is, a module designed to exploit or harm the machine on
-which it is installed)</li><li>Violations of copyright or licenses (for example, cloning an
+<ol><li>Malware (that is, a package designed to exploit or harm the machine on
+which it is installed).</li><li>Violations of copyright or licenses (for example, cloning an
 MIT-licensed program, and then removing or changing the copyright and
-license statement)</li><li>Illegal content.</li></ol>
+license statement).</li><li>Illegal content.</li><li>&quot;Squatting&quot; on a package name that you <em>plan</em> to use, but aren&#39;t
+actually using.  Sorry, I don&#39;t care how great the name is, or how
+perfect a fit it is for the thing that someday might happen.  If
+someone wants to use it today, and you&#39;re just taking up space with
+an empty tarball, you&#39;re going to be evicted.</li><li>Putting empty packages in the registry.  Packages must have SOME
+functionality.  It can be silly, but it can&#39;t be <em>nothing</em>.  (See
+also: squatting.)</li><li>Doing weird things with the registry, like using it as your own
+personal application database or otherwise putting non-packagey
+things into it.</li></ol>
 
 <p>If you see bad behavior like this, please report it right away.</p>
 
@@ -80,7 +91,7 @@ license statement)</li><li>Illegal content.</li></ol>
 
 <ul><li><a href="../doc/registry.html">registry(1)</a></li><li><a href="../doc/owner.html">owner(1)</a></li></ul>
 </div>
-<p id="footer">disputes &mdash; npm@1.1.61</p>
+<p id="footer">disputes &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/doc/docs.html

@@ -23,7 +23,7 @@ config param.</p>
 
 <h3 id="browser">browser</h3>
 
-<ul><li>Default: OS X: <code>&quot;open&quot;</code>, others: <code>&quot;google-chrome&quot;</code></li><li>Type: String</li></ul>
+<ul><li>Default: OS X: <code>&quot;open&quot;</code>, Windows: <code>&quot;start&quot;</code>, Others: <code>&quot;xdg-open&quot;</code></li><li>Type: String</li></ul>
 
 <p>The browser that is called by the <code>npm docs</code> command to open websites.</p>
 
@@ -37,7 +37,7 @@ config param.</p>
 
 <ul><li><a href="../doc/view.html">view(1)</a></li><li><a href="../doc/publish.html">publish(1)</a></li><li><a href="../doc/registry.html">registry(1)</a></li><li><a href="../doc/config.html">config(1)</a></li><li><a href="../doc/json.html">json(1)</a></li></ul>
 </div>
-<p id="footer">docs &mdash; npm@1.1.61</p>
+<p id="footer">docs &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/doc/edit.html

@@ -37,7 +37,7 @@ or <code>&quot;notepad&quot;</code> on Windows.</li><li>Type: path</li></ul>
 
 <ul><li><a href="../doc/folders.html">folders(1)</a></li><li><a href="../doc/explore.html">explore(1)</a></li><li><a href="../doc/install.html">install(1)</a></li><li><a href="../doc/config.html">config(1)</a></li></ul>
 </div>
-<p id="footer">edit &mdash; npm@1.1.61</p>
+<p id="footer">edit &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/doc/explore.html

@@ -40,7 +40,7 @@ Windows</li><li>Type: path</li></ul>
 
 <ul><li><a href="../doc/submodule.html">submodule(1)</a></li><li><a href="../doc/folders.html">folders(1)</a></li><li><a href="../doc/edit.html">edit(1)</a></li><li><a href="../doc/rebuild.html">rebuild(1)</a></li><li><a href="../doc/build.html">build(1)</a></li><li><a href="../doc/install.html">install(1)</a></li></ul>
 </div>
-<p id="footer">explore &mdash; npm@1.1.61</p>
+<p id="footer">explore &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/doc/faq.html

@@ -10,7 +10,7 @@
 
 <h2 id="Where-can-I-find-these-docs-in-HTML">Where can I find these docs in HTML?</h2>
 
-<p><a href="http://npmjs.org/doc/">http://npmjs.org/doc/</a>, or run:</p>
+<p><a href="https://npmjs.org/doc/">https://npmjs.org/doc/</a>, or run:</p>
 
 <pre><code>npm config set viewer browser</code></pre>
 
@@ -78,6 +78,52 @@ program that uses it.</p>
 
 <p>npm will not help you do something that is known to be a bad idea.</p>
 
+<h2 id="node_modules-is-the-name-of-my-deity-s-arch-rival-and-a-Forbidden-Word-in-my-religion-Can-I-configure-npm-to-use-a-different-folder"><code>&quot;node_modules&quot;</code> is the name of my deity&#39;s arch-rival, and a Forbidden Word in my religion.  Can I configure npm to use a different folder?</h2>
+
+<p>No.  This will never happen.  This question comes up sometimes,
+because it seems silly from the outside that npm couldn&#39;t just be
+configured to put stuff somewhere else, and then npm could load them
+from there.  It&#39;s an arbitrary spelling choice, right?  What&#39;s the big
+deal?</p>
+
+<p>At the time of this writing, the string <code>&#39;node_modules&#39;</code> appears 151
+times in 53 separate files in npm and node core (excluding tests and
+documentation).</p>
+
+<p>Some of these references are in node&#39;s built-in module loader.  Since
+npm is not involved <strong>at all</strong> at run-time, node itself would have to
+be configured to know where you&#39;ve decided to stick stuff.  Complexity
+hurdle #1.  Since the Node module system is locked, this cannot be
+changed, and is enough to kill this request.  But I&#39;ll continue, in
+deference to your deity&#39;s delicate feelings regarding spelling.</p>
+
+<p>Many of the others are in dependencies that npm uses, which are not
+necessarily tightly coupled to npm (in the sense that they do not read
+npm&#39;s configuration files, etc.)  Each of these would have to be
+configured to take the name of the <code>node_modules</code> folder as a
+parameter.  Complexity hurdle #2.</p>
+
+<p>Furthermore, npm has the ability to &quot;bundle&quot; dependencies by adding
+the dep names to the <code>&quot;bundledDependencies&quot;</code> list in package.json,
+which causes the folder to be included in the package tarball.  What
+if the author of a module bundles its dependencies, and they use a
+different spelling for <code>node_modules</code>?  npm would have to rename the
+folder at publish time, and then be smart enough to unpack it using
+your locally configured name.  Complexity hurdle #3.</p>
+
+<p>Furthermore, what happens when you <em>change</em> this name?  Fine, it&#39;s
+easy enough the first time, just rename the <code>node_modules</code> folders to
+<code>./blergyblerp/</code> or whatever name you choose.  But what about when you
+change it again?  npm doesn&#39;t currently track any state about past
+configuration settings, so this would be rather difficult to do
+properly.  It would have to track every previous value for this
+config, and always accept any of them, or else yesterday&#39;s install may
+be broken tomorrow.  Complexity hurdle #5.</p>
+
+<p>Never going to happen.  The folder is named <code>node_modules</code>.  It is
+written indelibly in the Node Way, handed down from the ancient times
+of Node 0.3.</p>
+
 <h2 id="Should-I-check-my-node_modules-folder-into-git">Should I check my <code>node_modules</code> folder into git?</h2>
 
 <p>Mikeal Rogers answered this question very well:</p>
@@ -148,7 +194,7 @@ command.)</p>
 
 <p>In those cases, you can do this:</p>
 
-<pre><code>curl http://npmjs.org/install.sh | sh</code></pre>
+<pre><code>curl https://npmjs.org/install.sh | sh</code></pre>
 
 <h2 id="What-is-a-package">What is a <code>package</code>?</h2>
 
@@ -173,10 +219,16 @@ an argument to <code>git checkout</code>.  The default is <code>master</code>.</
 
 <h2 id="How-do-I-install-node-with-npm">How do I install node with npm?</h2>
 
-<p>You don&#39;t.  Try one of these:</p>
+<p>You don&#39;t.  Try one of these node version managers:</p>
+
+<p>Unix:</p>
 
 <ul><li><a href="http://github.com/isaacs/nave">http://github.com/isaacs/nave</a></li><li><a href="http://github.com/visionmedia/n">http://github.com/visionmedia/n</a></li><li><a href="http://github.com/creationix/nvm">http://github.com/creationix/nvm</a></li></ul>
 
+<p>Windows:</p>
+
+<ul><li><a href="http://github.com/marcelklehr/nodist">http://github.com/marcelklehr/nodist</a></li><li><a href="https://github.com/hakobera/nvmw">https://github.com/hakobera/nvmw</a></li></ul>
+
 <h2 id="How-can-I-use-npm-for-development">How can I use npm for development?</h2>
 
 <p>See <code><a href="../doc/developers.html">developers(1)</a></code> and <code><a href="../doc/json.html">json(1)</a></code>.</p>
@@ -240,7 +292,7 @@ There is not sufficient need to impose namespace rules on everyone.</p>
 
 <p>Discuss it on the mailing list, or post an issue.</p>
 
-<ul><li><a href="mailto:npm-@googlegroups.com">npm-@googlegroups.com</a></li><li><a href="http://github.com/isaacs/npm/issues">http://github.com/isaacs/npm/issues</a></li></ul>
+<ul><li><a href="mailto:npm-@googlegroups.com">npm-@googlegroups.com</a></li><li><a href="https://github.com/isaacs/npm/issues">https://github.com/isaacs/npm/issues</a></li></ul>
 
 <h2 id="Why-does-npm-hate-me">Why does npm hate me?</h2>
 
@@ -250,7 +302,7 @@ There is not sufficient need to impose namespace rules on everyone.</p>
 
 <ul><li><a href="../doc/npm.html">npm(1)</a></li><li><a href="../doc/developers.html">developers(1)</a></li><li><a href="../doc/json.html">json(1)</a></li><li><a href="../doc/config.html">config(1)</a></li><li><a href="../doc/folders.html">folders(1)</a></li></ul>
 </div>
-<p id="footer">faq &mdash; npm@1.1.61</p>
+<p id="footer">faq &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/doc/folders.html

@@ -160,21 +160,21 @@ highest level possible, below the localized &quot;target&quot; folder.</p>
 +-- node_modules
     +-- blerg (1.2.5) &lt;---[A]
     +-- bar (1.2.3) &lt;---[B]
-    |   +-- node_modules
-    |   |   `-- baz (2.0.2) &lt;---[C]
-    |   |       `-- node_modules
-    |   |           `-- quux (3.2.0)
-    |   `-- asdf (2.3.4)
+    |   `-- node_modules
+    |       +-- baz (2.0.2) &lt;---[C]
+    |       |   `-- node_modules
+    |       |       `-- quux (3.2.0)
+    |       `-- asdf (2.3.4)
     `-- baz (1.2.3) &lt;---[D]
         `-- node_modules
             `-- quux (3.2.0) &lt;---[E]</code></pre>
 
-<p>Since foo depends directly on bar@1.2.3 and baz@1.2.3, those are
+<p>Since foo depends directly on <code>bar@1.2.3</code> and <code>baz@1.2.3</code>, those are
 installed in foo&#39;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&#39;s bar&#39;s dependency on blerg@1.x,
+parent installation of blerg satisfies bar&#39;s dependency on <code>blerg@1.x</code>,
 it does not install another copy under [B].</p>
 
 <p>Bar [B] also has dependencies on baz and asdf, so those are installed in
@@ -182,11 +182,11 @@ bar&#39;s <code>node_modules</code> folder.  Because it depends on <code>baz@2.x
 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-&gt;quux-&gt;bar</code> dependency creates a cycle.
-However, because <code>bar</code> is already in <code>quux</code>&#39;s ancestry [B], it does not
+<p>Underneath bar, the <code>baz -&gt; quux -&gt; bar</code> dependency creates a cycle.
+However, because bar is already in quux&#39;s ancestry [B], it does not
 unpack another copy of bar into that folder.</p>
 
-<p>Underneath <code>foo-&gt;baz</code> [D], quux&#39;s [E] folder tree is empty, because its
+<p>Underneath <code>foo -&gt; baz</code> [D], quux&#39;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>
@@ -205,7 +205,7 @@ cannot be found elsewhere.  See <code><a href="../doc/json.html">json(1)</a></co
 
 <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">folders &mdash; npm@1.1.61</p>
+<p id="footer">folders &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")

deps/npm/html/doc/global.html

@@ -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&#39;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&#39;re going to <code>require()</code> it.</li><li>Install it <strong>globally</strong> if you&#39;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&#39;s <code>process.installPrefix</code>.</p>
+
+<p>On windows, this is the exact location of the node.exe binary.  On Unix
+systems, it&#39;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(&quot;packagename&quot;)</code> to load its main module, or
+<code>require(&quot;packagename/lib/path/to/sub/module&quot;)</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
+&quot;current directory&quot; for the purpose of running npm commands.  (This
+behavior is inspired by and similar to git&#39;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&#39;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 &quot;globally&quot;.</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&#39;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 -&gt; bar -&gt; baz</code>.  Imagine if, in
+addition to that, baz depended on bar, so you&#39;d have:
+<code>foo -&gt; bar -&gt; baz -&gt; bar -&gt; baz ...</code>.  However, since the folder
+structure is: <code>foo/node_modules/bar/node_modules/baz</code>, there&#39;s no need to
+put another copy of bar into <code>.../baz/node_modules</code>, since when it calls
+require(&quot;bar&quot;), 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
+&quot;a&quot; 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 &quot;target&quot; 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) &lt;---[A]
+    +-- bar (1.2.3) &lt;---[B]
+    |   +-- node_modules
+    |   |   `-- baz (2.0.2) &lt;---[C]
+    |   |       `-- node_modules
+    |   |           `-- quux (3.2.0)
+    |   `-- asdf (2.3.4)
+    `-- baz (1.2.3) &lt;---[D]
+        `-- node_modules
+            `-- quux (3.2.0) &lt;---[E]</code></pre>
+
+<p>Since foo depends directly on bar@1.2.3 and baz@1.2.3, those are
+installed in foo&#39;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&#39;s bar&#39;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&#39;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-&gt;quux-&gt;bar</code> dependency creates a cycle.
+However, because <code>bar</code> is already in <code>quux</code>&#39;s ancestry [B], it does not
+unpack another copy of bar into that folder.</p>
+
+<p>Underneath <code>foo-&gt;baz</code> [D], quux&#39;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 &mdash; npm@1.2.30</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>

deps/npm/html/doc/help-search.html

@@ -38,7 +38,7 @@ where the terms were found in the documentation.</p>
 
 <ul><li><a href="../doc/npm.html">npm(1)</a></li><li><a href="../doc/faq.html">faq(1)</a></li><li><a href="../doc/help.html">help(1)</a></li></ul>
 </div>
-<p id="footer">help-search &mdash; npm@1.1.61</p>
+<p id="footer">help-search &mdash; npm@1.2.30</p>
 <script>
 ;(function () {
 var wrapper = document.getElementById("wrapper")