1berry/nodejs
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Include NPM, update .pkg to install it.

Browse Source 
.msi update coming soon.
This commit is contained in:
Ryan Dahl 2011-11-21 09:48:45 -08:00
parent 05de01d707
commit b488be127a
449 changed files with 33131 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
LICENSE
View File

@ -78,3 +78,9 @@ The externally maintained libraries used by Node are:
- deps/zlib copyright 1995-2010 Jean-loup Gailly and Mark Adler - deps/zlib copyright 1995-2010 Jean-loup Gailly and Mark Adler
licensed under a permissive free software license. See licensed under a permissive free software license. See
deps/zlib/LICENSE. deps/zlib/LICENSE.
- deps/npm NPM is a package manager program copyright 2009, 2010, 2011
Isaac Z. Schlueter and licensed under MIT. NPM includes several
subpackages MIT or Apache licenses, see deps/npm/LICENSE for more
information. NPM is included in the Node .msi and .pkg distributions
but not in the Node binary itself.

15
deps/npm/.gitignore vendored Normal file
View File

@ -0,0 +1,15 @@
*.swp
test/bin
test/output.log
test/packages/*/node_modules
test/packages/npm-test-depends-on-spark/which-spark.log
test/packages/test-package/random-data.txt
test/root
node_modules/ronn
node_modules/.bin
npm-debug.log
html/api/*.html
html/doc/*.html
man/
doc/*/index.md
./npmrc

51
deps/npm/.gitmodules vendored Normal file
View File

@ -0,0 +1,51 @@
[submodule "node_modules/semver"]
path = node_modules/semver
url = https://github.com/isaacs/node-semver.git
[submodule "node_modules/abbrev"]
path = node_modules/abbrev
url = https://github.com/isaacs/abbrev-js.git
[submodule "node_modules/nopt"]
path = node_modules/nopt
url = https://github.com/isaacs/nopt.git
[submodule "node_modules/node-uuid"]
path = node_modules/node-uuid
url = https://github.com/broofa/node-uuid
[submodule "node_modules/minimatch"]
path = node_modules/minimatch
url = https://github.com/isaacs/minimatch.git
[submodule "node_modules/graceful-fs"]
path = node_modules/graceful-fs
url = https://github.com/isaacs/node-graceful-fs.git
[submodule "node_modules/slide"]
path = node_modules/slide
url = https://github.com/isaacs/slide-flow-control.git
[submodule "node_modules/rimraf"]
path = node_modules/rimraf
url = https://github.com/isaacs/rimraf.git
[submodule "node_modules/proto-list"]
path = node_modules/proto-list
url = https://github.com/isaacs/proto-list.git
[submodule "node_modules/ini"]
path = node_modules/ini
url = https://github.com/isaacs/ini.git
[submodule "node_modules/which"]
path = node_modules/which
url = https://github.com/isaacs/node-which.git
[submodule "node_modules/request"]
path = node_modules/request
url = https://github.com/isaacs/request.git
[submodule "node_modules/tar"]
path = node_modules/tar
url = git://github.com/isaacs/node-tar.git
[submodule "node_modules/fstream"]
path = node_modules/fstream
url = git://github.com/isaacs/fstream.git
[submodule "node_modules/inherits"]
path = node_modules/inherits
url = git://github.com/isaacs/inherits.git
[submodule "node_modules/block-stream"]
path = node_modules/block-stream
url = git://github.com/isaacs/block-stream.git
[submodule "node_modules/mkdirp"]
path = node_modules/mkdirp
url = git://github.com/isaacs/node-mkdirp.git

11
deps/npm/.npmignore vendored Normal file
View File

