mirror of https://github.com/lukechilds/node.git
Ryan Dahl
13 years ago
483 changed files with 33629 additions and 146 deletions
@ -1,2 +0,0 @@ |
|||||
include_directories (.) |
|
||||
add_library (http_parser http_parser.c) |
|
||||
@ -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 |
||||
@ -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 |
||||
@ -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 |
||||
@ -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> |
||||
@ -0,0 +1 @@ |
|||||
|
doc/cli/changelog.md |
||||
@ -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. |
||||
@ -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 |
||||
@ -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) |
||||
@ -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) |
||||
|
}) |
||||
|
|
||||
|
})() |
||||
@ -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" %* |
||||
|
) |
||||
@ -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})) |
||||
|
} |
||||
@ -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" %* |
||||
|
) |
||||
@ -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" %* |
||||
|
) |
||||
@ -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) |
||||
|
}) |
||||
|
}) |
||||
@ -0,0 +1,2 @@ |
|||||
|
#!/usr/bin/env node
|
||||
|
require("./bin/npm-cli.js") |
||||
@ -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 |
||||
@ -0,0 +1 @@ |
|||||
|
owner.md |
||||
@ -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. |
||||
@ -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. |
||||
@ -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) |
||||
@ -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) |
||||
@ -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) |
||||
@ -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. |
||||
@ -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. |
||||
@ -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. |
||||
@ -0,0 +1 @@ |
|||||
|
ls.md |
||||
@ -0,0 +1 @@ |
|||||
|
config.md |
||||
@ -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. |
||||
@ -0,0 +1 @@ |
|||||
|
docs.md |
||||
@ -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) |
||||
@ -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. |
||||
@ -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 |
||||
@ -0,0 +1 @@ |
|||||
|
ls.md |
||||
@ -0,0 +1 @@ |
|||||
|
link.md |
||||
@ -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` |
||||
@ -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. |
||||
@ -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" |
||||
@ -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. |
||||
@ -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) |
||||
@ -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. |
||||
@ -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 |
||||
@ -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. |
||||
@ -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) |
||||
@ -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` |
||||
@ -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) |
||||
@ -0,0 +1 @@ |
|||||
|
uninstall.md |
||||
@ -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. |
||||
@ -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) |
||||
@ -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). |
||||
@ -0,0 +1 @@ |
|||||
|
config.md |
||||
@ -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. |
||||
@ -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. |
||||
@ -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 |
||||
@ -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. |
||||
@ -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. |
||||
@ -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. |
||||
@ -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. |
||||
@ -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. |
||||
@ -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. |
||||
@ -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. |
||||
@ -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 |
||||
@ -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) |
||||
@ -0,0 +1 @@ |
|||||
|
owner.md |
||||
@ -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) |
||||
@ -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) |
||||
@ -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) |
||||
@ -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) |
||||
@ -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) |
||||
@ -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) |
||||
@ -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) |
||||
@ -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) |
||||
@ -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) |
||||
@ -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) |
||||
@ -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) |
||||
@ -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) |
||||
@ -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) |
||||
@ -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) |
||||
@ -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) |
||||
@ -0,0 +1 @@ |
|||||
|
search.md |
||||
@ -0,0 +1,209 @@ |
|||||
|
npm-folders(1) -- Folder Structures Used by npm |
||||
|
=============================================== |
||||
|
|
||||
|
## DESCRIPTION |
||||
|
|
||||
|
npm puts various things on your computer. That's its job. |
||||
|
|
||||
|
This document will tell you what it puts where. |
||||
|
|
||||
|
### tl;dr |
||||
|
|
||||
|
* Local install (default): puts stuff in `./node_modules` of the current |
||||
|
package root. |
||||
|
* Global install (with `-g`): puts stuff in /usr/local or wherever node |
||||
|
is installed. |
||||
|
* Install it **locally** if you're going to `require()` it. |
||||
|
* Install it **globally** if you're going to run it on the command line. |
||||
|
* If you need both, then install it in both places, or use `npm link`. |
||||
|
|
||||
|
### prefix Configuration |
||||
|
|
||||
|
The `prefix` config defaults to the location where node is installed. |
||||
|
On most systems, this is `/usr/local`, and most of the time is the same |
||||
|
as node's `process.installPrefix`. |
||||
|
|
||||
|
On windows, this is the exact location of the node.exe binary. On Unix |
||||
|
systems, it's one level up, since node is typically installed at |
||||
|
`{prefix}/bin/node` rather than `{prefix}/node.exe`. |
||||
|
|
||||
|
When the `global` flag is set, npm installs things into this prefix. |
||||
|
When it is not set, it uses the root of the current package, or the |
||||
|
current working directory if not in a package already. |
||||
|
|
||||
|
### Node Modules |
||||
|
|
||||
|
Packages are dropped into the `node_modules` folder under the `prefix`. |
||||
|
When installing locally, this means that you can |
||||
|
`require("packagename")` to load its main module, or |
||||
|
`require("packagename/lib/path/to/sub/module")` to load other modules. |
||||
|
|
||||
|
Global installs on Unix systems go to `{prefix}/lib/node_modules`. |
||||
|
Global installs on Windows go to `{prefix}/node_modules` (that is, no |
||||
|
`lib` folder.) |
||||
|
|
||||
|
If you wish to `require()` a package, then install it locally. |
||||
|
|
||||
|
### Executables |
||||
|
|
||||
|
When in global mode, executables are linked into `{prefix}/bin` on Unix, |
||||
|
or directly into `{prefix}` on Windows. |
||||
|
|
||||
|
When in local mode, executables are linked into |
||||
|
`./node_modules/.bin` so that they can be made available to scripts run |
||||
|
through npm. (For example, so that a test runner will be in the path |
||||
|
when you run `npm test`.) |
||||
|
|
||||
|
### Man Pages |
||||
|
|
||||
|
When in global mode, man pages are linked into `{prefix}/share/man`. |
||||
|
|
||||
|
When in local mode, man pages are not installed. |
||||
|
|
||||
|
Man pages are not installed on Windows systems. |
||||
|
|
||||
|
### Cache |
||||
|
|
||||
|
See `npm-cache(1)`. Cache files are stored in `~/.npm` on Posix, or |
||||
|
`~/npm-cache` on Windows. |
||||
|
|
||||
|
This is controlled by the `cache` configuration param. |
||||
|
|
||||
|
### Temp Files |
||||
|
|
||||
|
Temporary files are stored by default in the folder specified by the |
||||
|
`tmp` config, which defaults to the TMPDIR, TMP, or TEMP environment |
||||
|
variables, or `/tmp` on Unix and `c:\windows\temp` on Windows. |
||||
|
|
||||
|
Temp files are given a unique folder under this root for each run of the |
||||
|
program, and are deleted upon successful exit. |
||||
|
|
||||
|
## More Information |
||||
|
|
||||
|
When installing locally, npm first tries to find an appropriate |
||||
|
`prefix` folder. This is so that `npm install foo@1.2.3` will install |
||||
|
to the sensible root of your package, even if you happen to have `cd`ed |
||||
|
into some other folder. |
||||
|
|
||||
|
Starting at the $PWD, npm will walk up the folder tree checking for a |
||||
|
folder that contains either a `package.json` file, or a `node_modules` |
||||
|
folder. If such a thing is found, then that is treated as the effective |
||||
|
"current directory" for the purpose of running npm commands. (This |
||||
|
behavior is inspired by and similar to git's .git-folder seeking |
||||
|
logic when running git commands in a working dir.) |
||||
|
|
||||
|
If no package root is found, then the current folder is used. |
||||
|
|
||||
|
When you run `npm install foo@1.2.3`, then the package is loaded into |
||||
|
the cache, and then unpacked into `./node_modules/foo`. Then, any of |
||||
|
foo's dependencies are similarly unpacked into |
||||
|
`./node_modules/foo/node_modules/...`. |
||||
|
|
||||
|
Any bin files are symlinked to `./node_modules/.bin/`, so that they may |
||||
|
be found by npm scripts when necessary. |
||||
|
|
||||
|
### Global Installation |
||||
|
|
||||
|
If the `global` configuration is set to true, then npm will |
||||
|
install packages "globally". |
||||
|
|
||||
|
For global installation, packages are installed roughly the same way, |
||||
|
but using the folders described above. |
||||
|
|
||||
|
### Cycles, Conflicts, and Folder Parsimony |
||||
|
|
||||
|
Cycles are handled using the property of node's module system that it |
||||
|
walks up the directories looking for `node_modules` folders. So, at every |
||||
|
stage, if a package is already installed in an ancestor `node_modules` |
||||
|
folder, then it is not installed at the current location. |
||||
|
|
||||
|
Consider the case above, where `foo -> bar -> baz`. Imagine if, in |
||||
|
addition to that, baz depended on bar, so you'd have: |
||||
|
`foo -> bar -> baz -> bar -> baz ...`. However, since the folder |
||||
|
structure is: `foo/node_modules/bar/node_modules/baz`, there's no need to |
||||
|
put another copy of bar into `.../baz/node_modules`, since when it calls |
||||
|
require("bar"), it will get the copy that is installed in |
||||
|
`foo/node_modules/bar`. |
||||
|
|
||||
|
This shortcut is only used if the exact same |
||||
|
version would be installed in multiple nested `node_modules` folders. It |
||||
|
is still possible to have `a/node_modules/b/node_modules/a` if the two |
||||
|
"a" packages are different versions. However, without repeating the |
||||
|
exact same package multiple times, an infinite regress will always be |
||||
|
prevented. |
||||
|
|
||||
|
Another optimization can be made by installing dependencies at the |
||||
|
highest level possible, below the localized "target" folder. |
||||
|
|
||||
|
#### Example |
||||
|
|
||||
|
Consider this dependency graph: |
||||
|
|
||||
|
foo |
||||
|
+-- blerg@1.2.5 |
||||
|
+-- bar@1.2.3 |
||||
|
| +-- blerg@1.x (latest=1.3.7) |
||||
|
| +-- baz@2.x |
||||
|
| | `-- quux@3.x |
||||
|
| | `-- bar@1.2.3 (cycle) |
||||
|
| `-- asdf@* |
||||
|
`-- baz@1.2.3 |
||||
|
`-- quux@3.x |
||||
|
`-- bar |
||||
|
|
||||
|
In this case, we might expect a folder structure like this: |
||||
|
|
||||
|
foo |
||||
|
+-- node_modules |
||||
|
+-- blerg (1.2.5) <---[A] |
||||
|
+-- bar (1.2.3) <---[B] |
||||
|
| +-- node_modules |
||||
|
| | `-- baz (2.0.2) <---[C] |
||||
|
| | `-- node_modules |
||||
|
| | `-- quux (3.2.0) |
||||
|
| `-- asdf (2.3.4) |
||||
|
`-- baz (1.2.3) <---[D] |
||||
|
`-- node_modules |
||||
|
`-- quux (3.2.0) <---[E] |
||||
|
|
||||
|
Since foo depends directly on bar@1.2.3 and baz@1.2.3, those are |
||||
|
installed in foo's `node_modules` folder. |
||||
|
|
||||
|
Even though the latest copy of blerg is 1.3.7, foo has a specific |
||||
|
dependency on version 1.2.5. So, that gets installed at [A]. Since the |
||||
|
parent installation of blerg satisfie's bar's dependency on blerg@1.x, |
||||
|
it does not install another copy under [B]. |
||||
|
|
||||
|
Bar [B] also has dependencies on baz and asdf, so those are installed in |
||||
|
bar's `node_modules` folder. Because it depends on `baz@2.x`, it cannot |
||||
|
re-use the `baz@1.2.3` installed in the parent `node_modules` folder [D], |
||||
|
and must install its own copy [C]. |
||||
|
|
||||
|
Underneath bar, the `baz->quux->bar` dependency creates a cycle. |
||||
|
However, because `bar` is already in `quux`'s ancestry [B], it does not |
||||
|
unpack another copy of bar into that folder. |
||||
|
|
||||
|
Underneath `foo->baz` [D], quux's [E] folder tree is empty, because its |
||||
|
dependency on bar is satisfied by the parent folder copy installed at [B]. |
||||
|
|
||||
|
For a graphical breakdown of what is installed where, use `npm ls`. |
||||
|
|
||||
|
### Publishing |
||||
|
|
||||
|
Upon publishing, npm will look in the `node_modules` folder. If any of |
||||
|
the items there are not in the `bundledDependencies` array, then they will |
||||
|
not be included in the package tarball. |
||||
|
|
||||
|
This allows a package maintainer to install all of their dependencies |
||||
|
(and dev dependencies) locally, but only re-publish those items that |
||||
|
cannot be found elsewhere. See `npm-json(1)` for more information. |
||||
|
|
||||
|
## SEE ALSO |
||||
|
|
||||
|
* npm-faq(1) |
||||
|
* npm-json(1) |
||||
|
* npm-install(1) |
||||
|
* npm-pack(1) |
||||
|
* npm-cache(1) |
||||
|
* npm-config(1) |
||||
|
* npm-publish(1) |
||||
@ -0,0 +1 @@ |
|||||
|
config.md |
||||
@ -0,0 +1 @@ |
|||||
|
folders.md |
||||
@ -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) |
||||
@ -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) |
||||
@ -0,0 +1 @@ |
|||||
|
docs.md |
||||
@ -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) |
||||
@ -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) |
||||
@ -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) |
||||
@ -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) |
||||
@ -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) |
||||
@ -0,0 +1 @@ |
|||||
|
link.md |
||||
@ -0,0 +1 @@ |
|||||
|
list.md |
||||
Some files were not shown because too many files changed in this diff
Loading…
Reference in new issue