Include NPM, update .pkg to install it.
.msi update coming soon.
This commit is contained in:
Ryan Dahl
parent
05de01d707
commit
b488be127a
6
LICENSE
6
LICENSE
@ -78,3 +78,9 @@ The externally maintained libraries used by Node are:
|
||||
- deps/zlib copyright 1995-2010 Jean-loup Gailly and Mark Adler
|
||||
licensed under a permissive free software license. See
|
||||
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
15
deps/npm/.gitignore
vendored
Normal 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
51
deps/npm/.gitmodules
vendored
Normal 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
11
deps/npm/.npmignore
vendored
Normal 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
50
deps/npm/AUTHORS
vendored
Normal 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
1
deps/npm/CHANGES
vendored
Symbolic link
@ -0,0 +1 @@
|
||||
doc/cli/changelog.md
|
||||
61
deps/npm/LICENSE
vendored
Normal file
61
deps/npm/LICENSE
vendored
Normal 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
125
deps/npm/Makefile
vendored
Normal 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
274
deps/npm/README.md
vendored
Normal 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
77
deps/npm/bin/npm-cli.js
vendored
Executable 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
6
deps/npm/bin/npm-g.cmd
vendored
Normal 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
16
deps/npm/bin/npm-get-uid-gid.js
vendored
Executable 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
6
deps/npm/bin/npm.cmd
vendored
Normal 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
6
deps/npm/bin/npm_g.cmd
vendored
Normal 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
22
deps/npm/bin/read-package-json.js
vendored
Executable 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
2
deps/npm/cli.js
vendored
Executable file
@ -0,0 +1,2 @@
|
||||
#!/usr/bin/env node
|
||||
require("./bin/npm-cli.js")
|
||||
33
deps/npm/configure
vendored
Executable file
33
deps/npm/configure
vendored
Executable 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
1
deps/npm/doc/api/author.md
vendored
Symbolic link
@ -0,0 +1 @@
|
||||
owner.md
|
||||
13
deps/npm/doc/api/bin.md
vendored
Normal file
13
deps/npm/doc/api/bin.md
vendored
Normal 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
19
deps/npm/doc/api/bugs.md
vendored
Normal 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
22
deps/npm/doc/api/commands.md
vendored
Normal 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
45
deps/npm/doc/api/config.md
vendored
Normal 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
32
deps/npm/doc/api/deprecate.md
vendored
Normal 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
19
deps/npm/doc/api/docs.md
vendored
Normal 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
24
deps/npm/doc/api/edit.md
vendored
Normal 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
18
deps/npm/doc/api/explore.md
vendored
Normal 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
1
deps/npm/doc/api/find.md
vendored
Symbolic link
@ -0,0 +1 @@
|
||||
ls.md
|
||||
1
deps/npm/doc/api/get.md
vendored
Symbolic link
1
deps/npm/doc/api/get.md
vendored
Symbolic link
@ -0,0 +1 @@
|
||||
config.md
|
||||
30
deps/npm/doc/api/help-search.md
vendored
Normal file
30
deps/npm/doc/api/help-search.md
vendored
Normal 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
1
deps/npm/doc/api/home.md
vendored
Symbolic link
@ -0,0 +1 @@
|
||||
docs.md
|
||||
29
deps/npm/doc/api/init.md
vendored
Normal file
29
deps/npm/doc/api/init.md
vendored
Normal 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
19
deps/npm/doc/api/install.md
vendored
Normal 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
33
deps/npm/doc/api/link.md
vendored
Normal 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
1
deps/npm/doc/api/list.md
vendored
Symbolic link
@ -0,0 +1 @@
|
||||
ls.md
|
||||
1
deps/npm/doc/api/ln.md
vendored
Symbolic link
1
deps/npm/doc/api/ln.md
vendored
Symbolic link
@ -0,0 +1 @@
|
||||
link.md
|
||||
26
deps/npm/doc/api/load.md
vendored
Normal file
26
deps/npm/doc/api/load.md
vendored
Normal 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
50
deps/npm/doc/api/ls.md
vendored
Normal 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
115
deps/npm/doc/api/npm.md
vendored
Normal 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
13
deps/npm/doc/api/outdated.md
vendored
Normal 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
31
deps/npm/doc/api/owner.md
vendored
Normal 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
19
deps/npm/doc/api/pack.md
vendored
Normal 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
15
deps/npm/doc/api/prefix.md
vendored
Normal 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
17
deps/npm/doc/api/prune.md
vendored
Normal 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
30
deps/npm/doc/api/publish.md
vendored
Normal 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
16
deps/npm/doc/api/rebuild.md
vendored
Normal 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
22
deps/npm/doc/api/restart.md
vendored
Normal 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
1
deps/npm/doc/api/rm.md
vendored
Symbolic link
@ -0,0 +1 @@
|
||||
uninstall.md
|
||||
15
deps/npm/doc/api/root.md
vendored
Normal file
15
deps/npm/doc/api/root.md
vendored
Normal 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
27
deps/npm/doc/api/run-script.md
vendored
Normal 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
35
deps/npm/doc/api/search.md
vendored
Normal 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
1
deps/npm/doc/api/set.md
vendored
Symbolic link
@ -0,0 +1 @@
|
||||
config.md
|
||||
13
deps/npm/doc/api/start.md
vendored
Normal file
13
deps/npm/doc/api/start.md
vendored
Normal 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
13
deps/npm/doc/api/stop.md
vendored
Normal 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
28
deps/npm/doc/api/submodule.md
vendored
Normal 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
23
deps/npm/doc/api/tag.md
vendored
Normal 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
16
deps/npm/doc/api/test.md
vendored
Normal 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
16
deps/npm/doc/api/uninstall.md
vendored
Normal 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
20
deps/npm/doc/api/unpublish.md
vendored
Normal 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
11
deps/npm/doc/api/update.md
vendored
Normal 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
18
deps/npm/doc/api/version.md
vendored
Normal 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
93
deps/npm/doc/api/view.md
vendored
Normal 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
15
deps/npm/doc/api/whoami.md
vendored
Normal 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
36
deps/npm/doc/cli/adduser.md
vendored
Normal 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
1
deps/npm/doc/cli/author.md
vendored
Symbolic link
@ -0,0 +1 @@
|
||||
owner.md
|
||||
17
deps/npm/doc/cli/bin.md
vendored
Normal file
17
deps/npm/doc/cli/bin.md
vendored
Normal 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
38
deps/npm/doc/cli/bugs.md
vendored
Normal 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
22
deps/npm/doc/cli/build.md
vendored
Normal 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
14
deps/npm/doc/cli/bundle.md
vendored
Normal 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
70
deps/npm/doc/cli/cache.md
vendored
Normal 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
36
deps/npm/doc/cli/changelog.md
vendored
Normal 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
190
deps/npm/doc/cli/coding-style.md
vendored
Normal 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
29
deps/npm/doc/cli/completion.md
vendored
Normal 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
665
deps/npm/doc/cli/config.md
vendored
Normal 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
24
deps/npm/doc/cli/deprecate.md
vendored
Normal 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
172
deps/npm/doc/cli/developers.md
vendored
Normal 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
38
deps/npm/doc/cli/docs.md
vendored
Normal 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
35
deps/npm/doc/cli/edit.md
vendored
Normal 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
40
deps/npm/doc/cli/explore.md
vendored
Normal 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
223
deps/npm/doc/cli/faq.md
vendored
Normal 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
1
deps/npm/doc/cli/find.md
vendored
Symbolic link
@ -0,0 +1 @@
|
||||
search.md
|
||||
209
deps/npm/doc/cli/folders.md
vendored
Normal file
209
deps/npm/doc/cli/folders.md
vendored
Normal 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
1
deps/npm/doc/cli/get.md
vendored
Symbolic link
@ -0,0 +1 @@
|
||||
config.md
|
||||
1
deps/npm/doc/cli/global.md
vendored
Symbolic link
1
deps/npm/doc/cli/global.md
vendored
Symbolic link
@ -0,0 +1 @@
|
||||
folders.md
|
||||
35
deps/npm/doc/cli/help-search.md
vendored
Normal file
35
deps/npm/doc/cli/help-search.md
vendored
Normal 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
38
deps/npm/doc/cli/help.md
vendored
Normal 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
1
deps/npm/doc/cli/home.md
vendored
Symbolic link
@ -0,0 +1 @@
|
||||
docs.md
|
||||
24
deps/npm/doc/cli/init.md
vendored
Normal file
24
deps/npm/doc/cli/init.md
vendored
Normal 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
201
deps/npm/doc/cli/install.md
vendored
Normal 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
472
deps/npm/doc/cli/json.md
vendored
Normal 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
57
deps/npm/doc/cli/link.md
vendored
Normal 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
55
deps/npm/doc/cli/list.md
vendored
Normal 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
1
deps/npm/doc/cli/ln.md
vendored
Symbolic link
@ -0,0 +1 @@
|
||||
link.md
|
||||
1
deps/npm/doc/cli/ls.md
vendored
Symbolic link
1
deps/npm/doc/cli/ls.md
vendored
Symbolic link
@ -0,0 +1 @@
|
||||
list.md
|
||||
155
deps/npm/doc/cli/npm.md
vendored
Normal file
155
deps/npm/doc/cli/npm.md
vendored
Normal 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
17
deps/npm/doc/cli/outdated.md
vendored
Normal 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
32
deps/npm/doc/cli/owner.md
vendored
Normal 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
25
deps/npm/doc/cli/pack.md
vendored
Normal 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
17
deps/npm/doc/cli/prefix.md
vendored
Normal 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
21
deps/npm/doc/cli/prune.md
vendored
Normal 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
30
deps/npm/doc/cli/publish.md
vendored
Normal 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
Loading…
x
Reference in New Issue
Block a user