@ -0,0 +1,11 @@
*.swp
test/bin
test/output.log
test/packages/*/node_modules
test/packages/npm-test-depends-on-spark/which-spark.log
test/packages/test-package/random-data.txt
test/root
node_modules/ronn
node_modules/.bin
npm-debug.log
./npmrc

50
deps/npm/AUTHORS vendored Normal file
View File

@ -0,0 +1,50 @@
# Authors sorted by whether or not they're me
Isaac Z. Schlueter <i@izs.me> (http://blog.izs.me/)
Steve Steiner <ssteinerX@gmail.com> (http://websaucesoftware.com/blog/)
Mikeal Rogers <mikeal.rogers@gmail.com> (http://www.mikealrogers.com/)
Aaron Blohowiak <aaron.blohowiak@gmail.com> (http://aaronblohowiak.com/)
Martyn Smith <martyn@dollyfish.net.nz> (http://dollyfish.net.nz/)
Mathias Pettersson <mape@mape.me> (http://mape.me/)
Brian Hammond <brian@fictorial.com> (http://fictorial.com/)
Charlie Robbins <charlie.robbins@gmail.com> (http://www.charlierobbins.com/)
Francisco Treacy <francisco.treacy@gmail.com> (http://franciscotreacy.com/)
Cliffano Subagio <cliffano@gmail.com> (http://blog.cliffano.com/)
Christian Eager <christian.eager@nokia.com> (http://perpenduum.com)
Dav Glass <davglass@gmail.com> (http://blog.davglass.com)
Alex K. Wolfe <alexkwolfe@gmail.com>
James Sanders <jimmyjazz14@gmail.com> (http://james-sanders.com/)
Reid Burke <me@reidburke.com> (http://reidburke.com/)
Arlo Breault <arlolra@gmail.com> (http://thoughtherder.com/)
Timo Derstappen <teemow@gmail.com> (http://teemow.com)
Bradley Meck <bradley.meck@gmail.com>
Bart Teeuwisse <bart.teeuwisse@thecodemill.biz> (http://thecodemill.biz/)
Ben Noordhuis <info@bnoordhuis.nl> (http://bnoordhuis.nl/)
Tor Valamo <tor.valamo@gmail.com> (http://www.magnimedia.no/)
Whyme.Lyu <5longluna@gmail.com> (http://whyme.kuantu.com/)
Olivier Melcher <olivier.melcher@gmail.com>
Tomaž Muraus <kami@k5-storitve.net> (http://www.tomaz-muraus.info)
Evan Meagher <evan.meagher@gmail.com> (http://evanmeagher.net/)
Orlando Vazquez <ovazquez@gmail.com> (http://2wycked.net/)
George Miroshnykov <gmiroshnykov@lohika.com>
Geoff Flarity (http://ca.linkedin.com/pub/geoff-flarity/a/536/43a)
Pete Kruckenberg <pete@kruckenberg.com>
Laurie Harper <laurie@holoweb.net> (http://laurie.holoweb.net/)
Chris Wong <chris@chriswongstudio.com>
Max Goodman <c@chromacode.com> (http://chromacode.com/)
Scott Bronson <brons_github@rinspin.com>
Federico Romero <federomero@gmail.com>
Visnu Pitiyanuvath <visnupx@gmail.com> (http://visnup.com)
Irakli Gozalishvili <rfobic@gmail.com> (http://jeditoolkit.com/)
Mark Cahill <mark@tiemonster.info> (http://www.tiemonster.info/)
Zearin <zearin@gonk.net>
Iain Sproat <iainsproat@gmail.com>
Trent Mick <trentm@gmail.com> (http://trentm.com/)
Felix Geisendörfer <felix@debuggable.com> (http://www.debuggable.com/)
Conny Brunnkvist <cbrunnkvist@gmail.com> (http://twitter.com/connyb)
Will Elwood <w.elwood08@gmail.com> (https://github.com/welwood08)
Oleg Efimov <efimovov@gmail.com> (http://sannis.ru)
Martin Cooper <mfncooper@gmail.com>
Jameson Little <t.jameson.little@gmail.com>
cspotcode <cspotcode@gmail.com>
Maciej Małecki <maciej.malecki@notimplemented.org>
Stephen Sugden <glurgle@gmail.com>

1
deps/npm/CHANGES vendored Symbolic link
View File

@ -0,0 +1 @@
doc/cli/changelog.md

61
deps/npm/LICENSE vendored Normal file
View File

@ -0,0 +1,61 @@
Copyright 2009, 2010, 2011 Isaac Z. Schlueter (the "Author")
All rights reserved.
MIT +no-false-attribs License
Permission is hereby granted, free of charge, to any person
obtaining a copy of this software and associated documentation
files (the "Software"), to deal in the Software without
restriction, including without limitation the rights to use,
copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the
Software is furnished to do so, subject to the following
conditions:
The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.
Distributions of all or part of the Software intended to be used
by the recipients as they would use the unmodified Software,
containing modifications that substantially alter, remove, or
disable functionality of the Software, outside of the documented
configuration mechanisms provided by the Software, shall be
modified such that the Author's bug reporting email addresses and
urls are either replaced with the contact information of the
parties responsible for the changes, or removed entirely.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
OTHER DEALINGS IN THE SOFTWARE.
Except where noted, this license applies to any and all software
programs and associated documentation files created by the
Author, when distributed with the Software.
"Node.js" and "node" trademark Joyent, Inc. npm is not officially
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.
"npm Logo" created by Mathias Pettersson and Brian Hammond,
used with permission.
This program includes a BSDTar/LibArchive version 2.8.3-1 binary,
originally distributed as part of the MinGW suite, compiled for
Win32, according to the terms of the BSD license.
See deps/basic-bsdtar-2.8.3-1-ming32-bin/basic-bsdtar.LICENSE.
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,
according to the terms of the Apache license.

125
deps/npm/Makefile vendored Normal file
View File

@ -0,0 +1,125 @@
SHELL = bash
markdowns = $(shell find doc -name '*.md' | grep -v 'index') README.md
cli_mandocs = $(shell find doc/cli -name '*.md' \
|sed 's|.md|.1|g' \
|sed 's|doc/cli/|man/man1/|g' ) \
man/man1/README.1 \
man/man1/index.1
api_mandocs = $(shell find doc/api -name '*.md' \
|sed 's|.md|.3|g' \
|sed 's|doc/api/|man/man3/|g' )
cli_htmldocs = $(shell find doc/cli -name '*.md' \
|grep -v 'index.md' \
|sed 's|.md|.html|g' \
|sed 's|doc/cli/|html/doc/|g' ) \
html/doc/README.html \
html/doc/index.html
api_htmldocs = $(shell find doc/api -name '*.md' \
|sed 's|.md|.html|g' \
|sed 's|doc/api/|html/api/|g' )
mandocs = $(api_mandocs) $(cli_mandocs)
htmldocs = $(api_htmldocs) $(cli_htmldocs)
all: submodules doc
submodules:
! [ -d .git ] || git submodule update --init --recursive
latest: submodules
@echo "Installing latest published npm"
@echo "Use 'make install' or 'make link' to install the code"
@echo "in this folder that you're looking at right now."
node cli.js install -g -f npm
install: all
node cli.js install -g -f
# backwards compat
dev: install
link: uninstall
node cli.js link -f
clean: doc-clean uninstall
rm npmrc
node cli.js cache clean
uninstall: submodules
node cli.js rm npm -g -f
doc: $(mandocs) $(htmldocs)
docclean: doc-clean
doc-clean:
rm -rf \
node_modules/ronn \
node_modules/.bin/ronn \
.building_ronn \
doc/cli/index.md \
doc/api/index.md \
$(api_mandocs) \
$(cli_mandocs) \
$(api_htmldocs) \
$(cli_htmldocs) \
&>/dev/null || true
# use `npm install ronn` for this to work.
man/man1/README.1: README.md scripts/doc-build.sh package.json
scripts/doc-build.sh $< $@
man/man1/%.1: doc/cli/%.md scripts/doc-build.sh package.json
@[ -d man/man1 ] || mkdir -p man/man1
scripts/doc-build.sh $< $@
man/man3/%.3: doc/api/%.md scripts/doc-build.sh package.json
@[ -d man/man3 ] || mkdir -p man/man3
scripts/doc-build.sh $< $@
html/doc/README.html: README.md html/dochead.html html/docfoot.html scripts/doc-build.sh package.json
scripts/doc-build.sh $< $@
html/doc/%.html: doc/cli/%.md html/dochead.html html/docfoot.html scripts/doc-build.sh package.json
scripts/doc-build.sh $< $@
html/api/%.html: doc/api/%.md html/dochead.html html/docfoot.html scripts/doc-build.sh package.json
scripts/doc-build.sh $< $@
doc/cli/index.md: $(markdowns) scripts/index-build.js scripts/doc-build.sh package.json
node scripts/index-build.js > $@
node_modules/ronn:
node cli.js install https://github.com/isaacs/ronnjs/tarball/master
doc: man
man: $(cli_docs) $(api_docs)
test: submodules
node cli.js test
version: link
git add package.json &&\
git ci -m v$(shell npm -v)
publish: link
git tag -s -m v$(shell npm -v) v$(shell npm -v) &&\
git push origin master --tags &&\
npm publish &&\
make doc-publish
docpublish: doc-publish
doc-publish: doc
rsync -vazu --stats --no-implied-dirs --delete html/doc/ npmjs.org:/var/www/npmjs.org/public/doc
rsync -vazu --stats --no-implied-dirs --delete html/api/ npmjs.org:/var/www/npmjs.org/public/api
sandwich:
@[ $$(whoami) = "root" ] && (echo "ok"; echo "ham" > sandwich) || echo "make it yourself"
.PHONY: all latest install dev link doc clean uninstall test man doc-publish doc-clean docclean docpublish

274
deps/npm/README.md vendored Normal file
View File

@ -0,0 +1,274 @@
npm(1) -- node package manager
==============================
## SYNOPSIS
This is just enough info to get you up and running.
Much more info available via `npm help` once it's installed.
## IMPORTANT
**You need node v0.4 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.
## Simple Install (Unix only, sorry)
To install npm with one command, do this:
curl http://npmjs.org/install.sh | sh
To skip the npm 0.x cleanup, do this:
curl http://npmjs.org/install.sh | clean=no sh
To say "yes" to the 0.x cleanup, but skip the prompt:
curl http://npmjs.org/install.sh | clean=yes sh
If you get permission errors, see the section below, entitled
"Permission Errors on Installation".
## Installing on Windows -- Experimental
Yes, this sucks. A convenient one-liner is coming soon.
### Step 1: Drop the node.exe somewhere
You will probably need the latest version of node, **at least** version
`0.5.8` or higher. You can get it from
<http://nodejs.org/dist/v0.5.8/node.exe>.
### Step 2 (optional): Update the %PATH% environment variable
Update your `%PATH%` environment variable in System Properties:
Advanced: Environment, so that it includes the `bin` folder you chose.
The entries are separated by semicolons.
You *may* be able to do this from the command line using `set` and
`setx`. `cd` into the `bin` folder you created in step 1, and do this:
set path=%PATH%;%CD%
setx path "%PATH%"
This will have the added advantage that you'll be able to simply type
`npm` or `node` in any project folder to access those commands.
If you decide not to update the PATH, and put the node.exe file in
`C:\node\node.exe`, then the npm executable will end up `C:\node\npm.cmd`,
and you'll have to type `C:\node\npm <command>` to use it.
### Step 3: Install git
If you don't already have git,
[install it](https://git.wiki.kernel.org/index.php/MSysGit:InstallMSysGit).
Run `git --version` to make sure that it's at least version 1.7.6.
### Step 4: install npm
Lastly, **after** node.exe, git, and your %PATH% have *all* been set up
properly, install npm itself:
git config --system http.sslcainfo /bin/curl-ca-bundle.crt
git clone --recursive git://github.com/isaacs/npm.git
cd npm
node cli.js install npm -gf
## Permission Errors (`EACCES` or `EACCESS`) on Installation
On Windows, you may need to run the command prompt in elevated
permission mode. (Right-click on cmd.exe, Run as Administrator.)
On Unix, you may need to run as root, or use `sudo`.
**Note**: You would need to `sudo` the `sh`, **not** the `curl`. Fetching
stuff from the internet typically doesn't require elevated permissions.
Running it might.
I highly recommend that you first download the file, and make sure that
it is what you expect, and *then* run it.
curl -O http://npmjs.org/install.sh
# inspect file..
sudo sh install.sh
## Installing on Cygwin
No.
## Dev Install
To install the latest **unstable** development version from git:
git clone https://github.com/isaacs/npm.git
cd npm
git submodule update --init --recursive
sudo make install # (or: `node cli.js install -gf`)
If you're sitting in the code folder reading this document in your
terminal, then you've already got the code. Just do:
git submodule update --init --recursive
sudo make install
and npm will install itself.
If you don't have make, and don't have curl or git, and ALL you have is
this code and node, you can probably do this:
git submodule update --init --recursive
sudo node ./cli.js install -g
Note that github tarballs **do not contain submodules**, so
those won't work. You'll have to also fetch the appropriate submodules
listed in the .gitmodules file.
## Permissions when Using npm to Install Other Stuff
**tl;dr**
* Use `sudo` for greater safety. Or don't, if you prefer not to.
* npm will downgrade permissions if it's root before running any build
scripts that package authors specified.
### More details...
As of version 0.3, it is recommended to run npm as root.
This allows npm to change the user identifier to the `nobody` user prior
to running any package build or test commands.
If you are not the root user, or if you are on a platform that does not
support uid switching, then npm will not attempt to change the userid.
If you would like to ensure that npm **always** runs scripts as the
"nobody" user, and have it fail if it cannot downgrade permissions, then
set the following configuration param:
npm config set unsafe-perm false
This will prevent running in unsafe mode, even as non-root users.
## Uninstalling
So sad to see you go.
sudo npm uninstall npm -g
Or, if that fails,
sudo make uninstall
## More Severe Uninstalling
Usually, the above instructions are sufficient. That will remove
npm, but leave behind anything you've installed.
If you would like to remove all the packages that you have installed,
then you can use the `npm ls` command to find them, and then `npm rm` to
remove them.
To remove cruft left behind by npm 0.x, you can use the included
`clean-old.sh` script file. You can run it conveniently like this:
npm explore npm -g -- sh scripts/clean-old.sh
npm uses two configuration files, one for per-user configs, and another
for global (every-user) configs. You can view them by doing:
npm config get userconfig # defaults to ~/.npmrc
npm config get globalconfig # defaults to /usr/local/etc/npmrc
Uninstalling npm does not remove configuration files by default. You
must remove them yourself manually if you want them gone. Note that
this means that future npm installs will not remember the settings that
you have chosen.
## Using npm Programmatically
If you would like to use npm programmatically, you can do that.
It's not very well documented, but it *is* rather simple.
var npm = require("npm")
npm.load(myConfigObject, function (er) {
if (er) return handlError(er)
npm.commands.install(["some", "args"], function (er, data) {
if (er) return commandFailed(er)
// command succeeded, and data might have some info
})
npm.on("log", function (message) { .... })
})
The `load` function takes an object hash of the command-line configs.
The various `npm.commands.<cmd>` functions take an **array** of
positional argument **strings**. The last argument to any
`npm.commands.<cmd>` function is a callback. Some commands take other
optional arguments. Read the source.
You cannot set configs individually for any single npm function at this
time. Since `npm` is a singleton, any call to `npm.config.set` will
change the value for *all* npm commands in that process.
See `./bin/npm-cli.js` for an example of pulling config values off of the
command line arguments using nopt. You may also want to check out `npm
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).
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)
## Legal Stuff
"npm" and "the npm registry" are owned by Isaac Z. Schlueter. All
rights not explicitly granted in the MIT license are reserved. See the
included LICENSE file for more details.
"Node.js" and "node" are trademarks owned by Joyent, Inc. npm is not
officially part of the Node.js project, and is neither owned by nor
officially affiliated with Joyent, Inc.
The packages in the npm registry are not part of npm itself, and are the
sole property of their respective maintainers. While every effort is
made to ensure accountability, there is absolutely no guarantee,
warrantee, or assertion made as to the quality, fitness for a specific
purpose, or lack of malice in any given npm package. Modules
published on the npm registry are not affiliated with or endorsed by
Joyent, Inc., Isaac Z. Schlueter, Ryan Dahl, or the Node.js project.
If you have a complaint about a package in the npm registry, and cannot
resolve it with the package owner, please express your concerns to
Isaac Z. Schlueter at <i@izs.me>.
### In plain english
This is mine; not my employer's, not Node's, not Joyent's, not Ryan
Dahl's.
If you publish something, it's yours, and you are solely accountable
for it. Not me, not Node, not Joyent, not Ryan Dahl.
If other people publish something, it's theirs. Not mine, not Node's,
not Joyent's, not Ryan Dahl's.
Yes, you can publish something evil. It will be removed promptly if
reported, and we'll lose respect for you. But there is no vetting
process for published modules.
If this concerns you, inspect the source before using packages.
## SEE ALSO
* npm(1)
* npm-faq(1)
* npm-help(1)
* npm-index(1)

77
deps/npm/bin/npm-cli.js vendored Executable file
View File

@ -0,0 +1,77 @@
#!/usr/bin/env node
;(function () { // wrapper in case we're in module_context mode
// windows: running "npm blah" in this folder will invoke WSH, not node.
if (typeof WScript !== "undefined") {
WScript.echo("npm does not work when run\n"
+"with the Windows Scripting Host\n\n"
+"'cd' to a different directory,\n"
+"or type 'npm.cmd <args>',\n"
+"or type 'node npm <args>'.")
WScript.quit(1)
return
}
var log = require("../lib/utils/log.js")
log.waitForConfig()
log.info("ok", "it worked if it ends with")
var fs = require("graceful-fs")
, path = require("path")
, npm = require("../lib/npm.js")
, ini = require("../lib/utils/ini.js")
, errorHandler = require("../lib/utils/error-handler.js")
, configDefs = require("../lib/utils/config-defs.js")
, shorthands = configDefs.shorthands
, types = configDefs.types
, nopt = require("nopt")
// if npm is called as "npmg" or "npm_g", then
// run in global mode.
if (path.basename(process.argv[1]).slice(-1) === "g") {
process.argv.splice(1, 1, "npm", "-g")
}
log.verbose(process.argv, "cli")
var conf = nopt(types, shorthands)
npm.argv = conf.argv.remain
if (npm.deref(npm.argv[0])) npm.command = npm.argv.shift()
else conf.usage = true
if (conf.version) {
console.log(npm.version)
return
}
log.info("npm@"+npm.version, "using")
log.info("node@"+process.version, "using")
// make sure that this version of node works with this version of npm.
var semver = require("semver")
, nodeVer = process.version
, reqVer = npm.nodeVersionRequired
if (reqVer && !semver.satisfies(nodeVer, reqVer)) {
return errorHandler(new Error(
"npm doesn't work with node " + nodeVer
+ "\nRequired: node@" + reqVer), true)
}
process.on("uncaughtException", errorHandler)
if (conf.usage && npm.command !== "help") {
npm.argv.unshift(npm.command)
npm.command = "help"
}
// now actually fire up npm and run the command.
// this is how to use npm programmatically:
conf._exit = true
npm.load(conf, function (er) {
if (er) return errorHandler(er)
npm.commands[npm.command](npm.argv, errorHandler)
})
})()

6
deps/npm/bin/npm-g.cmd vendored Normal file
View File

@ -0,0 +1,6 @@
:: Created by npm, please don't edit manually.
@IF EXIST "%~dp0"\"node.exe" (
"%~dp0"\"node.exe" "%~dp0\.\node_modules\npm\bin\npm-cli.js" %*
) ELSE (
node "%~dp0\.\node_modules\npm\bin\npm-cli.js" %*
)

16
deps/npm/bin/npm-get-uid-gid.js vendored Executable file
View File

@ -0,0 +1,16 @@
var argv = process.argv.slice(2)
, user = argv[0] || process.getuid()
, group = argv[1] || process.getgid()
if (!isNaN(user)) user = +user
if (!isNaN(group)) group = +group
console.error([user, group])
try {
process.setgid(group)
process.setuid(user)
console.log(JSON.stringify({uid:+process.getuid(), gid:+process.getgid()}))
} catch (ex) {
console.log(JSON.stringify({error:ex.message,errno:ex.errno}))
}

6
deps/npm/bin/npm.cmd vendored Normal file
View File

@ -0,0 +1,6 @@
:: Created by npm, please don't edit manually.
@IF EXIST "%~dp0"\"node.exe" (
"%~dp0"\"node.exe" "%~dp0\.\node_modules\npm\bin\npm-cli.js" %*
) ELSE (
node "%~dp0\.\node_modules\npm\bin\npm-cli.js" %*
)

6
deps/npm/bin/npm_g.cmd vendored Normal file
View File

@ -0,0 +1,6 @@
:: Created by npm, please don't edit manually.
@IF EXIST "%~dp0"\"node.exe" (
"%~dp0"\"node.exe" "%~dp0\.\node_modules\npm\bin\npm-cli.js" %*
) ELSE (
node "%~dp0\.\node_modules\npm\bin\npm-cli.js" %*
)

22
deps/npm/bin/read-package-json.js vendored Executable file
View File

@ -0,0 +1,22 @@
var argv = process.argv
if (argv.length < 3) {
console.error("Usage: read-package.json <file> [<fields> ...]")
process.exit(1)
}
var fs = require("fs")
, file = argv[2]
, readJson = require("../lib/utils/read-json")
readJson(file, function (er, data) {
if (er) throw er
if (argv.length === 3) console.log(data)
else argv.slice(3).forEach(function (field) {
field = field.split(".")
var val = data
field.forEach(function (f) {
val = val[f]
})
console.log(val)
})
})

2
deps/npm/cli.js vendored Executable file
View File

@ -0,0 +1,2 @@
#!/usr/bin/env node
require("./bin/npm-cli.js")

33
deps/npm/configure vendored Executable file
View File

@ -0,0 +1,33 @@
#!/bin/bash
# set configurations that will be "sticky" on this system,
# surviving npm self-updates.
CONFIGS=()
i=0
# get the location of this file.
unset CDPATH
CONFFILE=$(cd $(dirname "$0"); pwd -P)/npmrc
while [ $# -gt 0 ]; do
conf="$1"
case $conf in
--help)
echo "./configure --param=value ..."
exit 0
;;
--*)
CONFIGS[$i]="${conf:2}"
;;
*)
CONFIGS[$i]="$conf"
;;
esac
let i++
shift
done
for c in "${CONFIGS[@]}"; do
echo "$c" >> "$CONFFILE"
done

1
deps/npm/doc/api/author.md vendored Symbolic link
View File

@ -0,0 +1 @@
owner.md

13
deps/npm/doc/api/bin.md vendored Normal file
View File

@ -0,0 +1,13 @@
npm-bin(3) -- Display npm bin folder
====================================
## SYNOPSIS
npm.commands.bin(args, cb)
## DESCRIPTION
Print the folder where npm will install executables.
This function should not be used programmatically. Instead, just refer
to the `npm.bin` member.

19
deps/npm/doc/api/bugs.md vendored Normal file
View File

@ -0,0 +1,19 @@
npm-bugs(3) -- Bugs for a package in a web browser maybe
========================================================
## SYNOPSIS
npm.commands.bugs(package, callback)
## DESCRIPTION
This command tries to guess at the likely location of a package's
bug tracker URL, and then tries to open it using the `--browser`
config param.
Like other commands, the first parameter is an array. This command only
uses the first element, which is expected to be a package name with an
optional version number.
This command will launch a browser, so this command may not be the most
friendly for programmatic use.

22
deps/npm/doc/api/commands.md vendored Normal file
View File

@ -0,0 +1,22 @@
npm-commands(3) -- npm commands
===============================
## SYNOPSIS
npm.commands[<command>](args, callback)
## DESCRIPTION
npm comes with a full set of commands, and each of the commands takes a
similar set of arguments.
In general, all commands on the command object take an **array** of positional
argument **strings**. The last argument to any function is a callback. Some
commands are special and take other optional arguments.
All commands have their own man page. See `man npm-<command>` for command-line
usage, or `man 3 npm-<command>` for programmatic usage.
## SEE ALSO
* npm-index(1)

45
deps/npm/doc/api/config.md vendored Normal file
View File

@ -0,0 +1,45 @@
npm-config(3) -- Manage the npm configuration files
===================================================
## SYNOPSIS
npm.commands.config(args, callback)
var val = npm.config.get(key)
npm.config.set(key, val)
## DESCRIPTION
This function acts much the same way as the command-line version. The first
element in the array tells config what to do. Possible values are:
* `set`
Sets a config parameter. The second element in `args` is interpreted as the
key, and the third element is interpreted as the value.
* `get`
Gets the value of a config parameter. The second element in `args` is the
key to get the value of.
* `delete` (`rm` or `del`)
Deletes a parameter from the config. The second element in `args` is the
key to delete.
* `list` (`ls`)
Show all configs that aren't secret. No parameters necessary.
* `edit`:
Opens the config file in the default editor. This command isn't very useful
programmatically, but it is made available.
To programmatically access npm configuration settings, or set them for
the duration of a program, use the `npm.config.set` and `npm.config.get`
functions instead.
## SEE ALSO
* npm(3)

32
deps/npm/doc/api/deprecate.md vendored Normal file
View File

@ -0,0 +1,32 @@
npm-deprecate(3) -- Deprecate a version of a package
====================================================
## SYNOPSIS
npm.commands.deprecate(args, callback)
## DESCRIPTION
This command will update the npm registry entry for a package, providing
a deprecation warning to all who attempt to install it.
The 'args' parameter must have exactly two elements:
* `package[@version]`
The `version` portion is optional, and may be either a range, or a
specific version, or a tag.
* `message`
The warning message that will be printed whenever a user attempts to
install the package.
Note that you must be the package owner to deprecate something. See the
`owner` and `adduser` help topics.
## SEE ALSO
* npm-publish(3)
* npm-unpublish(3)
* npm-registry(1)

19
deps/npm/doc/api/docs.md vendored Normal file
View File

@ -0,0 +1,19 @@
npm-docs(3) -- Docs for a package in a web browser maybe
========================================================
## SYNOPSIS
npm.commands.docs(package, callback)
## DESCRIPTION
This command tries to guess at the likely location of a package's
documentation URL, and then tries to open it using the `--browser`
config param.
Like other commands, the first parameter is an array. This command only
uses the first element, which is expected to be a package name with an
optional version number.
This command will launch a browser, so this command may not be the most
friendly for programmatic use.

24
deps/npm/doc/api/edit.md vendored Normal file
View File

@ -0,0 +1,24 @@
npm-edit(3) -- Edit an installed package
========================================
## SYNOPSIS
npm.commands.edit(package, callback)
## DESCRIPTION
Opens the package folder in the default editor (or whatever you've
configured as the npm `editor` config -- see `npm help config`.)
After it has been edited, the package is rebuilt so as to pick up any
changes in compiled packages.
For instance, you can do `npm install connect` to install connect
into your package, and then `npm.commands.edit(["connect"], callback)`
to make a few changes to your locally installed copy.
The first parameter is a string array with a single element, the package
to open. The package can optionally have a version number attached.
Since this command opens an editor in a new process, be careful about where
and how this is used.

18
deps/npm/doc/api/explore.md vendored Normal file
View File

@ -0,0 +1,18 @@
npm-explore(3) -- Browse an installed package
=============================================
## SYNOPSIS
npm.commands.explore(args, callback)
## DESCRIPTION
Spawn a subshell in the directory of the installed package specified.
If a command is specified, then it is run in the subshell, which then
immediately terminates.
Note that the package is *not* automatically rebuilt afterwards, so be
sure to use `npm rebuild <pkg>` if you make any changes.
The first element in the 'args' 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.

1
deps/npm/doc/api/find.md vendored Symbolic link
View File

@ -0,0 +1 @@
ls.md

1
deps/npm/doc/api/get.md vendored Symbolic link
View File

@ -0,0 +1 @@
config.md

30
deps/npm/doc/api/help-search.md vendored Normal file
View File

@ -0,0 +1,30 @@
npm-help-search(3) -- Search the help pages
===========================================
## SYNOPSIS
npm.commands.helpSearch(args, [silent,] callback)
## DESCRIPTION
This command is rarely useful, but it exists in the rare case that it is.
This command takes an array of search terms and returns the help pages that
match in order of best match.
If there is only one match, then npm displays that help section. If there
are multiple results, the results are printed to the screen formatted and the
array of results is returned. Each result is an object with these properties:
* hits:
A map of args to number of hits on that arg. For example, {"npm": 3}
* found:
Total number of unique args that matched.
* totalHits:
Total number of hits.
* lines:
An array of all matching lines (and some adjacent lines).
* file:
Name of the file that matched
The silent parameter is not neccessary not used, but it may in the future.

1
deps/npm/doc/api/home.md vendored Symbolic link
View File

@ -0,0 +1 @@
docs.md

29
deps/npm/doc/api/init.md vendored Normal file
View File

@ -0,0 +1,29 @@
npm init(3) -- Interactively create a package.json file
=======================================================
## SYNOPSIS
npm.commands.init(args, callback)
## DESCRIPTION
This will ask you a bunch of questions, and then write a package.json for you.
It attempts to make reasonable guesses about what you want things to be set to,
and then writes a package.json file with the options you've selected.
If you already have a package.json file, it'll read that first, and default to
the options in there.
It is strictly additive, so it does not delete options from your package.json
without a really good reason to do so.
Since this function expects to be run on the command-line, it doesn't work very
well as a programmatically. The best option is to roll your own, and since
JavaScript makes it stupid simple to output formatted JSON, that is the
preferred method. If you're sure you want to handle command-line prompting,
then go ahead and use this programmatically.
## SEE ALSO
npm-json(1)

19
deps/npm/doc/api/install.md vendored Normal file
View File

@ -0,0 +1,19 @@
npm-install(3) -- install a package programmatically
====================================================
## SYNOPSIS
npm.commands.install([where,] packages, callback)
## DESCRIPTION
This acts much the same ways as installing on the command-line.
The 'where' parameter is optional and only used internally, and it specifies
where the packages should be installed to.
The 'packages' parameter is an array of strings. Each element in the array is
the name of a package to be installed.
Finally, 'callback' is a function that will be called when all packages have been
installed or when an error has been encountered.

33
deps/npm/doc/api/link.md vendored Normal file
View File

@ -0,0 +1,33 @@
npm-link(3) -- Symlink a package folder
=======================================
## SYNOPSIS
npm.command.link(callback)
npm.command.link(packages, callback)
## DESCRIPTION
Package linking is a two-step process.
Without parameters, link will create a globally-installed
symbolic link from `prefix/package-name` to the current folder.
With a parameters, link will create a symlink from the local `node_modules`
folder to the global symlink.
When creating tarballs for `npm publish`, the linked packages are
"snapshotted" to their current state by resolving the symbolic links.
This is
handy for installing your own stuff, so that you can work on it and test it
iteratively without having to continually rebuild.
For example:
npm.commands.link(cb) # creates global link from the cwd
# (say redis package)
npm.commands.link('redis', cb) # link-install the package
Now, any changes to the redis package will be reflected in
the package in the current working directory

1
deps/npm/doc/api/list.md vendored Symbolic link
View File

@ -0,0 +1 @@
ls.md

1
deps/npm/doc/api/ln.md vendored Symbolic link
View File

@ -0,0 +1 @@
link.md

26
deps/npm/doc/api/load.md vendored Normal file
View File

@ -0,0 +1,26 @@
npm-load(3) -- Load config settings
===================================
## SYNOPSIS
npm.load(conf, cb)
## DESCRIPTION
npm.load() must be called before any other function call. Both parameters are
optional, but the second is recommended.
The first parameter is an object hash of command-line config params, and the
second parameter is a callback that will be called when npm is loaded and
ready to serve.
The first parameter should follow a similar structure as the package.json
config object.
For example, to emulate the --dev flag, pass an object that looks like this:
{
"dev": true
}
For a list of all the available command-line configs, see `npm help config`

50
deps/npm/doc/api/ls.md vendored Normal file
View File

@ -0,0 +1,50 @@
npm-ls(3) -- List installed packages
======================================
## SYNOPSIS
npm.commands.ls(args, [silent,] callback)
## DESCRIPTION
This command will print to stdout all the versions of packages that are
installed, as well as their dependencies, in a tree-structure. It will also
return that data using the callback.
This command does not take any arguments, but args must be defined.
Beyond that, if any arguments are passed in, npm will politely warn that it
does not take positional arguments, though you may set config flags
like with any other command, such as `global` to list global packages.
It will print out extraneous, missing, and invalid packages.
If the silent parameter is set to true, nothing will be output to the screen,
but the data will still be returned.
## CONFIGURATION
### long
* Default: false
* Type: Boolean
Show extended information.
### parseable
* Default: false
* Type: Boolean
Show parseable output instead of tree view.
### global
* Default: false
* Type: Boolean
List packages in the global install prefix instead of in the current
project.
Note, if parseable is set or long isn't set, then duplicates will be trimmed.
This means that if a submodule a same dependency as a parent module, then the
dependency will only be output once.

115
deps/npm/doc/api/npm.md vendored Normal file
View File

@ -0,0 +1,115 @@
npm(3) -- node package manager
==============================
## SYNOPSIS
var npm = require("npm")
npm.load(configObject, function (er, npm) {
// use the npm object, now that it's loaded.
npm.config.set(key, val)
val = npm.config.get(key)
console.log("prefix = %s", npm.prefix)
npm.commands.install(["package"], cb)
})
## VERSION
@VERSION@
## DESCRIPTION
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.
After that, each of the functions are accessible in the
commands object: `npm.commands.<cmd>`. See `npm-index(1)` for a list of
all possible commands.
All commands on the command object take an **array** of positional argument
**strings**. The last argument to any function is a callback. Some
commands take other optional arguments.
Configs cannot currently be set on a per function basis, as each call to
npm.config.set will change the value for *all* npm commands in that process.
To find API documentation for a specific command, run the `npm apihelp`
command.
## METHODS AND PROPERTIES
* `npm.load(configs, cb)`
Load the configuration params, and call the `cb` function once the
globalconfig and userconfig files have been loaded as well, or on
nextTick if they've already been loaded.
* `npm.config`
An object for accessing npm configuration parameters.
* `npm.config.get(key)`
* `npm.config.set(key, val)`
* `npm.config.del(key)`
* `npm.dir` or `npm.root`
The `node_modules` directory where npm will operate.
* `npm.prefix`
The prefix where npm is operating. (Most often the current working
directory.)
* `npm.cache`
The place where npm keeps JSON and tarballs it fetches from the
registry (or uploads to the registry).
* `npm.tmp`
npm's temporary working directory.
* `npm.deref`
Get the "real" name for a command that has either an alias or
abbreviation.
## MAGIC
For each of the methods in the `npm.commands` hash, a method is added to
the npm object, which takes a set of positional string arguments rather
than an array and a callback.
If the last argument is a callback, then it will use the supplied
callback. However, if no callback is provided, then it will print out
the error or results.
For example, this would work in a node repl:
> npm = require("npm")
> npm.load() // wait a sec...
> npm.install("dnode", "express")
Note that that *won't* work in a node program, since the `install`
method will get called before the configuration load is completed.
## ABBREVS
In order to support `npm ins foo` instead of `npm install foo`, the
`npm.commands` object has a set of abbreviations as well as the full
method names. Use the `npm.deref` method to find the real name.
For example:
var cmd = npm.deref("unp") // cmd === "unpublish"

13
deps/npm/doc/api/outdated.md vendored Normal file
View File

@ -0,0 +1,13 @@
npm-outdated(3) -- Check for outdated packages
==============================================
## SYNOPSIS
npm.commands.outdated([packages,] callback)
## DESCRIPTION
This command will check the registry to see if the specified packages are
currently outdated.
If the 'packages' parameter is left out, npm will check all packages.

31
deps/npm/doc/api/owner.md vendored Normal file
View File

@ -0,0 +1,31 @@
npm-owner(3) -- Manage package owners
=====================================
## SYNOPSIS
npm.commands.owner(args, callback)
## DESCRIPTION
The first element of the 'args' parameter defines what to do, and the subsequent
elements depend on the action. Possible values for the action are (order of
parameters are given in parenthesis):
* ls (package):
List all the users who have access to modify a package and push new versions.
Handy when you need to know who to bug for help.
* add (user, package):
Add a new user as a maintainer of a package. This user is enabled to modify
metadata, publish new versions, and add other owners.
* rm (user, package):
Remove a user from the package owner list. This immediately revokes their
privileges.
Note that there is only one level of access. Either you can modify a package,
or you can't. Future versions may contain more fine-grained access levels, but
that is not implemented at this time.
## SEE ALSO
* npm-publish(3)
* npm-registry(1)

19
deps/npm/doc/api/pack.md vendored Normal file
View File

@ -0,0 +1,19 @@
npm-pack(3) -- Create a tarball from a package
==============================================
## SYNOPSIS
npm.commands.pack([packages,] callback)
## DESCRIPTION
For anything that's installable (that is, a package folder, tarball,
tarball url, name@tag, name@version, or name), this command will fetch
it to the cache, and then copy the tarball to the current working
directory as `<name>-<version>.tgz`, and then write the filenames out to
stdout.
If the same package is specified multiple times, then the file will be
overwritten the second time.
If no arguments are supplied, then npm packs the current package folder.

15
deps/npm/doc/api/prefix.md vendored Normal file
View File

@ -0,0 +1,15 @@
npm-prefix(3) -- Display prefix
===============================
## SYNOPSIS
npm.commands.prefix(args, callback)
## DESCRIPTION
Print the prefix to standard out.
'args' is never used and callback is never called with data.
'args' must be present or things will break.
This function is not useful programmatically

17
deps/npm/doc/api/prune.md vendored Normal file
View File

@ -0,0 +1,17 @@
npm-prune(3) -- Remove extraneous packages
==========================================
## SYNOPSIS
npm.commands.prune([packages,] callback)
## DESCRIPTION
This command removes "extraneous" packages.
The first parameter is optional, and it specifies packages to be removed.
No packages are specified, then all packages will be checked.
Extraneous packages are packages that are not listed on the parent
package's dependencies list.

30
deps/npm/doc/api/publish.md vendored Normal file
View File

@ -0,0 +1,30 @@
npm-publish(3) -- Publish a package
===================================
## SYNOPSIS
npm.commands.publish([packages,] callback)
## DESCRIPTION
Publishes a package to the registry so that it can be installed by name.
Possible values in the 'packages' array are:
* `<folder>`:
A folder containing a package.json file
* `<tarball>`:
A url or file path to a gzipped tar archive containing a single folder
with a package.json file inside.
If the package array is empty, npm will try to publish something in the
current working directory.
This command could fails if one of the packages specified already exists in
the registry. Overwrites when the "force" environment variable is set.
## SEE ALSO
* npm-registry(1)
* npm-adduser(1)
* npm-owner(3)

16
deps/npm/doc/api/rebuild.md vendored Normal file
View File

@ -0,0 +1,16 @@
npm-rebuild(3) -- Rebuild a package
===================================
## SYNOPSIS
npm.commands.rebuild([packages,] callback)
## DESCRIPTION
This command runs the `npm build` command on each of the matched packages. This is useful
when you install a new version of node, and must recompile all your C++ addons with
the new binary. If no 'packages' parameter is specify, every package will be rebuilt.
## CONFIGURATION
See `npm help build`

22
deps/npm/doc/api/restart.md vendored Normal file
View File

@ -0,0 +1,22 @@
npm-restart(3) -- Start a package
=================================
## SYNOPSIS
npm.commands.restart(packages, callback)
## DESCRIPTION
This runs a package's "restart" script, if one was provided.
Otherwise it runs package's "stop" script, if one was provided, and then
the "start" script.
If no version is specified, then it restarts the "active" version.
npm can run tests on multiple packages. Just specify multiple packages
in the `packages` parameter.
## SEE ALSO
* npm-start(3)
* npm-stop(3)

1
deps/npm/doc/api/rm.md vendored Symbolic link
View File

@ -0,0 +1 @@
uninstall.md

15
deps/npm/doc/api/root.md vendored Normal file
View File

@ -0,0 +1,15 @@
npm-root(3) -- Display npm root
===============================
## SYNOPSIS
npm.commands.root(args, callback)
## DESCRIPTION
Print the effective `node_modules` folder to standard out.
'args' is never used and callback is never called with data.
'args' must be present or things will break.
This function is not useful programmatically.

27
deps/npm/doc/api/run-script.md vendored Normal file
View File

@ -0,0 +1,27 @@
npm-run-script(3) -- Run arbitrary package scripts
==================================================
## SYNOPSIS
npm.commands.run-script(args, callback)
## DESCRIPTION
This runs an arbitrary command from a package's "scripts" object.
It is used by the test, start, restart, and stop commands, but can be
called directly, as well.
The 'args' parameter is an array of strings. Behavior depends on the number
of elements. If there is only one element, npm assumes that the element
represents a command to be run on the local repository. If there is more than
one element, then the first is assumed to be the package and the second is
assumed to be the command to run. All other elements are ignored.
## SEE ALSO
* npm-scripts(1)
* npm-test(3)
* npm-start(3)
* npm-restart(3)
* npm-stop(3)

35
deps/npm/doc/api/search.md vendored Normal file
View File

@ -0,0 +1,35 @@
npm-search(3) -- Search for packages
====================================
## SYNOPSIS
npm.commands.search(searchTerms, [silent,] [staleness,] callback)
## DESCRIPTION
Search the registry for packages matching the search terms. The available parameters are:
* searchTerms:
Array of search terms. These terms are case-insensitive.
* silent:
If true, npm will not log anything to the console.
* staleness:
This is the threshold for stale packages. "Fresh" packages are not refreshed
from the registry. This value is measured in seconds.
* callback:
Returns an object where each key is the name of a package, and the value
is information about that package along with a 'words' property, which is
a space-delimited string of all of the interesting words in that package.
The only properties included are those that are searched, which generally include:
* name
* description
* maintainers
* url
* keywords
A search on the registry excludes any result that does not match all of the
search terms. It also removes any items from the results that contain an
excluded term (the "searchexclude" config). The search is case insensitive
and doesn't try to read your mind (it doesn't do any verb tense matching or the
like).

1
deps/npm/doc/api/set.md vendored Symbolic link
View File

@ -0,0 +1 @@
config.md

13
deps/npm/doc/api/start.md vendored Normal file
View File

@ -0,0 +1,13 @@
npm-start(3) -- Start a package
===============================
## SYNOPSIS
npm.commands.start(packages, callback)
## DESCRIPTION
This runs a package's "start" script, if one was provided.
npm can run tests on multiple packages. Just specify multiple packages
in the `packages` parameter.

13
deps/npm/doc/api/stop.md vendored Normal file
View File

@ -0,0 +1,13 @@
npm-stop(3) -- Stop a package
=============================
## SYNOPSIS
npm.commands.stop(packages, callback)
## DESCRIPTION
This runs a package's "stop" script, if one was provided.
npm can run stop on multiple packages. Just specify multiple packages
in the `packages` parameter.

28
deps/npm/doc/api/submodule.md vendored Normal file
View File

@ -0,0 +1,28 @@
npm-submodule(3) -- Add a package as a git submodule
====================================================
## SYNOPSIS
npm.commands.submodule(packages, callback)
## DESCRIPTION
For each package specified, npm will check if it has a git repository url
in its package.json description then add it as a git submodule at
`node_modules/<pkg name>`.
This is a convenience only. From then on, it's up to you to manage
updates by using the appropriate git commands. npm will stubbornly
refuse to update, modify, or remove anything with a `.git` subfolder
in it.
This command also does not install missing dependencies, if the package
does not include them in its git repository. If `npm ls` reports that
things are missing, you can either install, link, or submodule them yourself,
or you can do `npm explore <pkgname> -- npm install` to install the
dependencies into the submodule folder.
## SEE ALSO
* npm help json
* git help submodule

23
deps/npm/doc/api/tag.md vendored Normal file
View File

@ -0,0 +1,23 @@
npm-tag(3) -- Tag a published version
=====================================
## SYNOPSIS
npm.commands.tag(package@version, tag, callback)
## DESCRIPTION
Tags the specified version of the package with the specified tag, or the
`--tag` config if not specified.
The 'package@version' is an array of strings, but only the first two elements are
currently used.
The first element must be in the form package@version, where package
is the package name and version is the version number (much like installing a
specific version).
The second element is the name of the tag to tag this version with. If this
parameter is missing or falsey (empty), the default froom the config will be
used. For more information about how to set this config, check
`man 3 npm-config` for programmatic usage or `man npm-config` for cli usage.

16
deps/npm/doc/api/test.md vendored Normal file
View File

@ -0,0 +1,16 @@
npm-test(3) -- Test a package
=============================
## SYNOPSIS
npm.commands.test(packages, callback)
## DESCRIPTION
This runs a package's "test" script, if one was provided.
To run tests as a condition of installation, set the `npat` config to
true.
npm can run tests on multiple packages. Just specify multiple packages
in the `packages` parameter.

16
deps/npm/doc/api/uninstall.md vendored Normal file
View File

@ -0,0 +1,16 @@
npm-uninstall(3) -- uninstall a package programmatically
========================================================
## SYNOPSIS
npm.commands.uninstall(packages, callback)
## DESCRIPTION
This acts much the same ways as uninstalling on the command-line.
The 'packages' parameter is an array of strings. Each element in the array is
the name of a package to be uninstalled.
Finally, 'callback' is a function that will be called when all packages have been
uninstalled or when an error has been encountered.

20
deps/npm/doc/api/unpublish.md vendored Normal file
View File

@ -0,0 +1,20 @@
npm-unpublish(3) -- Remove a package from the registry
======================================================
## SYNOPSIS
npm.commands.unpublish(package, callback)
## DESCRIPTION
This removes a package version from the registry, deleting its
entry and removing the tarball.
The package parameter must be defined.
Only the first element in the package parameter is used. If there is no first
element, then npm assumes that the package at the current working directory
is what is meant.
If no version is specified, or if all versions are removed then
the root package entry is removed from the registry entirely.

11
deps/npm/doc/api/update.md vendored Normal file
View File

@ -0,0 +1,11 @@
npm-update(3) -- Update a package
=================================
## SYNOPSIS
npm.commands.update(packages, callback)
# DESCRIPTION
Updates a package, upgrading it to the latest version. It also installs any missing packages.
The 'packages' argument is an array of packages to update. The 'callback' parameter will be called when done or when an error occurs.

18
deps/npm/doc/api/version.md vendored Normal file
View File

@ -0,0 +1,18 @@
npm-version(3) -- Bump a package version
========================================
## SYNOPSIS
npm.commands.version(newversion, callback)
## DESCRIPTION
Run this in a package directory to bump the version and write the new
data back to the package.json file.
If run in a git repo, it will also create a version commit and tag, and
fail if the repo is not clean.
Like all other commands, this function takes a string array as its first
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.

93
deps/npm/doc/api/view.md vendored Normal file
View File

@ -0,0 +1,93 @@
npm-view(3) -- View registry info
=================================
## SYNOPSIS
npm.commands.view(args, [silent,] callback)
## DESCRIPTION
This command shows data about a package and prints it to the stream
referenced by the `outfd` config, which defaults to stdout.
The "args" parameter is an ordered list that closely resembles the command-line
usage. The elements should be ordered such that the first element is
the package and version (package@version). The version is optional. After that,
the rest of the parameters are fields with optional subfields ("field.subfield")
which can be used to get only the information desired from the registry.
The callback will be passed all of the data returned by the query.
For example, to get the package registry entry for the `connect` package,
you can do this:
npm.commands.view(["connect"], callback)
If no version is specified, "latest" is assumed.
Field names can be specified after the package descriptor.
For example, to show the dependencies of the `ronn` package at version
0.3.5, you could do the following:
npm.commands.view(["ronn@0.3.5", "dependencies"], callback)
You can view child field by separating them with a period.
To view the git repository URL for the latest version of npm, you could
do this:
npm.commands.view(["npm", "repository.url"], callback)
For fields that are arrays, requesting a non-numeric field will return
all of the values from the objects in the list. For example, to get all
the contributor names for the "express" project, you can do this:
npm.commands.view(["express", "contributors.email"], callback)
You may also use numeric indices in square braces to specifically select
an item in an array field. To just get the email address of the first
contributor in the list, you can do this:
npm.commands.view(["express", "contributors[0].email"], callback)
Multiple fields may be specified, and will be printed one after another.
For exampls, to get all the contributor names and email addresses, you
can do this:
npm.commands.view(["express", "contributors.name", "contributors.email"], callback)
"Person" fields are shown as a string if they would be shown as an
object. So, for example, this will show the list of npm contributors in
the shortened string format. (See `npm help json` for more on this.)
npm.commands.view(["npm", "contributors"], callback)
If a version range is provided, then data will be printed for every
matching version of the package. This will show which version of jsdom
was required by each matching version of yui3:
npm.commands.view(["yui3@'>0.5.4'", "dependencies.jsdom"], callback)
## OUTPUT
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.
If the version range matches multiple versions, than each printed value
will be prefixed with the version it applies to.
If multiple fields are requested, than each of them are prefixed with
the field name.
Console output can be disabled by setting the 'silent' parameter to true.
## RETURN VALUE
The data returned will be an object in this formation:
{ <version>:
{ <field>: <value>
, ... }
, ... }
corresponding to the list of fields selected.

15
deps/npm/doc/api/whoami.md vendored Normal file
View File

@ -0,0 +1,15 @@
npm-whoami(3) -- Display npm username
=====================================
## SYNOPSIS
npm.commands.whoami(args, callback)
## DESCRIPTION
Print the `username` config to standard output.
'args' is never used and callback is never called with data.
'args' must be present or things will break.
This function is not useful programmatically

36
deps/npm/doc/cli/adduser.md vendored Normal file
View File

@ -0,0 +1,36 @@
npm-adduser(1) -- Add a registry user account
=============================================
## SYNOPSIS
npm adduser
## DESCRIPTION
Create or verify a user named `<username>` in the npm registry, and
save the credentials to the `.npmrc` file.
The username, password, and email are read in from prompts.
You may use this command to change your email address, but not username
or password.
To reset your password, go to <http://admin.npmjs.org/>
You may use this command multiple times with the same user account to
authorize on a new machine.
## CONFIGURATION
### registry
Default: http://registry.npmjs.org/
The base URL of the npm package registry.
## SEE ALSO
* npm-registry(1)
* npm-config(1)
* npm-owner(1)
* npm-whoami(1)

1
deps/npm/doc/cli/author.md vendored Symbolic link
View File

@ -0,0 +1 @@
owner.md

17
deps/npm/doc/cli/bin.md vendored Normal file
View File

@ -0,0 +1,17 @@
npm-bin(1) -- Display npm bin folder
====================================
## SYNOPSIS
npm bin
## DESCRIPTION
Print the folder where npm will install executables.
## SEE ALSO
* npm-prefix(1)
* npm-root(1)
* npm-folders(1)
* npm-config(1)

38
deps/npm/doc/cli/bugs.md vendored Normal file
View File

@ -0,0 +1,38 @@
npm-bugs(1) -- Bugs for a package in a web browser maybe
========================================================
## SYNOPSIS
npm bugs <pkgname>
## DESCRIPTION
This command tries to guess at the likely location of a package's
bug tracker URL, and then tries to open it using the `--browser`
config param.
## CONFIGURATION
### browser
* Default: OS X: `"open"`, others: `"google-chrome"`
* Type: String
The browser that is called by the `npm bugs` command to open websites.
### registry
* Default: https://registry.npmjs.org/
* Type: url
The base URL of the npm package registry.
## SEE ALSO
* npm-docs(1)
* npm-view(1)
* npm-publish(1)
* npm-registry(1)
* npm-config(1)
* npm-json(1)

22
deps/npm/doc/cli/build.md vendored Normal file
View File

@ -0,0 +1,22 @@
npm-build(1) -- Build a package
===============================
## SYNOPSIS
npm build <package-folder>
* `<package-folder>`:
A folder containing a `package.json` file in its root.
## DESCRIPTION
This is the plumbing command called by `npm link` and `npm install`.
It should generally not be called directly.
## SEE ALSO
* npm-install(1)
* npm-link(1)
* npm-scripts(1)
* npm-json(1)

14
deps/npm/doc/cli/bundle.md vendored Normal file
View File

@ -0,0 +1,14 @@
npm-bundle(1) -- REMOVED
========================
## DESCRIPTION
The `npm bundle` command has been removed in 1.0, for the simple reason
that it is no longer necessary, as the default behavior is now to
install packages into the local space.
Just use `npm install` now to do what `npm bundle` used to do.
## SEE ALSO
* npm-install(1)

70
deps/npm/doc/cli/cache.md vendored Normal file
View File

@ -0,0 +1,70 @@
npm-cache(1) -- Manipulates packages cache
==========================================
## SYNOPSIS
npm cache add <tarball file>
npm cache add <folder>
npm cache add <tarball url>
npm cache add <name>@<version>
npm cache ls [<path>]
npm cache clean [<path>]
## DESCRIPTION
Used to add, list, or clear the npm cache folder.
* add:
Add the specified package to the local cache. This command is primarily
intended to be used internally by npm, but it can provide a way to
add data to the local installation cache explicitly.
* ls:
Show the data in the cache. Argument is a path to show in the cache
folder. Works a bit like the `find` program, but limited by the
`depth` config.
* clean:
Delete data out of the cache folder. If an argument is provided, then
it specifies a subpath to delete. If no argument is provided, then
the entire cache is cleared.
## DETAILS
npm stores cache data in `$HOME/.npm`. For each package that is added
to the cache, three pieces of information are stored in
`{cache}/{name}/{version}`:
* .../package/:
A folder containing the package contents as they appear in the tarball.
* .../package.json:
The package.json file, as npm sees it, with overlays applied and a _id attribute.
* .../package.tgz:
The tarball for that version.
Additionally, whenever a registry request is made, a `.cache.json` file
is placed at the corresponding URI, to store the ETag and the requested
data.
Commands that make non-essential registry requests (such as `search` and
`view`, or the completion scripts) generally specify a minimum timeout.
If the `.cache.json` file is younger than the specified timeout, then
they do not make an HTTP request to the registry.
## CONFIGURATION
### cache
Default: `$HOME/.npm` on Posix, or `$HOME/npm-cache` on Windows.
The root cache folder.
## SEE ALSO
* npm-folders(1)
* npm-config(1)
* npm-install(1)
* npm-publish(1)
* npm-pack(1)

36
deps/npm/doc/cli/changelog.md vendored Normal file
View File

@ -0,0 +1,36 @@
npm-changelog(1) -- Changes
===========================
## HISTORY
### 1.0
* Greatly simplified folder structure
* Install locally (bundle by default)
* Drastic rearchitecture
### 0.3
* More correct permission/uid handling when running as root
* Require node 0.4.0
* Reduce featureset
* Packages without "main" modules don't export modules
* Remove support for invalid JSON (since node doesn't support it)
### 0.2
* First allegedly "stable" release
* Most functionality implemented
* Used shim files and `name@version` symlinks
* Feature explosion
* Kind of a mess
### 0.1
* push to beta, and announce
* Solaris and Cygwin support
### 0.0
* Lots of sketches and false starts; abandoned a few times
* Core functionality established
## SEE ALSO
* npm(1)
* npm-faq(1)

190
deps/npm/doc/cli/coding-style.md vendored Normal file
View File

@ -0,0 +1,190 @@
npm-coding-style(1) -- npm's "funny" coding style
=================================================
## DESCRIPTION
npm's coding style is a bit unconventional. It is not different for
difference's sake, but rather a carefully crafted style that is
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.
## Line Length
Keep lines shorter than 80 characters. It's better for lines to be
too short than to be too long. Break up long lists, objects, and other
statements onto multiple lines.
## Indentation
Two-spaces. Tabs are better, but they look like hell in web browsers
(and on github), and node uses 2 spaces, so that's that.
Configure your editor appropriately.
## Curly braces
Curly braces belong on the same line as the thing that necessitates them.
Bad:
function ()
{
Good:
function () {
If a block needs to wrap to the next line, use a curly brace. Don't
use it if it doesn't.
Bad:
if (foo) { bar() }
while (foo)
bar()
Good:
if (foo) bar()
while (foo) {
bar()
}
## Semicolons
Don't use them except in four situations:
* `for (;;)` loops. They're actually required.
* null loops like: `while (something) ;` (But you'd better have a good
reason for doing that.)
* case "foo": doSomething(); break
* In front of a leading ( or [ at the start of the line.
This prevents the expression from being interpreted
as a function call or property access, respectively.
Some examples of good semicolon usage:
;(x || y).doSomething()
;[a, b, c].forEach(doSomething)
for (var i = 0; i < 10; i ++) {
switch (state) {
case "begin": start(); continue
case "end": finish(); break
default: throw new Error("unknown state")
}
end()
}
Note that starting lines with `-` and `+` also should be prefixed
with a semicolon, but this is much less common.
## Comma First
If there is a list of things separated by commas, and it wraps
across multiple lines, put the comma at the start of the next
line, directly below the token that starts the list. Put the
final token in the list on a line by itself. For example:
var magicWords = [ "abracadabra"
, "gesundheit"
, "ventrilo"
]
, spells = { "fireball" : function () { setOnFire() }
, "water" : function () { putOut() }
}
, a = 1
, b = "abc"
, etc
, somethingElse
## Whitespace
Put a single space in front of ( for anything other than a function call.
Also use a single space wherever it makes things more readable.
Don't leave trailing whitespace at the end of lines. Don't indent empty
lines. Don't use more spaces than are helpful.
## Functions
Use named functions. They make stack traces a lot easier to read.
## Callbacks, Sync/async Style
Use the asynchronous/non-blocking versions of things as much as possible.
It might make more sense for npm to use the synchronous fs APIs, but this
way, the fs and http and child process stuff all uses the same callback-passing
methodology.
The callback should always be the last argument in the list. Its first
argument is the Error or null.
Be very careful never to ever ever throw anything. It's worse than useless.
Just send the error message back as the first argument to the callback.
## Errors
Always create a new Error object with your message. Don't just return a
string message to the callback. Stack traces are handy.
Use the `require("./utils/log").er` function. It takes a callback and an
error message, and returns an object that will report the message in the
event of a failure. It's quite handy.
function myThing (args, cb) {
getData(args, function (er, data) {
if (er) return log.er(cb, "Couldn't get data")(er)
doSomethingElse(data, cb)
})
}
function justHasToWork (cb) {
doSomething(log.er(cb, "the doSomething failed."))
}
## Logging
Please clean up logs when they are no longer helpful. In particular,
logging the same object over and over again is not helpful. Logs should
report what's happening so that it's easier to track down where a fault
occurs.
Use appropriate log levels. The default log() function logs at the
"info" level. See `npm-config(1)` and search for "loglevel".
## Case, naming, etc.
Use lowerCamelCase for multiword identifiers when they refer to objects,
functions, methods, members, or anything not specified in this section.
Use UpperCamelCase for class names (things that you'd pass to "new").
Use all-lower-hyphen-css-case for multiword filenames and config keys.
Use named functions. They make stack traces easier to follow.
Use CAPS_SNAKE_CASE for constants, things that should never change
and are rarely used.
Use a single uppercase letter for function names where the function
would normally be anonymous, but needs to call itself recursively. It
makes it clear that it's a "throwaway" function.
## null, undefined, false, 0
Boolean variables and functions should always be either `true` or
`false`. Don't set it to 0 unless it's supposed to be a number.
When something is intentionally missing or removed, set it to `null`.
Don't set things to `undefined`. Reserve that value to mean "not yet
set to anything."
Boolean objects are verboten.
## SEE ALSO
* npm-developers(1)
* npm-faq(1)
* npm(1)

29
deps/npm/doc/cli/completion.md vendored Normal file
View File

@ -0,0 +1,29 @@
npm-completion(1) -- Tab Completion for npm
===========================================
## SYNOPSIS
. <(npm completion)
## DESCRIPTION
Enables tab-completion in all npm commands.
The synopsis above
loads the completions into your current shell. Adding it to
your ~/.bashrc or ~/.zshrc will make the completions available
everywhere.
You may of course also pipe the output of npm completion to a file
such as `/usr/local/etc/bash_completion.d/npm` if you have a system
that will read that file for you.
When `COMP_CWORD`, `COMP_LINE`, and `COMP_POINT` are defined in the
environment, `npm completion` acts in "plumbing mode", and outputs
completions based on the arguments.
## SEE ALSO
* npm-developers(1)
* npm-faq(1)
* npm(1)

665
deps/npm/doc/cli/config.md vendored Normal file
View File

@ -0,0 +1,665 @@
npm-config(1) -- Manage the npm configuration file
==================================================
## SYNOPSIS
npm config set <key> <value> [--global]
npm config get <key>
npm config delete <key>
npm config list
npm config edit
npm get <key>
npm set <key> <value> [--global]
## DESCRIPTION
npm gets its configuration values from 6 sources, in this priority:
### Command Line Flags
Putting `--foo bar` on the command line sets the
`foo` configuration parameter to `"bar"`. A `--` argument tells the cli
parser to stop reading flags. A `--flag` parameter that is at the *end* of
the command will be given the value of `true`.
### Environment Variables
Any environment variables that start with `npm_config_` will be interpreted
as a configuration parameter. For example, putting `npm_config_foo=bar` in
your environment will set the `foo` configuration parameter to `bar`. Any
environment configurations that are not given a value will be given the value
of `true`. Config values are case-insensitive, so `NPM_CONFIG_FOO=bar` will
work the same.
### Per-user config file
`$HOME/.npmrc` (or the `userconfig` param, if set above)
This file is an ini-file formatted list of `key = value` parameters.
### 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
### Built-in config file
`path/to/npm/itself/npmrc`
This is an unchangeable "builtin"
configuration file that npm keeps consistent across updates. Set
fields in here using the `./configure` script that comes with npm.
This is primarily for distribution maintainers to override default
configs in a standard and consistent manner.
### Default Configs
A set of configuration parameters that are internal to npm, and are
defaults if nothing else is specified.
## Sub-commands
Config supports the following sub-commands:
### set
npm config set key value
Sets the config key to the value.
If value is omitted, then it sets it to "true".
### get
npm config get key
Echo the config value to stdout.
### list
npm config list
Show all the config settings.
### delete
npm config delete key
Deletes the key from all configuration files.
### edit
npm config edit
Opens the config file in an editor. Use the `--global` flag to edit the
global config.
## Shorthands and Other CLI Niceties
The following shorthands are parsed on the command-line:
* `-v`: `--version`
* `-h`, `-?`, `--help`, `-H`: `--usage`
* `-s`, `--silent`: `--loglevel silent`
* `-d`: `--loglevel info`
* `-dd`, `--verbose`: `--loglevel verbose`
* `-ddd`: `--loglevel silly`
* `-g`: `--global`
* `-l`: `--long`
* `-m`: `--message`
* `-p`, `--porcelain`: `--parseable`
* `-reg`: `--registry`
* `-v`: `--version`
* `-f`: `--force`
* `-l`: `--long`
* `-desc`: `--description`
* `-S`: `--save`
* `-y`: `--yes`
* `-n`: `--yes false`
* `ll` and `la` commands: `ls --long`
If the specified configuration param resolves unambiguously to a known
configuration parameter, then it is expanded to that configuration
parameter. For example:
npm ls --par
# same as:
npm ls --parseable
If multiple single-character shorthands are strung together, and the
resulting combination is unambiguously not some other configuration
param, then it is expanded to its various component pieces. For
example:
npm ls -gpld
# same as:
npm ls --global --parseable --long --loglevel info
## Per-Package Config Settings
When running scripts (see `npm-scripts(1)`)
the package.json "config" keys are overwritten in the environment if
there is a config param of `<name>[@<version>]:<key>`. For example, if
the package.json has this:
{ "name" : "foo"
, "config" : { "port" : "8080" }
, "scripts" : { "start" : "node server.js" } }
and the server.js is this:
http.createServer(...).listen(process.env.npm_package_config_port)
then the user could change the behavior by doing:
npm config set foo:port 80
## Config Settings
### always-auth
* Default: false
* Type: Boolean
Force npm to always require authentication when accessing the registry,
even for `GET` requests.
### bin-publish
* Default: false
* Type: Boolean
If set to true, then binary packages will be created on publish.
This is the way to opt into the "bindist" behavior described below.
### bindist
* Default: Unstable node versions, `null`, otherwise
`"<node version>-<platform>-<os release>"`
* Type: String or `null`
Experimental: on stable versions of node, binary distributions will be
created with this tag. If a user then installs that package, and their
`bindist` tag is found in the list of binary distributions, they will
get that prebuilt version.
Pre-build node packages have their preinstall, install, and postinstall
scripts stripped (since they are run prior to publishing), and do not
have their `build` directories automatically ignored.
It's yet to be seen if this is a good idea.
### browser
* Default: OS X: `"open"`, others: `"google-chrome"`
* Type: String
The browser that is called by the `npm docs` command to open websites.
### ca
* Default: The npm CA certificate
* Type: String or null
The Certificate Authority signing certificate that is trusted for SSL
connections to the registry.
Set to `null` to only allow "known" registrars, or to a specific CA cert
to trust only that specific signing authority.
See also the `strict-ssl` config.
### cache
* Default: Windows: `~/npm-cache`, Posix: `~/.npm`
* Type: path
The location of npm's cache directory. See `npm-cache(1)`
### color
* Default: true on Posix, false on Windows
* Type: Boolean or `"always"`
If false, never shows colors. If `"always"` then always shows colors.
If true, then only prints color codes for tty file descriptors.
### depth
* Default: Infinity
* Type: Number
The depth to go when recursing directories for `npm ls` and
`npm cache ls`.
### description
* Default: true
* Type: Boolean
Show the description in `npm search`
### dev
* Default: false
* Type: Boolean
Install `dev-dependencies` along with packages.
Note that `dev-dependencies` are also installed if the `npat` flag is
set.
### editor
* Default: `EDITOR` environment variable if set, or `"vi"` on Posix,
or `"notepad"` on Windows.
* Type: path
The command to run for `npm edit` or `npm config edit`.
### force
* Default: false
* Type: Boolean
Makes various commands more forceful.
* lifecycle script failure does not block progress.
* publishing clobbers previously published versions.
* skips cache when requesting from the registry.
* prevents checks against clobbering non-npm files.
### global
* Default: false
* Type: Boolean
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
current working directory.
* bin files are linked to `prefix/bin`
* man pages are linked to `prefix/share/man`
### globalconfig
* Default: {prefix}/etc/npmrc
* Type: path
The config file to read for global config options.
### globalignorefile
* Default: {prefix}/etc/npmignore
* Type: path
The config file to read for global ignore patterns to apply to all users
and all projects.
If not found, but there is a "gitignore" file in the
same directory, then that will be used instead.
### group
* Default: GID of the current process
* Type: String or Number
The group to use when running package scripts in global mode as the root
user.
### https-proxy
* Default: the `HTTPS_PROXY` or `https_proxy` or `HTTP_PROXY` or
`http_proxy` environment variables.
* Type: url
A proxy to use for outgoing https requests.
### ignore
* Default: ""
* Type: string
A white-space separated list of glob patterns of files to always exclude
from packages when building tarballs.
### init.version
* Default: "0.0.0"
* Type: semver
The value `npm init` should use by default for the package version.
### init.author.name
* Default: "0.0.0"
* Type: String
The value `npm init` should use by default for the package author's name.
### init.author.email
* Default: ""
* Type: String
The value `npm init` should use by default for the package author's email.
### init.author.url
* Default: ""
* Type: String
The value `npm init` should use by default for the package author's homepage.
### link
* Default: false
* Type: Boolean
If true, then local installs will link if there is a suitable globally
installed package.
Note that this means that local installs can cause things to be
installed into the global space at the same time. The link is only done
if one of the two conditions are met:
* The package is not already installed globally, or
* the globally installed version is identical to the version that is
being installed locally.
### logfd
* Default: stderr file descriptor
* Type: Number or Stream
The location to write log output.
### loglevel
* Default: "warn"
* Type: String
* Values: "silent", "win", "error", "warn", "info", "verbose", "silly"
What level of logs to report. On failure, *all* logs are written to
`npm-debug.log` in the current working directory.
### logprefix
* Default: true on Posix, false on Windows
* Type: Boolean
Whether or not to prefix log messages with "npm" and the log level. See
also "color" and "loglevel".
### long
* Default: false
* Type: Boolean
Show extended information in `npm ls`
### message
* Default: "%s"
* Type: String
Commit message which is used by `npm version` when creating version commit.
Any "%s" in the message will be replaced with the version number.
### node-version
* Default: process.version
* Type: semver or false
The node version to use when checking package's "engines" hash.
### npat
* Default: false
* Type: Boolean
Run tests on installation and report results to the
`npaturl`.
### npaturl
* Default: Not yet implemented
* Type: url
The url to report npat test results.
### onload-script
* Default: false
* Type: path
A node module to `require()` when npm loads. Useful for programmatic
usage.
### outfd
* Default: standard output file descriptor
* Type: Number or Stream
Where to write "normal" output. This has no effect on log output.
### parseable
* Default: false
* Type: Boolean
Output parseable results from commands that write to
standard output.
### prefix
* Default: node's process.installPrefix
* Type: path
The location to install global items. If set on the command line, then
it forces non-global commands to run in the specified folder.
### production
* Default: false
* Type: Boolean
Set to true to run in "production" mode.
1. devDependencies are not installed at the topmost level when running
local `npm install` without any arguments.
2. Set the NODE_ENV="production" for lifecycle scripts.
### proxy
* Default: `HTTP_PROXY` or `http_proxy` environment variable, or null
* Type: url
A proxy to use for outgoing http requests.
### rebuild-bundle
* Default: true
* Type: Boolean
Rebuild bundled dependencies after installation.
### registry
* Default: https://registry.npmjs.org/
* Type: url
The base URL of the npm package registry.
### rollback
* Default: true
* Type: Boolean
Remove failed installs.
### save
* Default: false
* Type: Boolean
Save installed packages to a package.json file as dependencies.
Only works if there is already a package.json file present.
### searchopts
* Default: ""
* Type: String
Space-separated options that are always passed to search.
### searchexclude
* Default: ""
* Type: String
Space-separated options that limit the results from search.
### shell
* Default: SHELL environment variable, or "bash" on Posix, or "cmd" on
Windows
* Type: path
The shell to run for the `npm explore` command.
### strict-ssl
* Default: true
* Type: Boolean
Whether or not to do SSL key validation when making requests to the
registry via https.
See also the `ca` config.
### tag
* Default: latest
* Type: String
If you ask npm to install a package and don't tell it a specific version, then
it will install the specified tag.
Also the tag that is added to the package@version specified by the `npm
tag` command, if no explicit tag is given.
### tmp
* Default: TMPDIR environment variable, or "/tmp"
* Type: path
Where to store temporary files and folders. All temp files are deleted
on success, but left behind on failure for forensic purposes.
### unicode
* Default: true
* Type: Boolean
When set to true, npm uses unicode characters in the tree output. When
false, it uses ascii characters to draw trees.
### unsafe-perm
* Default: false if running as root, true otherwise
* Type: Boolean
Set to true to suppress the UID/GID switching when running package
scripts. If set explicitly to false, then installing as a non-root user
will fail.
### usage
* Default: false
* Type: Boolean
Set to show short usage output (like the -H output)
instead of complete help when doing `npm-help(1)`.
### user
* Default: "nobody"
* Type: String or Number
The UID to set to when running package scripts as root.
### username
* Default: null
* Type: String
The username on the npm registry. Set with `npm adduser`
### userconfig
* Default: ~/.npmrc
* Type: path
The location of user-level configuration settings.
### userignorefile
* Default: ~/.npmignore
* Type: path
The location of a user-level ignore file to apply to all packages.
If not found, but there is a .gitignore file in the same directory, then
that will be used instead.
### umask
* Default: 022
* Type: Octal numeric string
The "umask" value to use when setting the file creation mode on files
and folders.
Folders and executables are given a mode which is `0777` masked against
this value. Other files are given a mode which is `0666` masked against
this value. Thus, the defaults are `0755` and `0644` respectively.
### version
* Default: false
* Type: boolean
If true, output the npm version and exit successfully.
Only relevant when specified explicitly on the command line.
### viewer
* Default: "man" on Posix, "browser" on Windows
* Type: path
The program to use to view help content.
Set to `"browser"` to view html help content in the default web browser.
### yes
* Default: null
* Type: Boolean or null
If set to `null`, then prompt the user for responses in some
circumstances.
If set to `true`, then answer "yes" to any prompt. If set to `false`
then answer "no" to any prompt.
## SEE ALSO
* npm-folders(1)
* npm(1)

24
deps/npm/doc/cli/deprecate.md vendored Normal file
View File

@ -0,0 +1,24 @@
npm-deprecate(1) -- Deprecate a version of a package
====================================================
## SYNOPSIS
npm deprecate <name>[@<version>] <message>
## DESCRIPTION
This command will update the npm registry entry for a package, providing
a deprecation warning to all who attempt to install it.
It works on version ranges as well as specific versions, so you can do
something like this:
npm deprecate my-thing@"< 0.2.3" "critical bug fixed in v0.2.3"
Note that you must be the package owner to deprecate something. See the
`owner` and `adduser` help topics.
## SEE ALSO
* npm-publish(1)
* npm-registry(1)

172
deps/npm/doc/cli/developers.md vendored Normal file
View File

@ -0,0 +1,172 @@
npm-developers(1) -- Developer Guide
====================================
## DESCRIPTION
So, you've decided to use npm to develop (and maybe publish/deploy)
your project.
Fantastic!
There are a few things that you need to do above the simple steps
that your users will do to install your program.
## About These Documents
These are man pages. If you install npm, you should be able to
then do `man npm-thing` to get the documentation on a particular
topic, or `npm help thing` to see the same information.
## What is a `package`
A package is:
* a) a folder containing a program described by a package.json file
* b) a gzipped tarball containing (a)
* c) a url that resolves to (b)
* d) a `<name>@<version>` that is published on the registry with (c)
* e) a `<name>@<tag>` that points to (d)
* f) a `<name>` that has a "latest" tag satisfying (e)
Even if you never publish your package, you can still get a lot of
benefits of using npm if you just want to write a node program (a), and
perhaps if you also want to be able to easily install it elsewhere
after packing it up into a tarball (b).
## The package.json File
You need to have a `package.json` file in the root of your project to do
much of anything with npm. That is basically the whole interface.
See `npm-json(1)` for details about what goes in that file. At the very
least, you need:
* name:
This should be a string that identifies your project. Please do not
use the name to specify that it runs on node, or is in JavaScript.
You can use the "engines" field to explicitly state the versions of
node (or whatever else) that your program requires, and it's pretty
well assumed that it's javascript.
It does not necessarily need to match your github repository name.
So, `node-foo` and `bar-js` are bad names. `foo` or `bar` are better.
* version:
A semver-compatible version.
* engines:
Specify the versions of node (or whatever else) that your program
runs on. The node API changes a lot, and there may be bugs or new
functionality that you depend on. Be explicit.
* author:
Take some credit.
* scripts:
If you have a special compilation or installation script, then you
should put it in the `scripts` hash. You should definitely have at
least a basic smoke-test command as the "scripts.test" field.
See npm-scripts(1).
* main:
If you have a single module that serves as the entry point to your
program (like what the "foo" package gives you at require("foo")),
then you need to specify that in the "main" field.
* directories:
This is a hash of folders. The best ones to include are "lib" and
"doc", but if you specify a folder full of man pages in "man", then
they'll get installed just like these ones.
You can use `npm init` in the root of your package in order to get you
started with a pretty basic package.json file. See `npm-init(1)` for
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.
## Link Packages
`npm link` is designed to install a development package and see the
changes in real time without having to keep re-installing it. (You do
need to either re-link or `npm rebuild -g` to update compiled packages,
of course.)
More info at `npm-link(1)`.
## Before Publishing: Make Sure Your Package Installs and Works
**This is important.**
If you can not install it locally, you'll have
problems trying to publish it. Or, worse yet, you'll be able to
publish it, but you'll be publishing a broken or pointless package.
So don't do that.
In the root of your package, do this:
npm install . -g
That'll show you that it's working. If you'd rather just create a symlink
package that points to your working directory, then do this:
npm link
Use `npm ls -g` to see if it's there.
To test a local install, go into some other folder, and then do:
cd ../some-other-folder
npm install ../my-package
to install it locally into the node_modules folder in that other place.
Then go into the node-repl, and try using require("my-thing") to
bring in your module's main module.
## Create a User Account
Create a user with the adduser command. It works like this:
npm adduser
and then follow the prompts.
This is documented better in npm-adduser(1).
## Publish your package
This part's easy. IN the root of your folder, do this:
npm publish
You can give publish a url to a tarball, or a filename of a tarball,
or a path to a folder.
Note that pretty much **everything in that folder will be exposed**
by default. So, if you have secret stuff in there, use a `.npminclude`
or `.npmignore` file to list out the globs to include/ignore, or publish
from a fresh checkout.
## Brag about it
Send emails, write blogs, blab in IRC.
Tell the world how easy it is to install your program!
## SEE ALSO
* npm-faq(1)
* npm(1)
* npm-init(1)
* npm-json(1)
* npm-scripts(1)
* npm-publish(1)
* npm-adduser(1)
* npm-registry(1)

38
deps/npm/doc/cli/docs.md vendored Normal file
View File

@ -0,0 +1,38 @@
npm-docs(1) -- Docs for a package in a web browser maybe
========================================================
## SYNOPSIS
npm docs <pkgname>
npm home <pkgname>
## DESCRIPTION
This command tries to guess at the likely location of a package's
documentation URL, and then tries to open it using the `--browser`
config param.
## CONFIGURATION
### browser
* Default: OS X: `"open"`, others: `"google-chrome"`
* Type: String
The browser that is called by the `npm docs` command to open websites.
### registry
* Default: https://registry.npmjs.org/
* Type: url
The base URL of the npm package registry.
## SEE ALSO
* npm-view(1)
* npm-publish(1)
* npm-registry(1)
* npm-config(1)
* npm-json(1)

35
deps/npm/doc/cli/edit.md vendored Normal file
View File

@ -0,0 +1,35 @@
npm-edit(1) -- Edit an installed package
========================================
## SYNOPSIS
npm edit <name>[@<version>]
## DESCRIPTION
Opens the package folder in the default editor (or whatever you've
configured as the npm `editor` config -- see `npm-config(1)`.)
After it has been edited, the package is rebuilt so as to pick up any
changes in compiled packages.
For instance, you can do `npm install connect` to install connect
into your package, and then `npm edit connect` to make a few
changes to your locally installed copy.
## CONFIGURATION
### editor
* Default: `EDITOR` environment variable if set, or `"vi"` on Posix,
or `"notepad"` on Windows.
* Type: path
The command to run for `npm edit` or `npm config edit`.
## SEE ALSO
* npm-folders(1)
* npm-explore(1)
* npm-install(1)
* npm-config(1)

40
deps/npm/doc/cli/explore.md vendored Normal file
View File

@ -0,0 +1,40 @@
npm-explore(1) -- Browse an installed package
=============================================
## SYNOPSIS
npm explore <name>[@<version>] [ -- <cmd>]
## DESCRIPTION
Spawn a subshell in the directory of the installed package specified.
If a command is specified, then it is run in the subshell, which then
immediately terminates.
This is particularly handy in the case of git submodules in the
`node_modules` folder:
npm explore some-dependency -- git pull origin master
Note that the package is *not* automatically rebuilt afterwards, so be
sure to use `npm rebuild <pkg>` if you make any changes.
## CONFIGURATION
### shell
* Default: SHELL environment variable, or "bash" on Posix, or "cmd" on
Windows
* Type: path
The shell to run for the `npm explore` command.
## SEE ALSO
* npm-submodule(1)
* npm-folders(1)
* npm-edit(1)
* npm-rebuild(1)
* npm-build(1)
* npm-install(1)

223
deps/npm/doc/cli/faq.md vendored Normal file
View File

@ -0,0 +1,223 @@
npm-faq(1) -- Frequently Asked Questions
========================================
## Where can I find these docs in HTML?
<http://npmjs.org/doc/>, or run:
npm config set viewer browser
to open these documents in your default web browser rather than `man`.
## It didn't work.
That's not really a question.
## Why didn't it work?
I don't know yet.
Read the error output, and if you can't figure out what it means,
do what it says and post a bug with all the information it asks for.
## Where does npm put stuff?
See `npm-folders(1)`
tl;dr:
* Use the `npm root` command to see where modules go, and the `npm bin`
command to see where executables go
* Global installs are different from local installs. If you install
something with the `-g` flag, then its executables go in `npm bin -g`
and its modules go in `npm root -g`.
## How do I install something everywhere?
Install it globally by tacking `-g` or `--global` to the command.
## I installed something globally, but I can't `require()` it
Install it locally.
## I don't wanna.
Check out `npm link`. You might like it.
## No, I really want 0.x style 'everything global' style.
Ok, fine. Do this:
echo 'export NODE_PATH="'$(npm root -g)'"' >> ~/.bashrc
. ~/.bashrc
npm config set global true
This is not recommended.
Many things **will not work** if you do this. Make sure you read and
understand `npm-config(1)` and `npm-global(1)` before you complain
about things being broken.
When you realize what a mistake it was, do this to switch back:
npm config delete global --local
## If 'npm' is an acronym, why is it never capitalized?
Contrary to the belief of many, "npm" is not in fact an abbreviation for
"Node Package Manager". It is a recursive bacronymic abbreviation for
"npm is not an acronym". (If it was "ninaa", then it would be an
acronym, and thus incorrectly named.)
"NPM", however, *is* an acronym (more precisely, a capitonym) for the
National Association of Pastoral Musicians. You can learn more
about them at <http://npm.org/>.
In software, "NPM" is a non-parametric mapping utility written by
Chris Rorden. You can analyze pictures of brains with it. Learn more
about the (capitalized) NPM program at <http://www.cabiatl.com/mricro/npm/>.
The first seed that eventually grew into this flower was a bash utility
named "pm", which was a shortened descendent of "pkgmakeinst", a
bash function that was used to install various different things on different
platforms, most often using Yahoo's `yinst`. If `npm` was ever an
acronym for anything, it was `node pm` or maybe `new pm`.
So, in all seriousness, the "npm" project is named after its command-line
utility, which was organically selected to be easily typed by a right-handed
programmer using a US QWERTY keyboard layout, ending with the
right-ring-finger in a postition to type the `-` key for flags and
other command-line arguments. That command-line utility is always
lower-case, though it starts most sentences it is a part of.
## How do I list installed packages?
`npm ls`
## How do I search for packages?
`npm search`
Arguments are greps. `npm search jsdom` shows jsdom packages.
## How do I update npm?
npm update npm -g
You can also update all outdated local packages by doing `npm update` without
any arguments, or global packages by doing `npm update -g`.
Occasionally, the version of npm will progress such that the current
version cannot be properly installed with the version that you have
installed already. (Consider, if there is ever a bug in the `update`
command.)
In those cases, you can do this:
curl http://npmjs.org/install.sh | sh
## What is a `package`?
A package is:
* a) a folder containing a program described by a package.json file
* b) a gzipped tarball containing (a)
* c) a url that resolves to (b)
* d) a `<name>@<version>` that is published on the registry with (c)
* e) a `<name>@<tag>` that points to (d)
* f) a `<name>` that has a "latest" tag satisfying (e)
* g) a `git` url that, when cloned, results in (a).
Even if you never publish your package, you can still get a lot of
benefits of using npm if you just want to write a node program (a), and
perhaps if you also want to be able to easily install it elsewhere
after packing it up into a tarball (b).
Git urls can be of the form:
git://github.com/user/project.git#commit-ish
git+ssh://user@hostname:project.git#commit-ish
git+http://user@hostname/project/blah.git#commit-ish
git+https://user@hostname/project/blah.git#commit-ish
The `commit-ish` can be any tag, sha, or branch which can be supplied as
an argument to `git checkout`. The default is `master`.
## How do I install node with npm?
You don't. Try one of these:
* <http://github.com/isaacs/nave>
* <http://github.com/visionmedia/n>
* <http://github.com/creationix/nvm>
## How can I use npm for development?
See `npm-developers(1)` and `npm-json(1)`.
You'll most likely want to `npm link` your development folder. That's
awesomely handy.
To set up your own private registry, check out `npm-registry(1)`.
## Can I list a url as a dependency?
Yes. It should be a url to a gzipped tarball containing a single folder
that has a package.json in its root, or a git url.
(See "what is a package?" above.)
## How do I symlink to a dev folder so I don't have to keep re-installing?
See `npm-link(1)`
## The package registry website. What is that exactly?
See `npm-registry(1)`.
## What's up with the insecure channel warnings?
Until node 0.4.10, there were problems sending big files over HTTPS. That
means that publishes go over HTTP by default in those versions of node.
## I forgot my password, and can't publish. How do I reset it?
Go to <http://admin.npmjs.org/reset>.
## I get ECONNREFUSED a lot. What's up?
Either the registry is down, or node's DNS isn't able to reach out.
This happens a lot if you don't follow *all* the steps in the Cygwin
setup doc.
To check if the registry is down, open up
<http://registry.npmjs.org/-/short>
in a web browser. This will also tell you if you are just unable to
access the internet for some reason.
If the registry IS down, let me know by emailing or posting an issue.
We'll have someone kick it or something.
## Who does npm?
`npm view npm author`
`npm view npm contributors`
## I have a question or request not addressed here. Where should I put it?
Discuss it on the mailing list, or post an issue.
* <npm-@googlegroups.com>
* <http://github.com/isaacs/npm/issues>
## Why does npm hate me?
npm is not capable of hatred. It loves everyone, especially you.
## SEE ALSO
* npm(1)
* npm-developers(1)
* npm-json(1)
* npm-config(1)
* npm-folders(1)

1
deps/npm/doc/cli/find.md vendored Symbolic link
View File

@ -0,0 +1 @@
search.md

209
deps/npm/doc/cli/folders.md vendored Normal file
View File

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

1
deps/npm/doc/cli/get.md vendored Symbolic link
View File

@ -0,0 +1 @@
config.md

1
deps/npm/doc/cli/global.md vendored Symbolic link
View File

@ -0,0 +1 @@
folders.md

35
deps/npm/doc/cli/help-search.md vendored Normal file
View File

@ -0,0 +1,35 @@
npm-help-search(1) -- Search npm help documentation
===================================================
## SYNOPSIS
npm help-search some search terms
## DESCRIPTION
This command will search the npm markdown documentation files for the
terms provided, and then list the results, sorted by relevance.
If only one result is found, then it will show that help topic.
If the argument to `npm help` is not a known help topic, then it will
call `help-search`. It is rarely if ever necessary to call this
command directly.
## CONFIGURATION
### long
* Type: Boolean
* Default false
If true, the "long" flag will cause help-search to output context around
where the terms were found in the documentation.
If false, then help-search will just list out the help topics found.
## SEE ALSO
* npm(1)
* npm-faq(1)
* npm-help(1)

38
deps/npm/doc/cli/help.md vendored Normal file
View File

@ -0,0 +1,38 @@
npm-help(1) -- Get help on npm
==============================
## SYNOPSIS
npm help <topic>
npm help some search terms
## DESCRIPTION
If supplied a topic, then show the appropriate documentation page.
If the topic does not exist, or if multiple terms are provided, then run
the `help-search` command to find a match. Note that, if `help-search`
finds a single subject, then it will run `help` on that topic, so unique
matches are equivalent to specifying a topic name.
## CONFIGURATION
### viewer
* Default: "man" on Posix, "browser" on Windows
* Type: path
The program to use to view help content.
Set to `"browser"` to view html help content in the default web browser.
## SEE ALSO
* npm(1)
* README
* npm-faq(1)
* npm-folders(1)
* npm-config(1)
* npm-json(1)
* npm-help-search(1)
* npm-index(1)

1
deps/npm/doc/cli/home.md vendored Symbolic link
View File

@ -0,0 +1 @@
docs.md

24
deps/npm/doc/cli/init.md vendored Normal file
View File

@ -0,0 +1,24 @@
npm-init(1) -- Interactively create a package.json file
=======================================================
## SYNOPSIS
npm init
## DESCRIPTION
This will ask you a bunch of questions, and then write a package.json for you.
It attempts to make reasonable guesses about what you want things to be set to,
and then writes a package.json file with the options you've selected.
If you already have a package.json file, it'll read that first, and default to
the options in there.
It is strictly additive, so it does not delete options from your package.json
without a really good reason to do so.
## SEE ALSO
* npm-json(1)
* npm-version(1)

201
deps/npm/doc/cli/install.md vendored Normal file
View File

@ -0,0 +1,201 @@
npm-install(1) -- Install a package
===================================
## SYNOPSIS
npm install (with no args in a package dir)
npm install <tarball file>
npm install <tarball url>
npm install <folder>
npm install <name>
npm install <name>@<tag>
npm install <name>@<version>
npm install <name>@<version range>
## DESCRIPTION
This command installs a package, and any packages that it depends on.
A `package` is:
* a) a folder containing a program described by a package.json file
* b) a gzipped tarball containing (a)
* c) a url that resolves to (b)
* d) a `<name>@<version>` that is published on the registry with (c)
* e) a `<name>@<tag>` that points to (d)
* f) a `<name>` that has a "latest" tag satisfying (e)
* g) a `<git remote url>` that resolves to (b)
Even if you never publish your package, you can still get a lot of
benefits of using npm if you just want to write a node program (a), and
perhaps if you also want to be able to easily install it elsewhere
after packing it up into a tarball (b).
* `npm install` (in package directory, no arguments):
Install the dependencies in the local node_modules folder.
In global mode (ie, with `-g` or `--global` appended to the command),
it installs the current package context (ie, the current working
directory) as a global package.
* `npm install <folder>`:
Install a package that is sitting in a folder on the filesystem.
* `npm install <tarball file>`:
Install a package that is sitting on the filesystem. Note: if you just want
to link a dev directory into your npm root, you can do this more easily by
using `npm link`.
Example:
npm install ./package.tgz
* `npm install <tarball url>`:
Fetch the tarball url, and then install it. In order to distinguish between
this and other options, the argument must start with "http://" or "https://"
Example:
npm install https://github.com/indexzero/forever/tarball/v0.5.6
* `npm install <name>`:
Do a `<name>@<tag>` install, where `<tag>` is the "tag" config. (See
`npm-config(1)`)
Example:
npm install sax
**Note**: If there is a file or folder named `<name>` in the current
working directory, then it will try to install that, and only try to
fetch the package by name if it is not valid.
* `npm install <name>@<tag>`:
Install the version of the package that is referenced by the specified tag.
If the tag does not exist in the registry data for that package, then this
will fail.
Example:
npm install sax@latest
* `npm install <name>@<version>`:
Install the specified version of the package. This will fail if the version
has not been published to the registry.
Example:
npm install sax@0.1.1
* `npm install <name>@<version range>`:
Install a version of the package matching the specified version range. This
will follow the same rules for resolving dependencies described in `npm-json(1)`.
Note that most version ranges must be put in quotes so that your shell will
treat it as a single argument.
Example:
npm install sax@">=0.1.0 <0.2.0"
* `npm install <git remote url>`:
Install a package by cloning a git remote url. The format of the git
url is:
<protocol>://[<user>@]<hostname><separator><path>[#<commit-ish>]
`<protocol>` is one of `git`, `git+ssh`, `git+http`, or
`git+https`. If no `<commit-ish>` is specified, then `master` is
used.
Examples:
git+ssh://git@github.com:isaacs/npm.git#v1.0.27
git+https://isaacs@github.com/isaacs/npm.git
git://github.com/isaacs/npm.git#v1.0.27
You may combine multiple arguments, and even multiple types of arguments.
For example:
npm install sax@">=0.1.0 <0.2.0" bench supervisor
The `--tag` argument will apply to all of the specified install targets.
The `--force` argument will force npm to fetch remote resources even if a
local copy exists on disk.
npm install sax --force
The `--global` argument will cause npm to install the package globally
rather than locally. See `npm-global(1)`.
The `--link` argument will cause npm to link global installs into the
local space in some cases.
See `npm-config(1)`. Many of the configuration params have some
effect on installation, since that's most of what npm does.
## ALGORITHM
To install a package, npm uses the following algorithm:
install(where, what, family, ancestors)
fetch what, unpack to <where>/node_modules/<what>
for each dep in what.dependencies
resolve dep to precise version
for each dep@version in what.dependencies
not in <where>/node_modules/<what>/node_modules/*
and not in <family>
add precise version deps to <family>
install(<where>/node_modules/<what>, dep, family)
For this `package{dep}` structure: `A{B,C}, B{C}, C{D}`,
this algorithm produces:
A
+-- B
`-- C
`-- D
That is, the dependency from B to C is satisfied by the fact that A
already caused C to be installed at a higher level.
See npm-folders(1) for a more detailed description of the specific
folder structures that npm creates.
### Limitations of npm's Install Algorithm
There are some very rare and pathological edge-cases where a cycle can
cause npm to try to install a never-ending tree of packages. Here is
the simplest case:
A -> B -> A' -> B' -> A -> B -> A' -> B' -> A -> ...
where `A` is some version of a package, and `A'` is a different version
of the same package. Because `B` depends on a different version of `A`
than the one that is already in the tree, it must install a separate
copy. The same is true of `A'`, which must install `B'`. Because `B'`
depends on the original version of `A`, which has been overridden, the
cycle falls into infinite regress.
To avoid this situation, npm flat-out refuses to install any
`name@version` that is already present anywhere in the tree of package
folder ancestors. A more correct, but more complex, solution would be
to symlink the existing version into the new location. If this ever
affects a real use-case, it will be investigated.
## SEE ALSO
* npm-folders(1)
* npm-update(1)
* npm-link(1)
* npm-rebuild(1)
* npm-scripts(1)
* npm-build(1)
* npm-config(1)
* npm-registry(1)
* npm-folders(1)
* npm-tag(1)
* npm-rm(1)

472
deps/npm/doc/cli/json.md vendored Normal file
View File

@ -0,0 +1,472 @@
npm-json(1) -- Specifics of npm's package.json handling
=======================================================
## DESCRIPTION
This document is all you need to know about what's required in your package.json
file. It must be actual JSON, not just a JavaScript object literal.
A lot of the behavior described in this document is affected by the config
settings described in `npm-config(1)`.
## DEFAULT VALUES
npm will default some values based on package contents.
* `"scripts": {"start": "node server.js"}`
If there is a `server.js` file in the root of your package, then npm
will default the `start` command to `node server.js`.
* `"scripts":{"preinstall": "node-waf clean || true; node-waf configure build"}`
If there is a `wscript` file in the root of your package, npm will
default the `preinstall` command to compile using node-waf.
* `"contributors": [...]`
If there is an `AUTHORS` file in the root of your package, npm will
treat each line as a `Name <email> (url)` format, where email and url
are optional. Lines which start with a `#` or are blank, will be
ignored.
## name
The *most* important things in your package.json are the name and version fields.
Those are actually required, and your package won't install without
them. The name and version together form an identifier that is assumed
to be completely unique. Changes to the package should come along with
changes to the version.
The name is what your thing is called. Some tips:
* Don't put "js" or "node" in the name. It's assumed that it's js, since you're
writing a package.json file, and you can specify the engine using the "engines"
field. (See below.)
* The name ends up being part of a URL, an argument on the command line, and a
folder name. Any name with non-url-safe characters will be rejected.
Also, it can't start with a dot or an underscore.
* The name will probably be passed as an argument to require(), so it should
be something short, but also reasonably descriptive.
* You may want to check the npm registry to see if there's something by that name
already, before you get too attached to it. http://registry.npmjs.org/
## version
The *most* important things in your package.json are the name and version fields.
Those are actually required, and your package won't install without
them. The name and version together form an identifier that is assumed
to be completely unique. Changes to the package should come along with
changes to the version.
Version must be parseable by
[node-semver](https://github.com/isaacs/node-semver), which is bundled
with npm as a dependency. (`npm install semver` to use it yourself.)
Here's how npm's semver implementation deviates from what's on semver.org:
* Versions can start with "v"
* A numeric item separated from the main three-number version by a hyphen
will be interpreted as a "build" number, and will *increase* the version.
But, if the tag is not a number separated by a hyphen, then it's treated
as a pre-release tag, and is *less than* the version without a tag.
So, `0.1.2-7 > 0.1.2-7-beta > 0.1.2-6 > 0.1.2 > 0.1.2beta`
This is a little bit confusing to explain, but matches what you see in practice
when people create tags in git like "v1.2.3" and then do "git describe" to generate
a patch version.
## description
Put a description in it. It's a string. This helps people discover your
package, as it's listed in `npm search`.
## keywords
Put keywords in it. It's an array of strings. This helps people
discover your package as it's listed in `npm search`.
## homepage
The url to the project homepage.
**NOTE**: This is *not* the same as "url". If you put a "url" field,
then the registry will think it's a redirection to your package that has
been published somewhere else, and spit at you.
Literally. Spit. I'm so not kidding.
## bugs
The url to your project's issue tracker and / or the email address to which
issues should be reported. These are helpful for people who encounter issues
with your package.
It should look like this:
{ "url" : "http://github.com/owner/project/issues"
, "email" : "project@hostname.com"
}
You can specify either one or both values. If you want to provide only a url,
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.
## people fields: author, contributors
The "author" is one person. "contributors" is an array of people. A "person"
is an object with a "name" field and optionally "url" and "email", like this:
{ "name" : "Barney Rubble"
, "email" : "b@rubble.com"
, "url" : "http://barnyrubble.tumblr.com/"
}
Or you can shorten that all into a single string, and npm will parse it for you:
"Barney Rubble <b@rubble.com> (http://barnyrubble.tumblr.com/)
Both email and url are optional either way.
npm also sets a top-level "maintainers" field with your npm user info.
## files
The "files" field is an array of files to include in your project. If
you name a folder in the array, then it will also include the files
inside that folder. (Unless they would be ignored by another rule.)
You can also provide a ".npmignore" file in the root of your package,
which will keep files from being included, even if they would be picked
up by the files array. The ".npmignore" file works just like a
".gitignore".
## main
The main field is a module ID that is the primary entry point to your program.
That is, if your package is named `foo`, and a user installs it, and then does
`require("foo")`, then your main module's exports object will be returned.
This should be a module ID relative to the root of your package folder.
For most modules, it makes the most sense to have a main script and often not
much else.
## bin
A lot of packages have one or more executable files that they'd like to
install into the PATH. npm makes this pretty easy (in fact, it uses this
feature to install the "npm" executable.)
To use this, supply a `bin` field in your package.json which is a map of
command name to local file name. On install, npm will symlink that file into
`prefix/bin` for global installs, or `./node_modules/.bin/` for local
installs.
For example, npm has this:
{ "bin" : { "npm" : "./cli.js" } }
So, when you install npm, it'll create a symlink from the `cli.js` script to
`/usr/local/bin/npm`.
If you have a single executable, and its name should be the name
of the package, then you can just supply it as a string. For example:
{ "name": "my-program"
, "version": "1.2.5"
, "bin": "./path/to/program" }
would be the same as this:
{ "name": "my-program"
, "version": "1.2.5"
, "bin" : { "my-program" : "./path/to/program" } }
## man
Specify either a single file or an array of filenames to put in place for the
`man` program to find.
If only a single file is provided, then it's installed such that it is the
result from `man <pkgname>`, regardless of its actual filename. For example:
{ "name" : "foo"
, "version" : "1.2.3"
, "description" : "A packaged foo fooer for fooing foos"
, "main" : "foo.js"
, "man" : "./man/doc.1"
}
would link the `./man/doc.1` file in such that it is the target for `man foo`
If the filename doesn't start with the package name, then it's prefixed.
So, this:
{ "name" : "foo"
, "version" : "1.2.3"
, "description" : "A packaged foo fooer for fooing foos"
, "main" : "foo.js"
, "man" : [ "./man/foo.1", "./man/bar.1" ]
}
will create files to do `man foo` and `man foo-bar`.
Man files must end with a number, and optionally a `.gz` suffix if they are
compressed. The number dictates which man section the file is installed into.
{ "name" : "foo"
, "version" : "1.2.3"
, "description" : "A packaged foo fooer for fooing foos"
, "main" : "foo.js"
, "man" : [ "./man/foo.1", "./man/foo.2" ]
}
will create entries for `man foo` and `man 2 foo`
## directories
The CommonJS [Packages](http://wiki.commonjs.org/wiki/Packages/1.0) spec details a
few ways that you can indicate the structure of your package using a `directories`
hash. If you look at [npm's package.json](http://registry.npmjs.org/npm/latest),
you'll see that it has directories for doc, lib, and man.
In the future, this information may be used in other creative ways.
### directories.lib
Tell people where the bulk of your library is. Nothing special is done
with the lib folder in any way, but it's useful meta info.
### directories.bin
If you specify a "bin" directory, then all the files in that folder will
be used as the "bin" hash.
If you have a "bin" hash already, then this has no effect.
### directories.man
A folder that is full of man pages. Sugar to generate a "man" array by
walking the folder.
### directories.doc
Put markdown files in here. Eventually, these will be displayed nicely,
maybe, someday.
### directories.example
Put example scripts in here. Someday, it might be exposed in some clever way.
## repository
Specify the place where your code lives. This is helpful for people who
want to contribute. If the git repo is on github, then the `npm docs`
command will be able to find you.
Do it like this:
"repository" :
{ "type" : "git"
, "url" : "http://github.com/isaacs/npm.git"
}
"repository" :
{ "type" : "svn"
, "url" : "http://v8.googlecode.com/svn/trunk/"
}
The URL should be a publicly available (perhaps read-only) url that can be handed
directly to a VCS program without any modification. It should not be a url to an
html project page that you put in your browser. It's for computers.
## scripts
The "scripts" member is an object hash of script commands that are run
at various times in the lifecycle of your package. The key is the lifecycle
event, and the value is the command to run at that point.
See `npm-scripts(1)` to find out more about writing package scripts.
## config
A "config" hash can be used to set configuration
parameters used in package scripts that persist across upgrades. For
instance, if a package had the following:
{ "name" : "foo"
, "config" : { "port" : "8080" } }
and then had a "start" command that then referenced the
`npm_package_config_port` environment variable, then the user could
override that by doing `npm config set foo:port 8001`.
See `npm-config(1)` and `npm-scripts(1)` for more on package
configs.
## dependencies
Dependencies are specified with a simple hash of package name to version
range. The version range is EITHER a string which has one or more
space-separated descriptors, OR a range like "fromVersion - toVersion"
**Please do not put test harnesses in your `dependencies` hash.** See
`devDependencies`, below.
Version range descriptors may be any of the following styles, where "version"
is a semver compatible version identifier.
* `version` Must match `version` exactly
* `=version` Same as just `version`
* `>version` Must be greater than `version`
* `>=version` etc
* `<version`
* `<=version`
* `~version` See 'Tilde Version Ranges' below
* `1.2.x` See 'X Version Ranges' below
* `http://...` See 'URLs as Dependencies' below
* `*` Matches any version
* `""` (just an empty string) Same as `*`
* `version1 - version2` Same as `>=version1 <=version2`.
* `range1 || range2` Passes if either range1 or range2 are satisfied.
For example, these are all valid:
{ "dependencies" :
{ "foo" : "1.0.0 - 2.9999.9999"
, "bar" : ">=1.0.2 <2.1.2"
, "baz" : ">1.0.2 <=2.3.4"
, "boo" : "2.0.1"
, "qux" : "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0"
, "asd" : "http://asdf.com/asdf.tar.gz"
, "til" : "~1.2"
, "elf" : "~1.2.3"
, "two" : "2.x"
, "thr" : "3.3.x"
}
}
### Tilde Version Ranges
A range specifier starting with a tilde `~` character is matched against
a version in the following fashion.
* The version must be at least as high as the range.
* The version must be less than the next major revision above the range.
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"`
### X Version Ranges
An "x" in a version range specifies that the version number must start
with the supplied digits, but any digit may be used in place of the x.
The following are equivalent:
* `"1.2.x" = ">=1.2.0 <1.3.0"`
* `"1.x.x" = ">=1.0.0 <2.0.0"`
* `"1.2" = "1.2.x"`
* `"1.x" = "1.x.x"`
* `"1" = "1.x.x"`
You may not supply a comparator with a version containing an x. Any
digits after the first "x" are ignored.
### URLs as Dependencies
Starting with npm version 0.2.14, you may specify a tarball URL in place
of a version range.
This tarball will be downloaded and installed locally to your package at
install time.
## devDependencies
If someone is planning on downloading and using your module in their
program, then they probably don't want or need to download and build
the external test or documentation framework that you use.
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.
## bundledDependencies
Array of package names that will be bundled when publishing the package.
If this is spelled `"bundleDependencies"`, then that is also honorable.
## engines
You can specify the version of
node that your stuff works on:
{ "engines" : { "node" : ">=0.1.27 <0.1.30" } }
And, like with dependencies, if you don't specify the version (or if you
specify "*" as the version), then any version of node will do.
If you specify an "engines" field, then npm will require that "node" be
somewhere on that list. If "engines" is omitted, then npm will just assume
that it works on node.
You can also use the "engines" field to specify which versions of npm
are capable of properly installing your program. For example:
{ "engines" : { "npm" : "~1.0.20" } }
## preferGlobal
If your package is primarily a command-line application that should be
installed globally, then set this value to `true` to provide a warning
if it is installed locally.
It doesn't actually prevent users from installing it locally, but it
does help prevent some confusion if it doesn't work as expected.
## private
If you set `"private": true` in your package.json, then npm will refuse
to publish it.
This is a way to prevent accidental publication of private repositories.
If you would like to ensure that a given package is only ever published
to a speciic registry (for example, an internal registry),
then use the `publishConfig` hash described below
to override the `registry` config param at publish-time.
## publishConfig
This is a set of config values that will be used at publish-time. It's
especially handy if you want to set the tag or registry, so that you can
ensure that a given package is not tagged with "latest" or published to
the global public registry by default.
Any config values can be overridden, but of course only "tag" and
"registry" probably matter for the purposes of publishing.
See `npm-config(1)` to see the list of config options that can be
overridden.
## SEE ALSO
* npm-semver(1)
* npm-init(1)
* npm-version(1)
* npm-config(1)
* npm-help(1)
* npm-faq(1)
* npm-install(1)
* npm-publish(1)
* npm-rm(1)

57
deps/npm/doc/cli/link.md vendored Normal file
View File

@ -0,0 +1,57 @@
npm-link(1) -- Symlink a package folder
=======================================
## SYNOPSIS
npm link (in package folder)
npm link <pkgname>
## DESCRIPTION
Package linking is a two-step process.
First, `npm link` in a package folder will create a globally-installed
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.
When creating tarballs for `npm publish`, the linked packages are
"snapshotted" to their current state by resolving the symbolic links.
This is
handy for installing your own stuff, so that you can work on it and test it
iteratively without having to continually rebuild.
For example:
cd ~/projects/node-redis # go into the package directory
npm link # creates global link
cd ~/projects/node-bloggy # go into some other package directory.
npm link redis # link-install the package
Now, any changes to ~/projects/node-redis will be reflected in
~/projects/node-bloggy/node_modules/redis/
You may also shortcut the two steps in one. For example, to do the
above use-case in a shorter way:
cd ~/projects/node-bloggy # go into the dir of your main project
npm link ../node-redis # link the dir of your dependency
The second line is the equivalent of doing:
(cd ../node-redis; npm link)
npm link redis
That is, it first creates a global link, and then links the global
installation target into your project's `node_modules` folder.
## SEE ALSO
* npm-developers(1)
* npm-faq(1)
* npm-json(1)
* npm-install(1)
* npm-folders(1)
* npm-config(1)

55
deps/npm/doc/cli/list.md vendored Normal file
View File

@ -0,0 +1,55 @@
npm-ls(1) -- List installed packages
======================================
## SYNOPSIS
npm list
npm ls
npm la
npm ll
## DESCRIPTION
This command will print to stdout all the versions of packages that are
installed, as well as their dependencies, in a tree-structure.
It does not take positional arguments, though you may set config flags
like with any other command, such as `-g` to list global packages.
It will print out extraneous, missing, and invalid packages.
When run as `ll` or `la`, it shows extended information by default.
## CONFIGURATION
### long
* Default: false
* Type: Boolean
Show extended information.
### parseable
* Default: false
* Type: Boolean
Show parseable output instead of tree view.
### global
* Default: false
* Type: Boolean
List packages in the global install prefix instead of in the current
project.
## SEE ALSO
* npm-config(1)
* npm-folders(1)
* npm-install(1)
* npm-link(1)
* npm-prune(1)
* npm-outdated(1)
* npm-update(1)

1
deps/npm/doc/cli/ln.md vendored Symbolic link
View File

@ -0,0 +1 @@
link.md

1
deps/npm/doc/cli/ls.md vendored Symbolic link
View File

@ -0,0 +1 @@
list.md

155
deps/npm/doc/cli/npm.md vendored Normal file
View File

@ -0,0 +1,155 @@
npm(1) -- node package manager
==============================
## SYNOPSIS
npm <command> [args]
## VERSION
@VERSION@
## DESCRIPTION
npm is the package manager for the Node JavaScript platform. It puts
modules in place so that node can find them, and manages dependency
conflicts intelligently.
It is extremely configurable to support a wide variety of use cases.
Most commonly, it is used to publish, discover, install, and develop node
programs.
Run `npm help` to get a list of available commands.
## INTRODUCTION
You probably got npm because you want to install stuff.
Use `npm install blerg` to install the latest version of "blerg". Check out
`npm-install(1)` for more info. It can do a lot of stuff.
Use the `npm search` command to show everything that's available.
Use `npm ls` to show everything you've installed.
## DIRECTORIES
See `npm-folders(1)` to learn about where npm puts stuff.
In particular, npm has two modes of operation:
* global mode:
npm installs packages into the install prefix at
`prefix/lib/node_modules` and bins are installed in `prefix/bin`.
* local mode:
npm installs packages into the current project directory, which
defaults to the current working directory. Packages are installed to
`./node_modules`, and bins are installed to `./node_modules/.bin`.
Local mode is the default. Use `--global` or `-g` on any command to
operate in global mode instead.
## DEVELOPER USAGE
If you're using npm to develop and publish your code, check out the
following help topics:
* json:
Make a package.json file. See `npm-json(1)`.
* link:
For linking your current working code into Node's path, so that you
don't have to reinstall every time you make a change. Use
`npm link` to do this.
* install:
It's a good idea to install things if you don't need the symbolic link.
Especially, installing other peoples code from the registry is done via
`npm install`
* adduser:
Create an account or log in. Creditials are stored in the
user config file.
* publish:
Use the `npm publish` command to upload your code to the registry.
## CONFIGURATION
npm is extremely configurable. It reads its configuration options from
5 places.
* Command line switches:
Set a config with `--key val`. All keys take a value, even if they
are booleans (the config parser doesn't know what the options are at
the time of parsing.) If no value is provided, then the option is set
to boolean `true`.
* Environment Variables:
Set any config by prefixing the name in an environment variable with
`npm_config_`. For example, `export npm_config_key=val`.
* User Configs:
The file at $HOME/.npmrc is an ini-formatted list of configs. If
present, it is parsed. If the `userconfig` option is set in the cli
or env, then that will be used instead.
* Global Configs:
The file found at ../etc/npmrc (from the node executable, by default
this resolves to /usr/local/etc/npmrc) will be parsed if it is found.
If the `globalconfig` option is set in the cli, env, or user config,
then that file is parsed instead.
* Defaults:
npm's default configuration options are defined in
lib/utils/config-defs.js. These must not be changed.
See `npm-config(1)` for much much more information.
## CONTRIBUTIONS
Patches welcome!
* code:
Read through `npm-coding-style(1)` if you plan to submit code.
You don't have to agree with it, but you do have to follow it.
* docs:
If you find an error in the documentation, edit the appropriate markdown
file in the "doc" folder. (Don't worry about generating the man page.)
Contributors are listed in npm's `package.json` file. You can view them
easily by doing `npm view npm contributors`.
If you would like to contribute, but don't know what to work on, check
the issues list or ask on the mailing list.
* <http://github.com/isaacs/npm/issues>
* <npm-@googlegroups.com>
## BUGS
When you find issues, please report them:
* web:
<http://github.com/isaacs/npm/issues>
* email:
<npm-@googlegroups.com>
Be sure to include *all* of the output from the npm command that didn't work
as expected. The `npm-debug.log` file is also helpful to provide.
You can also look for isaacs in #node.js on irc://irc.freenode.net. He
will no doubt tell you to put the output in a gist or email.
## HISTORY
See npm-changelog(1)
## AUTHOR
[Isaac Z. Schlueter](http://blog.izs.me/) ::
[isaacs](https://github.com/isaacs/) ::
[@izs](http://twitter.com/izs) ::
<i@izs.me>
## SEE ALSO
* npm-help(1)
* npm-faq(1)
* README
* npm-json(1)
* npm-install(1)
* npm-config(1)
* npm-index(1)
* npm(3)

17
deps/npm/doc/cli/outdated.md vendored Normal file
View File

@ -0,0 +1,17 @@
npm-outdated(1) -- Check for outdated packages
==============================================
## SYNOPSIS
npm outdated [<name> [<name> ...]]
## DESCRIPTION
This command will check the registry to see if any (or, specific) installed
packages are currently outdated.
## SEE ALSO
* npm-update(1)
* npm-registry(1)
* npm-folders(1)

32
deps/npm/doc/cli/owner.md vendored Normal file
View File

@ -0,0 +1,32 @@
npm-owner(1) -- Manage package owners
=====================================
## SYNOPSIS
npm owner ls <package name>
npm owner add <user> <package name>
npm owner rm <user> <package name>
## DESCRIPTION
Manage ownership of published packages.
* ls:
List all the users who have access to modify a package and push new versions.
Handy when you need to know who to bug for help.
* add:
Add a new user as a maintainer of a package. This user is enabled to modify
metadata, publish new versions, and add other owners.
* rm:
Remove a user from the package owner list. This immediately revokes their
privileges.
Note that there is only one level of access. Either you can modify a package,
or you can't. Future versions may contain more fine-grained access levels, but
that is not implemented at this time.
## SEE ALSO
* npm-publish(1)
* npm-registry(1)
* npm-adduser(1)

25
deps/npm/doc/cli/pack.md vendored Normal file
View File

@ -0,0 +1,25 @@
npm-pack(1) -- Create a tarball from a package
==============================================
## SYNOPSIS
npm pack [<pkg> [<pkg> ...]]
## DESCRIPTION
For anything that's installable (that is, a package folder, tarball,
tarball url, name@tag, name@version, or name), this command will fetch
it to the cache, and then copy the tarball to the current working
directory as `<name>-<version>.tgz`, and then write the filenames out to
stdout.
If the same package is specified multiple times, then the file will be
overwritten the second time.
If no arguments are supplied, then npm packs the current package folder.
## SEE ALSO
* npm-cache(1)
* npm-publish(1)
* npm-config(1)

17
deps/npm/doc/cli/prefix.md vendored Normal file
View File

@ -0,0 +1,17 @@
npm-prefix(1) -- Display prefix
===============================
## SYNOPSIS
npm prefix
## DESCRIPTION
Print the prefix to standard out.
## SEE ALSO
* npm-root(1)
* npm-bin(1)
* npm-folders(1)
* npm-config(1)

21
deps/npm/doc/cli/prune.md vendored Normal file
View File

@ -0,0 +1,21 @@
npm-prune(1) -- Remove extraneous packages
==========================================
## SYNOPSIS
npm prune [<name> [<name ...]]
## DESCRIPTION
This command removes "extraneous" packages. If a package name is
provided, then only packages matching one of the supplied names are
removed.
Extraneous packages are packages that are not listed on the parent
package's dependencies list.
## SEE ALSO
* npm-rm(1)
* npm-folders(1)
* npm-list(1)

30
deps/npm/doc/cli/publish.md vendored Normal file
View File

@ -0,0 +1,30 @@
npm-publish(1) -- Publish a package
===================================
## SYNOPSIS
npm publish <tarball>
npm publish <folder>
## DESCRIPTION
Publishes a package to the registry so that it can be installed by name.
* `<folder>`:
A folder containing a package.json file
* `<tarball>`:
A url or file path to a gzipped tar archive containing a single folder
with a package.json file inside.
Fails if the package name and version combination already exists in
the registry. Overwrites when the "--force" flag is set.
## SEE ALSO
* npm-registry(1)
* npm-adduser(1)
* npm-owner(1)
* npm-deprecate(1)
* npm-tag(1)

Some files were not shown because too many files have changed in this diff Show More