From: isaacs Date: Fri, 12 Jul 2013 15:55:57 +0000 (-0700) Subject: npm: Upgrade to 1.3.3 X-Git-Tag: v0.11.4~1^2~1 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=ff8a4058bfac4f360992cfe7adf04f910282cedc;p=platform%2Fupstream%2Fnodejs.git npm: Upgrade to 1.3.3 --- diff --git a/deps/npm/Makefile b/deps/npm/Makefile index 61251fbb2..01228c1cd 100644 --- a/deps/npm/Makefile +++ b/deps/npm/Makefile @@ -1,31 +1,57 @@ +# vim: set softtabstop=2 shiftwidth=2: SHELL = bash markdowns = $(shell find doc -name '*.md' | grep -v 'index') README.md +html_docdeps = html/dochead.html \ + html/docfoot.html \ + html/docfoot-script.html \ + scripts/doc-build.sh \ + package.json + 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 + man/man1/npm-README.1 api_mandocs = $(shell find doc/api -name '*.md' \ |sed 's|.md|.3|g' \ |sed 's|doc/api/|man/man3/|g' ) +files_mandocs = $(shell find doc/files -name '*.md' \ + |sed 's|.md|.5|g' \ + |sed 's|doc/files/|man/man5/|g' ) \ + man/man5/npm-json.5 \ + man/man5/npm-global.5 + +misc_mandocs = $(shell find doc/misc -name '*.md' \ + |sed 's|.md|.7|g' \ + |sed 's|doc/misc/|man/man7/|g' ) \ + man/man7/index.7 + 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 + |sed 's|doc/cli/|html/doc/cli/|g' ) \ + html/doc/README.html api_htmldocs = $(shell find doc/api -name '*.md' \ |sed 's|.md|.html|g' \ - |sed 's|doc/api/|html/api/|g' ) + |sed 's|doc/api/|html/doc/api/|g' ) + +files_htmldocs = $(shell find doc/files -name '*.md' \ + |sed 's|.md|.html|g' \ + |sed 's|doc/files/|html/doc/files/|g' ) \ + html/doc/files/npm-json.html \ + html/doc/files/npm-global.html -mandocs = $(api_mandocs) $(cli_mandocs) +misc_htmldocs = $(shell find doc/misc -name '*.md' \ + |sed 's|.md|.html|g' \ + |sed 's|doc/misc/|html/doc/misc/|g' ) \ + html/doc/index.html -htmldocs = $(api_htmldocs) $(cli_htmldocs) +mandocs = $(api_mandocs) $(cli_mandocs) $(files_mandocs) $(misc_mandocs) + +htmldocs = $(api_htmldocs) $(cli_htmldocs) $(files_htmldocs) $(misc_htmldocs) all: doc @@ -58,17 +84,14 @@ 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 + .building_ronn \ + html/doc \ + html/api \ + man/man* # use `npm install ronn` for this to work. -man/man1/README.1: README.md scripts/doc-build.sh package.json +man/man1/npm-README.1: README.md scripts/doc-build.sh package.json + @[ -d man/man1 ] || mkdir -p man/man1 scripts/doc-build.sh $< $@ man/man1/%.1: doc/cli/%.md scripts/doc-build.sh package.json @@ -79,17 +102,54 @@ 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 +man/man5/npm-json.5: man/man5/package.json.5 + cp $< $@ + +man/man5/npm-global.5: man/man5/npm-folders.5 + cp $< $@ + +man/man5/%.5: doc/files/%.md scripts/doc-build.sh package.json + @[ -d man/man5 ] || mkdir -p man/man5 scripts/doc-build.sh $< $@ -html/doc/%.html: doc/cli/%.md html/dochead.html html/docfoot.html scripts/doc-build.sh package.json +doc/misc/npm-index.md: scripts/index-build.js package.json + node scripts/index-build.js > $@ + +html/doc/index.html: doc/misc/npm-index.md $(html_docdeps) + @[ -d html/doc ] || mkdir -p html/doc scripts/doc-build.sh $< $@ -html/api/%.html: doc/api/%.md html/dochead.html html/docfoot.html scripts/doc-build.sh package.json +man/man7/%.7: doc/misc/%.md scripts/doc-build.sh package.json + @[ -d man/man7 ] || mkdir -p man/man7 scripts/doc-build.sh $< $@ -doc/cli/index.md: $(markdowns) scripts/index-build.js scripts/doc-build.sh package.json - node scripts/index-build.js > $@ +html/doc/README.html: README.md $(html_docdeps) + @[ -d html/doc ] || mkdir -p html/doc + scripts/doc-build.sh $< $@ + +html/doc/cli/%.html: doc/cli/%.md $(html_docdeps) + @[ -d html/doc/cli ] || mkdir -p html/doc/cli + scripts/doc-build.sh $< $@ + +html/doc/api/%.html: doc/api/%.md $(html_docdeps) + @[ -d html/doc/api ] || mkdir -p html/doc/api + scripts/doc-build.sh $< $@ + +html/doc/files/npm-json.html: html/doc/files/package.json.html + cp $< $@ +html/doc/files/npm-global.html: html/doc/files/npm-folders.html + cp $< $@ + +html/doc/files/%.html: doc/files/%.md $(html_docdeps) + @[ -d html/doc/files ] || mkdir -p html/doc/files + scripts/doc-build.sh $< $@ + +html/doc/misc/%.html: doc/misc/%.md $(html_docdeps) + @[ -d html/doc/misc ] || mkdir -p html/doc/misc + scripts/doc-build.sh $< $@ + + + node_modules/.bin/ronn: node cli.js install ronn @@ -114,18 +174,36 @@ publish: link doc docpublish: doc-publish doc-publish: doc + # legacy urls + for f in $$(find html/doc/{cli,files,misc}/ -name '*.html'); do \ + j=$$(basename $$f | sed 's|^npm-||g'); \ + if ! [ -f html/doc/$$j ] && [ $$j != README.html ] && [ $$j != index.html ]; then \ + perl -pi -e 's/ href="\.\.\// href="/g' <$$f >html/doc/$$j; \ + fi; \ + done + mkdir -p html/api + for f in $$(find html/doc/api/ -name '*.html'); do \ + j=$$(basename $$f | sed 's|^npm-||g'); \ + perl -pi -e 's/ href="\.\.\// href="/g' <$$f >html/api/$$j; \ + done rsync -vazu --stats --no-implied-dirs --delete \ - html/doc/ \ - node@npmjs.org:/home/node/npm-www/doc - rsync -vazu --stats --no-implied-dirs --delete \ - html/api/ \ - node@npmjs.org:/home/node/npm-www/api + html/doc/* \ + node@npmjs.org:/home/node/npm-www/doc rsync -vazu --stats --no-implied-dirs --delete \ - html/static/webfonts/ \ - node@npmjs.org:/home/node/npm-www/static/webfonts + html/static/webfonts/ \ + node@npmjs.org:/home/node/npm-www/static/webfonts rsync -vazu --stats --no-implied-dirs --delete \ - html/static/style.css \ - node@npmjs.org:/home/node/npm-www/static/ + html/static/style.css \ + node@npmjs.org:/home/node/npm-www/static/ + #cleanup + rm -rf html/api + for f in html/doc/*.html; do \ + case $$f in \ + html/doc/README.html) continue ;; \ + html/doc/index.html) continue ;; \ + *) rm $$f ;; \ + esac; \ + done zip-publish: release scp release/* node@nodejs.org:dist/npm/ diff --git a/deps/npm/doc/api/bin.md b/deps/npm/doc/api/bin.md deleted file mode 100644 index f3dc48286..000000000 --- a/deps/npm/doc/api/bin.md +++ /dev/null @@ -1,13 +0,0 @@ -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. diff --git a/deps/npm/doc/api/bugs.md b/deps/npm/doc/api/bugs.md deleted file mode 100644 index cc4db8f9e..000000000 --- a/deps/npm/doc/api/bugs.md +++ /dev/null @@ -1,19 +0,0 @@ -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. diff --git a/deps/npm/doc/api/commands.md b/deps/npm/doc/api/commands.md deleted file mode 100644 index eb7545639..000000000 --- a/deps/npm/doc/api/commands.md +++ /dev/null @@ -1,22 +0,0 @@ -npm-commands(3) -- npm commands -=============================== - -## SYNOPSIS - - npm.commands[](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-` for command-line -usage, or `man 3 npm-` for programmatic usage. - -## SEE ALSO - -* npm-index(1) diff --git a/deps/npm/doc/api/config.md b/deps/npm/doc/api/config.md deleted file mode 100644 index 7ae227428..000000000 --- a/deps/npm/doc/api/config.md +++ /dev/null @@ -1,45 +0,0 @@ -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) diff --git a/deps/npm/doc/api/deprecate.md b/deps/npm/doc/api/deprecate.md deleted file mode 100644 index 0608d3864..000000000 --- a/deps/npm/doc/api/deprecate.md +++ /dev/null @@ -1,34 +0,0 @@ -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. - -To un-deprecate a package, specify an empty string (`""`) for the `message` argument. - -## SEE ALSO - -* npm-publish(3) -* npm-unpublish(3) -* npm-registry(1) diff --git a/deps/npm/doc/api/docs.md b/deps/npm/doc/api/docs.md deleted file mode 100644 index 2c5fc5e63..000000000 --- a/deps/npm/doc/api/docs.md +++ /dev/null @@ -1,19 +0,0 @@ -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. diff --git a/deps/npm/doc/api/edit.md b/deps/npm/doc/api/edit.md deleted file mode 100644 index b13fbb857..000000000 --- a/deps/npm/doc/api/edit.md +++ /dev/null @@ -1,24 +0,0 @@ -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. diff --git a/deps/npm/doc/api/explore.md b/deps/npm/doc/api/explore.md deleted file mode 100644 index a239f3df3..000000000 --- a/deps/npm/doc/api/explore.md +++ /dev/null @@ -1,18 +0,0 @@ -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 ` 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. diff --git a/deps/npm/doc/api/help-search.md b/deps/npm/doc/api/help-search.md deleted file mode 100644 index 5c00cfc17..000000000 --- a/deps/npm/doc/api/help-search.md +++ /dev/null @@ -1,30 +0,0 @@ -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. diff --git a/deps/npm/doc/api/init.md b/deps/npm/doc/api/init.md deleted file mode 100644 index 5afc11b3b..000000000 --- a/deps/npm/doc/api/init.md +++ /dev/null @@ -1,29 +0,0 @@ -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) diff --git a/deps/npm/doc/api/install.md b/deps/npm/doc/api/install.md deleted file mode 100644 index 12f665a76..000000000 --- a/deps/npm/doc/api/install.md +++ /dev/null @@ -1,19 +0,0 @@ -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. diff --git a/deps/npm/doc/api/link.md b/deps/npm/doc/api/link.md deleted file mode 100644 index ad8cefcab..000000000 --- a/deps/npm/doc/api/link.md +++ /dev/null @@ -1,33 +0,0 @@ -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 diff --git a/deps/npm/doc/api/load.md b/deps/npm/doc/api/load.md deleted file mode 100644 index a95a6b295..000000000 --- a/deps/npm/doc/api/load.md +++ /dev/null @@ -1,26 +0,0 @@ -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` diff --git a/deps/npm/doc/api/ls.md b/deps/npm/doc/api/ls.md deleted file mode 100644 index ed890ff14..000000000 --- a/deps/npm/doc/api/ls.md +++ /dev/null @@ -1,56 +0,0 @@ -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. - -Callback is provided an error if one occurred, the full data about which -packages are installed and which dependencies they will receive, and a -"lite" data object which just shows which versions are installed where. -Note that the full data object is a circular structure, so care must be -taken if it is serialized to JSON. - -## 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. diff --git a/deps/npm/doc/api/npm-bin.md b/deps/npm/doc/api/npm-bin.md new file mode 100644 index 000000000..f3dc48286 --- /dev/null +++ b/deps/npm/doc/api/npm-bin.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. diff --git a/deps/npm/doc/api/npm-bugs.md b/deps/npm/doc/api/npm-bugs.md new file mode 100644 index 000000000..cc4db8f9e --- /dev/null +++ b/deps/npm/doc/api/npm-bugs.md @@ -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. diff --git a/deps/npm/doc/api/npm-commands.md b/deps/npm/doc/api/npm-commands.md new file mode 100644 index 000000000..36dcfd8d6 --- /dev/null +++ b/deps/npm/doc/api/npm-commands.md @@ -0,0 +1,22 @@ +npm-commands(3) -- npm commands +=============================== + +## SYNOPSIS + + npm.commands[](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-` for command-line +usage, or `man 3 npm-` for programmatic usage. + +## SEE ALSO + +* npm-index(7) diff --git a/deps/npm/doc/api/npm-config.md b/deps/npm/doc/api/npm-config.md new file mode 100644 index 000000000..7ae227428 --- /dev/null +++ b/deps/npm/doc/api/npm-config.md @@ -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) diff --git a/deps/npm/doc/api/npm-deprecate.md b/deps/npm/doc/api/npm-deprecate.md new file mode 100644 index 000000000..200fb9c30 --- /dev/null +++ b/deps/npm/doc/api/npm-deprecate.md @@ -0,0 +1,34 @@ +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. + +To un-deprecate a package, specify an empty string (`""`) for the `message` argument. + +## SEE ALSO + +* npm-publish(3) +* npm-unpublish(3) +* npm-registry(7) diff --git a/deps/npm/doc/api/npm-docs.md b/deps/npm/doc/api/npm-docs.md new file mode 100644 index 000000000..2c5fc5e63 --- /dev/null +++ b/deps/npm/doc/api/npm-docs.md @@ -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. diff --git a/deps/npm/doc/api/npm-edit.md b/deps/npm/doc/api/npm-edit.md new file mode 100644 index 000000000..b13fbb857 --- /dev/null +++ b/deps/npm/doc/api/npm-edit.md @@ -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. diff --git a/deps/npm/doc/api/npm-explore.md b/deps/npm/doc/api/npm-explore.md new file mode 100644 index 000000000..a239f3df3 --- /dev/null +++ b/deps/npm/doc/api/npm-explore.md @@ -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 ` 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. diff --git a/deps/npm/doc/api/npm-help-search.md b/deps/npm/doc/api/npm-help-search.md new file mode 100644 index 000000000..5c00cfc17 --- /dev/null +++ b/deps/npm/doc/api/npm-help-search.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. diff --git a/deps/npm/doc/api/npm-init.md b/deps/npm/doc/api/npm-init.md new file mode 100644 index 000000000..9b75bf791 --- /dev/null +++ b/deps/npm/doc/api/npm-init.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 + +package.json(5) diff --git a/deps/npm/doc/api/npm-install.md b/deps/npm/doc/api/npm-install.md new file mode 100644 index 000000000..12f665a76 --- /dev/null +++ b/deps/npm/doc/api/npm-install.md @@ -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. diff --git a/deps/npm/doc/api/npm-link.md b/deps/npm/doc/api/npm-link.md new file mode 100644 index 000000000..ad8cefcab --- /dev/null +++ b/deps/npm/doc/api/npm-link.md @@ -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 diff --git a/deps/npm/doc/api/npm-load.md b/deps/npm/doc/api/npm-load.md new file mode 100644 index 000000000..a95a6b295 --- /dev/null +++ b/deps/npm/doc/api/npm-load.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` diff --git a/deps/npm/doc/api/npm-ls.md b/deps/npm/doc/api/npm-ls.md new file mode 100644 index 000000000..ed890ff14 --- /dev/null +++ b/deps/npm/doc/api/npm-ls.md @@ -0,0 +1,56 @@ +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. + +Callback is provided an error if one occurred, the full data about which +packages are installed and which dependencies they will receive, and a +"lite" data object which just shows which versions are installed where. +Note that the full data object is a circular structure, so care must be +taken if it is serialized to JSON. + +## 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. diff --git a/deps/npm/doc/api/npm-outdated.md b/deps/npm/doc/api/npm-outdated.md new file mode 100644 index 000000000..89f4cf6fa --- /dev/null +++ b/deps/npm/doc/api/npm-outdated.md @@ -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. diff --git a/deps/npm/doc/api/npm-owner.md b/deps/npm/doc/api/npm-owner.md new file mode 100644 index 000000000..71fcccff5 --- /dev/null +++ b/deps/npm/doc/api/npm-owner.md @@ -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(7) diff --git a/deps/npm/doc/api/npm-pack.md b/deps/npm/doc/api/npm-pack.md new file mode 100644 index 000000000..cb339c0c4 --- /dev/null +++ b/deps/npm/doc/api/npm-pack.md @@ -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 `-.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. diff --git a/deps/npm/doc/api/npm-prefix.md b/deps/npm/doc/api/npm-prefix.md new file mode 100644 index 000000000..806dd4b6c --- /dev/null +++ b/deps/npm/doc/api/npm-prefix.md @@ -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 diff --git a/deps/npm/doc/api/npm-prune.md b/deps/npm/doc/api/npm-prune.md new file mode 100644 index 000000000..2a4f17748 --- /dev/null +++ b/deps/npm/doc/api/npm-prune.md @@ -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. diff --git a/deps/npm/doc/api/npm-publish.md b/deps/npm/doc/api/npm-publish.md new file mode 100644 index 000000000..6871dafb8 --- /dev/null +++ b/deps/npm/doc/api/npm-publish.md @@ -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: + +* ``: + A folder containing a package.json file + +* ``: + 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(7) +* npm-adduser(1) +* npm-owner(3) diff --git a/deps/npm/doc/api/npm-rebuild.md b/deps/npm/doc/api/npm-rebuild.md new file mode 100644 index 000000000..8b8989806 --- /dev/null +++ b/deps/npm/doc/api/npm-rebuild.md @@ -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` diff --git a/deps/npm/doc/api/npm-restart.md b/deps/npm/doc/api/npm-restart.md new file mode 100644 index 000000000..c40704438 --- /dev/null +++ b/deps/npm/doc/api/npm-restart.md @@ -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) diff --git a/deps/npm/doc/api/npm-root.md b/deps/npm/doc/api/npm-root.md new file mode 100644 index 000000000..1c3ab5640 --- /dev/null +++ b/deps/npm/doc/api/npm-root.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. diff --git a/deps/npm/doc/api/npm-run-script.md b/deps/npm/doc/api/npm-run-script.md new file mode 100644 index 000000000..91ad95351 --- /dev/null +++ b/deps/npm/doc/api/npm-run-script.md @@ -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(7) +* npm-test(3) +* npm-start(3) +* npm-restart(3) +* npm-stop(3) diff --git a/deps/npm/doc/api/npm-search.md b/deps/npm/doc/api/npm-search.md new file mode 100644 index 000000000..30651d76a --- /dev/null +++ b/deps/npm/doc/api/npm-search.md @@ -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). diff --git a/deps/npm/doc/api/npm-shrinkwrap.md b/deps/npm/doc/api/npm-shrinkwrap.md new file mode 100644 index 000000000..6584d6a0d --- /dev/null +++ b/deps/npm/doc/api/npm-shrinkwrap.md @@ -0,0 +1,20 @@ +npm-shrinkwrap(3) -- programmatically generate package shrinkwrap file +==================================================== + +## SYNOPSIS + + npm.commands.shrinkwrap(args, [silent,] callback) + +## DESCRIPTION + +This acts much the same ways as shrinkwrapping on the command-line. + +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. + +If the 'silent' parameter is set to true, nothing will be output to the screen, +but the shrinkwrap file will still be written. + +Finally, 'callback' is a function that will be called when the shrinkwrap has +been saved. diff --git a/deps/npm/doc/api/npm-start.md b/deps/npm/doc/api/npm-start.md new file mode 100644 index 000000000..74491146a --- /dev/null +++ b/deps/npm/doc/api/npm-start.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. diff --git a/deps/npm/doc/api/npm-stop.md b/deps/npm/doc/api/npm-stop.md new file mode 100644 index 000000000..0f8333d35 --- /dev/null +++ b/deps/npm/doc/api/npm-stop.md @@ -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. diff --git a/deps/npm/doc/api/npm-submodule.md b/deps/npm/doc/api/npm-submodule.md new file mode 100644 index 000000000..2d8bafaa3 --- /dev/null +++ b/deps/npm/doc/api/npm-submodule.md @@ -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/`. + +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 -- npm install` to install the +dependencies into the submodule folder. + +## SEE ALSO + +* npm help json +* git help submodule diff --git a/deps/npm/doc/api/npm-tag.md b/deps/npm/doc/api/npm-tag.md new file mode 100644 index 000000000..b5a3d7faa --- /dev/null +++ b/deps/npm/doc/api/npm-tag.md @@ -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. diff --git a/deps/npm/doc/api/npm-test.md b/deps/npm/doc/api/npm-test.md new file mode 100644 index 000000000..bc48dcc35 --- /dev/null +++ b/deps/npm/doc/api/npm-test.md @@ -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. diff --git a/deps/npm/doc/api/npm-uninstall.md b/deps/npm/doc/api/npm-uninstall.md new file mode 100644 index 000000000..4505295b3 --- /dev/null +++ b/deps/npm/doc/api/npm-uninstall.md @@ -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. diff --git a/deps/npm/doc/api/npm-unpublish.md b/deps/npm/doc/api/npm-unpublish.md new file mode 100644 index 000000000..6cbc5c1f3 --- /dev/null +++ b/deps/npm/doc/api/npm-unpublish.md @@ -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. diff --git a/deps/npm/doc/api/npm-update.md b/deps/npm/doc/api/npm-update.md new file mode 100644 index 000000000..bf02fd3c8 --- /dev/null +++ b/deps/npm/doc/api/npm-update.md @@ -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. diff --git a/deps/npm/doc/api/npm-version.md b/deps/npm/doc/api/npm-version.md new file mode 100644 index 000000000..bd40102c4 --- /dev/null +++ b/deps/npm/doc/api/npm-version.md @@ -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. diff --git a/deps/npm/doc/api/npm-view.md b/deps/npm/doc/api/npm-view.md new file mode 100644 index 000000000..fd0076c96 --- /dev/null +++ b/deps/npm/doc/api/npm-view.md @@ -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: + + { : + { : + , ... } + , ... } + +corresponding to the list of fields selected. diff --git a/deps/npm/doc/api/npm-whoami.md b/deps/npm/doc/api/npm-whoami.md new file mode 100644 index 000000000..598a1ab1a --- /dev/null +++ b/deps/npm/doc/api/npm-whoami.md @@ -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 diff --git a/deps/npm/doc/api/npm.md b/deps/npm/doc/api/npm.md index 8c7a8168e..e099320f4 100644 --- a/deps/npm/doc/api/npm.md +++ b/deps/npm/doc/api/npm.md @@ -30,11 +30,11 @@ If you provide `configObject` as an object hash of top-level configs, they override the values stored in the various config locations. In the npm command line client, this set of configs is parsed from the command line options. Additional configuration -params are loaded from two configuration files. See `npm-config(1)` -for more information. +params are loaded from two configuration files. See `npm-config(1)`, +`npm-config(7)`, and `npmrc(5)` for more information. After that, each of the functions are accessible in the -commands object: `npm.commands.`. See `npm-index(1)` for a list of +commands object: `npm.commands.`. See `npm-index(7)` for a list of all possible commands. All commands on the command object take an **array** of positional argument diff --git a/deps/npm/doc/api/outdated.md b/deps/npm/doc/api/outdated.md deleted file mode 100644 index 89f4cf6fa..000000000 --- a/deps/npm/doc/api/outdated.md +++ /dev/null @@ -1,13 +0,0 @@ -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. diff --git a/deps/npm/doc/api/owner.md b/deps/npm/doc/api/owner.md deleted file mode 100644 index de203c072..000000000 --- a/deps/npm/doc/api/owner.md +++ /dev/null @@ -1,31 +0,0 @@ -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) diff --git a/deps/npm/doc/api/pack.md b/deps/npm/doc/api/pack.md deleted file mode 100644 index cb339c0c4..000000000 --- a/deps/npm/doc/api/pack.md +++ /dev/null @@ -1,19 +0,0 @@ -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 `-.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. diff --git a/deps/npm/doc/api/prefix.md b/deps/npm/doc/api/prefix.md deleted file mode 100644 index 806dd4b6c..000000000 --- a/deps/npm/doc/api/prefix.md +++ /dev/null @@ -1,15 +0,0 @@ -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 diff --git a/deps/npm/doc/api/prune.md b/deps/npm/doc/api/prune.md deleted file mode 100644 index 2a4f17748..000000000 --- a/deps/npm/doc/api/prune.md +++ /dev/null @@ -1,17 +0,0 @@ -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. diff --git a/deps/npm/doc/api/publish.md b/deps/npm/doc/api/publish.md deleted file mode 100644 index a743303f8..000000000 --- a/deps/npm/doc/api/publish.md +++ /dev/null @@ -1,30 +0,0 @@ -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: - -* ``: - A folder containing a package.json file - -* ``: - 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) diff --git a/deps/npm/doc/api/rebuild.md b/deps/npm/doc/api/rebuild.md deleted file mode 100644 index 8b8989806..000000000 --- a/deps/npm/doc/api/rebuild.md +++ /dev/null @@ -1,16 +0,0 @@ -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` diff --git a/deps/npm/doc/api/restart.md b/deps/npm/doc/api/restart.md deleted file mode 100644 index c40704438..000000000 --- a/deps/npm/doc/api/restart.md +++ /dev/null @@ -1,22 +0,0 @@ -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) diff --git a/deps/npm/doc/api/root.md b/deps/npm/doc/api/root.md deleted file mode 100644 index 1c3ab5640..000000000 --- a/deps/npm/doc/api/root.md +++ /dev/null @@ -1,15 +0,0 @@ -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. diff --git a/deps/npm/doc/api/run-script.md b/deps/npm/doc/api/run-script.md deleted file mode 100644 index f15900ecb..000000000 --- a/deps/npm/doc/api/run-script.md +++ /dev/null @@ -1,27 +0,0 @@ -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) diff --git a/deps/npm/doc/api/search.md b/deps/npm/doc/api/search.md deleted file mode 100644 index 30651d76a..000000000 --- a/deps/npm/doc/api/search.md +++ /dev/null @@ -1,35 +0,0 @@ -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). diff --git a/deps/npm/doc/api/shrinkwrap.md b/deps/npm/doc/api/shrinkwrap.md deleted file mode 100644 index 6584d6a0d..000000000 --- a/deps/npm/doc/api/shrinkwrap.md +++ /dev/null @@ -1,20 +0,0 @@ -npm-shrinkwrap(3) -- programmatically generate package shrinkwrap file -==================================================== - -## SYNOPSIS - - npm.commands.shrinkwrap(args, [silent,] callback) - -## DESCRIPTION - -This acts much the same ways as shrinkwrapping on the command-line. - -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. - -If the 'silent' parameter is set to true, nothing will be output to the screen, -but the shrinkwrap file will still be written. - -Finally, 'callback' is a function that will be called when the shrinkwrap has -been saved. diff --git a/deps/npm/doc/api/start.md b/deps/npm/doc/api/start.md deleted file mode 100644 index 74491146a..000000000 --- a/deps/npm/doc/api/start.md +++ /dev/null @@ -1,13 +0,0 @@ -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. diff --git a/deps/npm/doc/api/stop.md b/deps/npm/doc/api/stop.md deleted file mode 100644 index 0f8333d35..000000000 --- a/deps/npm/doc/api/stop.md +++ /dev/null @@ -1,13 +0,0 @@ -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. diff --git a/deps/npm/doc/api/submodule.md b/deps/npm/doc/api/submodule.md deleted file mode 100644 index 2d8bafaa3..000000000 --- a/deps/npm/doc/api/submodule.md +++ /dev/null @@ -1,28 +0,0 @@ -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/`. - -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 -- npm install` to install the -dependencies into the submodule folder. - -## SEE ALSO - -* npm help json -* git help submodule diff --git a/deps/npm/doc/api/tag.md b/deps/npm/doc/api/tag.md deleted file mode 100644 index b5a3d7faa..000000000 --- a/deps/npm/doc/api/tag.md +++ /dev/null @@ -1,23 +0,0 @@ -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. diff --git a/deps/npm/doc/api/test.md b/deps/npm/doc/api/test.md deleted file mode 100644 index bc48dcc35..000000000 --- a/deps/npm/doc/api/test.md +++ /dev/null @@ -1,16 +0,0 @@ -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. diff --git a/deps/npm/doc/api/uninstall.md b/deps/npm/doc/api/uninstall.md deleted file mode 100644 index 4505295b3..000000000 --- a/deps/npm/doc/api/uninstall.md +++ /dev/null @@ -1,16 +0,0 @@ -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. diff --git a/deps/npm/doc/api/unpublish.md b/deps/npm/doc/api/unpublish.md deleted file mode 100644 index 6cbc5c1f3..000000000 --- a/deps/npm/doc/api/unpublish.md +++ /dev/null @@ -1,20 +0,0 @@ -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. diff --git a/deps/npm/doc/api/update.md b/deps/npm/doc/api/update.md deleted file mode 100644 index bf02fd3c8..000000000 --- a/deps/npm/doc/api/update.md +++ /dev/null @@ -1,11 +0,0 @@ -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. diff --git a/deps/npm/doc/api/version.md b/deps/npm/doc/api/version.md deleted file mode 100644 index bd40102c4..000000000 --- a/deps/npm/doc/api/version.md +++ /dev/null @@ -1,18 +0,0 @@ -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. diff --git a/deps/npm/doc/api/view.md b/deps/npm/doc/api/view.md deleted file mode 100644 index fd0076c96..000000000 --- a/deps/npm/doc/api/view.md +++ /dev/null @@ -1,93 +0,0 @@ -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: - - { : - { : - , ... } - , ... } - -corresponding to the list of fields selected. diff --git a/deps/npm/doc/api/whoami.md b/deps/npm/doc/api/whoami.md deleted file mode 100644 index 598a1ab1a..000000000 --- a/deps/npm/doc/api/whoami.md +++ /dev/null @@ -1,15 +0,0 @@ -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 diff --git a/deps/npm/doc/cli/adduser.md b/deps/npm/doc/cli/adduser.md deleted file mode 100644 index 51aa6f6a3..000000000 --- a/deps/npm/doc/cli/adduser.md +++ /dev/null @@ -1,36 +0,0 @@ -npm-adduser(1) -- Add a registry user account -============================================= - -## SYNOPSIS - - npm adduser - -## DESCRIPTION - -Create or verify a user named `` 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 - -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) diff --git a/deps/npm/doc/cli/bin.md b/deps/npm/doc/cli/bin.md deleted file mode 100644 index 2c2e7c477..000000000 --- a/deps/npm/doc/cli/bin.md +++ /dev/null @@ -1,17 +0,0 @@ -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) diff --git a/deps/npm/doc/cli/bugs.md b/deps/npm/doc/cli/bugs.md deleted file mode 100644 index 45ee84b58..000000000 --- a/deps/npm/doc/cli/bugs.md +++ /dev/null @@ -1,38 +0,0 @@ -npm-bugs(1) -- Bugs for a package in a web browser maybe -======================================================== - -## SYNOPSIS - - npm bugs - -## 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"`, Windows: `"start"`, Others: `"xdg-open"` -* 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) diff --git a/deps/npm/doc/cli/build.md b/deps/npm/doc/cli/build.md deleted file mode 100644 index 978f4a6d6..000000000 --- a/deps/npm/doc/cli/build.md +++ /dev/null @@ -1,22 +0,0 @@ -npm-build(1) -- Build a package -=============================== - -## SYNOPSIS - - npm build - -* ``: - 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) diff --git a/deps/npm/doc/cli/bundle.md b/deps/npm/doc/cli/bundle.md deleted file mode 100644 index 69b3d83e4..000000000 --- a/deps/npm/doc/cli/bundle.md +++ /dev/null @@ -1,14 +0,0 @@ -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) diff --git a/deps/npm/doc/cli/cache.md b/deps/npm/doc/cli/cache.md deleted file mode 100644 index 1fa128ad4..000000000 --- a/deps/npm/doc/cli/cache.md +++ /dev/null @@ -1,70 +0,0 @@ -npm-cache(1) -- Manipulates packages cache -========================================== - -## SYNOPSIS - - npm cache add - npm cache add - npm cache add - npm cache add @ - - npm cache ls [] - - npm cache clean [] - -## 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) diff --git a/deps/npm/doc/cli/changelog.md b/deps/npm/doc/cli/changelog.md deleted file mode 100644 index 64feeacda..000000000 --- a/deps/npm/doc/cli/changelog.md +++ /dev/null @@ -1,80 +0,0 @@ -npm-changelog(1) -- Changes -=========================== - -## HISTORY - -### 1.1.3, 1.1.4 - -* Update request to support HTTPS-over-HTTP proxy tunneling -* Throw on undefined envs in config settings -* Update which to 1.0.5 -* Fix windows UNC busyloop in findPrefix -* Bundle nested bundleDependencies properly -* Alias adduser to add-user -* Doc updates (Christian Howe, Henrik Hodne, Andrew Lunny) -* ignore logfd/outfd streams in makeEnv() (Rod Vagg) -* shrinkwrap: Behave properly with url-installed deps -* install: Support --save with url install targets -* Support installing naked tars or single-file modules from urls etc. -* init: Don't add engines section -* Don't run make clean on rebuild -* Added missing unicode replacement (atomizer) - -### 1.1.2 - -Dave Pacheco (2): - add "npm shrinkwrap" - -Martin Cooper (1): - Fix #1753 Make a copy of the cached objects we'll modify. - -Tim Oxley (1): - correctly remove readme from default npm view command. - -Tyler Green (1): - fix #2187 set terminal columns to Infinity if 0 - -isaacs (19): - update minimatch - update request - Experimental: single-file modules - Fix #2172 Don't remove global mans uninstalling local pkgs - Add --versions flag to show the version of node as well - Support --json flag for ls output - update request to 2.9.151 - -### 1.1 -* Replace system tar dependency with a JS tar -* Continue to refine - -### 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) diff --git a/deps/npm/doc/cli/coding-style.md b/deps/npm/doc/cli/coding-style.md deleted file mode 100644 index 1aa3e80e2..000000000 --- a/deps/npm/doc/cli/coding-style.md +++ /dev/null @@ -1,181 +0,0 @@ -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. - -Note: this concerns npm's code not the specific packages at npmjs.org - -## Line Length - -Keep lines shorter than 80 characters. It's better for lines to be -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. - -## Logging - -Logging is done using the [npmlog](https://github.com/isaacs/npmlog) -utility. - -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. 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) diff --git a/deps/npm/doc/cli/completion.md b/deps/npm/doc/cli/completion.md deleted file mode 100644 index 48bc50fd8..000000000 --- a/deps/npm/doc/cli/completion.md +++ /dev/null @@ -1,29 +0,0 @@ -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) diff --git a/deps/npm/doc/cli/config.md b/deps/npm/doc/cli/config.md deleted file mode 100644 index 54133bec3..000000000 --- a/deps/npm/doc/cli/config.md +++ /dev/null @@ -1,882 +0,0 @@ -npm-config(1) -- Manage the npm configuration file -================================================== - -## SYNOPSIS - - npm config set [--global] - npm config get - npm config delete - npm config list - npm config edit - npm get - npm set [--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. -Environment variables can be replaced using `${VARIABLE_NAME}`. For example: - - prefix = ${HOME}/.npm-packages - -### Global config file - -`$PREFIX/etc/npmrc` (or the `globalconfig` param, if set above): -This file is an ini-file formatted list of `key = value` parameters. -Environment variables can be replaced as above. - -### 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` -* `-q`, `--quiet`: `--loglevel warn` -* `-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` -* `-desc`: `--description` -* `-S`: `--save` -* `-D`: `--save-dev` -* `-O`: `--save-optional` -* `-B`: `--save-bundle` -* `-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 `[@]:`. 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-links - -* Default: `true` -* Type: Boolean - -Tells npm to create symlinks (or `.cmd` shims on Windows) for package -executables. - -Set to false to have it not do this. This can be used to work around -the fact that some file systems don't support symlinks, even on -ostensibly Unix systems. - -### browser - -* Default: OS X: `"open"`, Windows: `"start"`, Others: `"xdg-open"` -* 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: `%APPDATA%\npm-cache`, Posix: `~/.npm` -* Type: path - -The location of npm's cache directory. See `npm-cache(1)` - -### cache-lock-stale - -* Default: 60000 (1 minute) -* Type: Number - -The number of ms before cache folder lockfiles are considered stale. - -### cache-lock-retries - -* Default: 10 -* Type: Number - -Number of times to retry to acquire a lock on cache folder lockfiles. - -### cache-lock-wait - -* Default: 10000 (10 seconds) -* Type: Number - -Number of ms to wait for cache lock files to expire. - -### cache-max - -* Default: Infinity -* Type: Number - -The maximum time (in seconds) to keep items in the registry cache before -re-checking against the registry. - -Note that no purging is done unless the `npm cache clean` command is -explicitly used, and that only GET requests use the cache. - -### cache-min - -* Default: 10 -* Type: Number - -The minimum time (in seconds) to keep items in the registry cache before -re-checking against the registry. - -Note that no purging is done unless the `npm cache clean` command is -explicitly used, and that only GET requests use the cache. - -### 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. - -### coverage - -* Default: false -* Type: Boolean - -A flag to tell test-harness to run with their coverage options enabled, -if they respond to the `npm_config_coverage` environment variable. - -### 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`. - -### engine-strict - -* Default: false -* Type: Boolean - -If set to true, then npm will stubbornly refuse to install (or even -consider installing) any package that claims to not be compatible with -the current Node.js version. - -### 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. - -### fetch-retries - -* Default: 2 -* Type: Number - -The "retries" config for the `retry` module to use when fetching -packages from the registry. - -### fetch-retry-factor - -* Default: 10 -* Type: Number - -The "factor" config for the `retry` module to use when fetching -packages. - -### fetch-retry-mintimeout - -* Default: 10000 (10 seconds) -* Type: Number - -The "minTimeout" config for the `retry` module to use when fetching -packages. - -### fetch-retry-maxtimeout - -* Default: 60000 (1 minute) -* Type: Number - -The "maxTimeout" config for the `retry` module to use when fetching -packages. - -### git - -* Default: `"git"` -* Type: String - -The command to use for git commands. If git is installed on the -computer, but is not in the `PATH`, then set this to the full path to -the git binary. - -### 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}/lib/node_modules` folder, instead of the - current working directory. -* bin files are linked to `{prefix}/bin` -* man pages are linked to `{prefix}/share/man` - -### 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. - -### user-agent - -* Default: node/{process.version} {process.platform} {process.arch} -* Type: String - -Sets a User-Agent to the request header - -### ignore - -* Default: "" -* Type: string - -A white-space separated list of glob patterns of files to always exclude -from packages when building tarballs. - -### init-module - -* Default: ~/.npm-init.js -* Type: path - -A module that will be loaded by the `npm init` command. See the -documentation for the -[init-package-json](https://github.com/isaacs/init-package-json) module -for more information, or npm-init(1). - -### init.version - -* Default: "0.0.0" -* Type: semver - -The value `npm init` should use by default for the package version. - -### init.author.name - -* Default: "" -* 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. - -### json - -* Default: false -* Type: Boolean - -Whether or not to output JSON data, rather than the normal output. - -This feature is currently experimental, and the output data structures -for many commands is either not implemented in JSON yet, or subject to -change. Only the output from `npm ls --json` is currently valid. - -### 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. - -### loglevel - -* Default: "http" -* Type: String -* Values: "silent", "win", "error", "warn", "http", "info", "verbose", "silly" - -What level of logs to report. On failure, *all* logs are written to -`npm-debug.log` in the current working directory. - -Any logs of a higher level than the setting are shown. -The default is "http", which shows http, warn, and error output. - -### logstream - -* Default: process.stderr -* Type: Stream - -This is the stream that is passed to the -[npmlog](https://github.com/isaacs/npmlog) module at run time. - -It cannot be set from the command line, but if you are using npm -programmatically, you may wish to send logs to somewhere other than -stderr. - -If the `color` config is set to true, then this stream will receive -colored output if it is a TTY. - -### 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. - -### optional - -* Default: true -* Type: Boolean - -Attempt to install packages in the `optionalDependencies` hash. Note -that if these packages fail to install, the overall installation -process is not aborted. - -### parseable - -* Default: false -* Type: Boolean - -Output parseable results from commands that write to -standard output. - -### prefix - -* Default: see npm-folders(1) -* 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. - -### proprietary-attribs - -* Default: true -* Type: Boolean - -Whether or not to include proprietary extended attributes in the -tarballs created by npm. - -Unless you are expecting to unpack package tarballs with something other -than npm -- particularly a very outdated tar implementation -- leave -this as true. - -### 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. - -When used with the `npm rm` command, it removes it from the dependencies -hash. - -Only works if there is already a package.json file present. - -### save-bundle - -* Default: false -* Type: Boolean - -If a package would be saved at install time by the use of `--save`, -`--save-dev`, or `--save-optional`, then also put it in the -`bundleDependencies` list. - -When used with the `npm rm` command, it removes it from the -bundledDependencies list. - -### save-dev - -* Default: false -* Type: Boolean - -Save installed packages to a package.json file as devDependencies. - -When used with the `npm rm` command, it removes it from the devDependencies -hash. - -Only works if there is already a package.json file present. - -### save-optional - -* Default: false -* Type: Boolean - -Save installed packages to a package.json file as optionalDependencies. - -When used with the `npm rm` command, it removes it from the devDependencies -hash. - -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. - -### searchsort - -* Default: "name" -* Type: String -* Values: "name", "-name", "date", "-date", "description", - "-description", "keywords", "-keywords" - -Indication of which field to sort search results by. Prefix with a `-` -character to indicate reverse sort. - -### shell - -* Default: SHELL environment variable, or "bash" on Posix, or "cmd" on - Windows -* Type: path - -The shell to run for the `npm explore` command. - -### shrinkwrap - -* Default: true -* Type: Boolean - -If set to false, then ignore `npm-shrinkwrap.json` files when -installing. - -### sign-git-tag - -* Default: false -* Type: Boolean - -If set to true, then the `npm version` command will tag the version -using `-s` to add a signature. - -Note that git requires you to have set up GPG keys in your git configs -for this to work properly. - -### 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. - -### versions - -* Default: false -* Type: boolean - -If true, output the npm version as well as node's `process.versions` -hash, 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) diff --git a/deps/npm/doc/cli/dedupe.md b/deps/npm/doc/cli/dedupe.md deleted file mode 100644 index 220329acb..000000000 --- a/deps/npm/doc/cli/dedupe.md +++ /dev/null @@ -1,53 +0,0 @@ -npm-dedupe(1) -- Reduce duplication -=================================== - -## SYNOPSIS - - npm dedupe [package names...] - -## DESCRIPTION - -Searches the local package tree and attempts to simplify the overall -structure by moving dependencies further up the tree, where they can -be more effectively shared by multiple dependent packages. - -For example, consider this dependency graph: - - a - +-- b <-- depends on c@1.0.x - | `-- c@1.0.3 - `-- d <-- depends on c@~1.0.9 - `-- c@1.0.10 - -In this case, `npm-dedupe(1)` will transform the tree to: - - a - +-- b - +-- d - `-- c@1.0.10 - -Because of the hierarchical nature of node's module lookup, b and d -will both get their dependency met by the single c package at the root -level of the tree. - -If a suitable version exists at the target location in the tree -already, then it will be left untouched, but the other duplicates will -be deleted. - -If no suitable version can be found, then a warning is printed, and -nothing is done. - -If any arguments are supplied, then they are filters, and only the -named packages will be touched. - -Note that this operation transforms the dependency tree, and may -result in packages getting updated versions, perhaps from the npm -registry. - -This feature is experimental, and may change in future versions. - -## SEE ALSO - -* npm-ls(1) -* npm-update(1) -* npm-install(1) diff --git a/deps/npm/doc/cli/deprecate.md b/deps/npm/doc/cli/deprecate.md deleted file mode 100644 index c45245f09..000000000 --- a/deps/npm/doc/cli/deprecate.md +++ /dev/null @@ -1,26 +0,0 @@ -npm-deprecate(1) -- Deprecate a version of a package -==================================================== - -## SYNOPSIS - - npm deprecate [@] - -## 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. - -To un-deprecate a package, specify an empty string (`""`) for the `message` argument. - -## SEE ALSO - -* npm-publish(1) -* npm-registry(1) diff --git a/deps/npm/doc/cli/developers.md b/deps/npm/doc/cli/developers.md deleted file mode 100644 index d1ffd5aa8..000000000 --- a/deps/npm/doc/cli/developers.md +++ /dev/null @@ -1,207 +0,0 @@ -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 `@` that is published on the registry with (c) -* e) a `@` that points to (d) -* f) a `` 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`. - -## 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. - -By default, the following paths and files are ignored, so there's no -need to add them to `.npmignore` explicitly: - -* `.*.swp` -* `._*` -* `.DS_Store` -* `.git` -* `.hg` -* `.lock-wscript` -* `.svn` -* `.wafpickle-*` -* `CVS` -* `npm-debug.log` - -Additionally, everything in `node_modules` is ignored, except for -bundled dependencies. npm automatically handles this for you, so don't -bother adding `node_modules` to `.npmignore`. - -The following paths and files are never ignored, so adding them to -`.npmignore` is pointless: - -* `package.json` -* `README.*` - -## Link Packages - -`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 -`.npmignore` file to list out the globs to 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) diff --git a/deps/npm/doc/cli/disputes.md b/deps/npm/doc/cli/disputes.md deleted file mode 100644 index 52d2a2e56..000000000 --- a/deps/npm/doc/cli/disputes.md +++ /dev/null @@ -1,98 +0,0 @@ -npm-disputes(1) -- Handling Module Name Disputes -================================================ - -## SYNOPSIS - -1. Get the author email with `npm owner ls ` -2. Email the author, CC . -3. After a few weeks, if there's no resolution, we'll sort it out. - -Don't squat on package names. Publish code or move out of the way. - -## DESCRIPTION - -There sometimes arise cases where a user publishes a module, and then -later, some other user wants to use that name. Here are some common -ways that happens (each of these is based on actual events.) - -1. Joe writes a JavaScript module `foo`, which is not node-specific. - Joe doesn't use node at all. Bob wants to use `foo` in node, so he - wraps it in an npm module. Some time later, Joe starts using node, - and wants to take over management of his program. -2. Bob writes an npm module `foo`, and publishes it. Perhaps much - later, Joe finds a bug in `foo`, and fixes it. He sends a pull - request to Bob, but Bob doesn't have the time to deal with it, - because he has a new job and a new baby and is focused on his new - erlang project, and kind of not involved with node any more. Joe - would like to publish a new `foo`, but can't, because the name is - taken. -3. Bob writes a 10-line flow-control library, and calls it `foo`, and - publishes it to the npm registry. Being a simple little thing, it - never really has to be updated. Joe works for Foo Inc, the makers - of the critically acclaimed and widely-marketed `foo` JavaScript - toolkit framework. They publish it to npm as `foojs`, but people are - routinely confused when `npm install foo` is some different thing. -4. Bob writes a parser for the widely-known `foo` file format, because - he needs it for work. Then, he gets a new job, and never updates the - prototype. Later on, Joe writes a much more complete `foo` parser, - but can't publish, because Bob's `foo` is in the way. - -The validity of Joe's claim in each situation can be debated. However, -Joe's appropriate course of action in each case is the same. - -1. `npm owner ls foo`. This will tell Joe the email address of the - owner (Bob). -2. Joe emails Bob, explaining the situation **as respectfully as possible**, - and what he would like to do with the module name. He adds - isaacs to the CC list of the email. Mention in the email - that Bob can run `npm owner add joe foo` to add Joe as an owner of - the `foo` package. -3. After a reasonable amount of time, if Bob has not responded, or if - Bob and Joe can't come to any sort of resolution, email isaacs - and we'll sort it out. ("Reasonable" is usually about 4 - weeks, but extra time is allowed around common holidays.) - -## REASONING - -In almost every case so far, the parties involved have been able to reach -an amicable resolution without any major intervention. Most people -really do want to be reasonable, and are probably not even aware that -they're in your way. - -Module ecosystems are most vibrant and powerful when they are as -self-directed as possible. If an admin one day deletes something you -had worked on, then that is going to make most people quite upset, -regardless of the justification. When humans solve their problems by -talking to other humans with respect, everyone has the chance to end up -feeling good about the interaction. - -## EXCEPTIONS - -Some things are not allowed, and will be removed without discussion if -they are brought to the attention of the npm registry admins, including -but not limited to: - -1. Malware (that is, a package designed to exploit or harm the machine on - which it is installed). -2. Violations of copyright or licenses (for example, cloning an - MIT-licensed program, and then removing or changing the copyright and - license statement). -3. Illegal content. -4. "Squatting" on a package name that you *plan* to use, but aren't - actually using. Sorry, I don't care how great the name is, or how - perfect a fit it is for the thing that someday might happen. If - someone wants to use it today, and you're just taking up space with - an empty tarball, you're going to be evicted. -5. Putting empty packages in the registry. Packages must have SOME - functionality. It can be silly, but it can't be *nothing*. (See - also: squatting.) -6. Doing weird things with the registry, like using it as your own - personal application database or otherwise putting non-packagey - things into it. - -If you see bad behavior like this, please report it right away. - -## SEE ALSO - -* npm-registry(1) -* npm-owner(1) diff --git a/deps/npm/doc/cli/docs.md b/deps/npm/doc/cli/docs.md deleted file mode 100644 index 28fa49193..000000000 --- a/deps/npm/doc/cli/docs.md +++ /dev/null @@ -1,38 +0,0 @@ -npm-docs(1) -- Docs for a package in a web browser maybe -======================================================== - -## SYNOPSIS - - npm docs - npm home - -## 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"`, Windows: `"start"`, Others: `"xdg-open"` -* 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) diff --git a/deps/npm/doc/cli/edit.md b/deps/npm/doc/cli/edit.md deleted file mode 100644 index 9eaccfc54..000000000 --- a/deps/npm/doc/cli/edit.md +++ /dev/null @@ -1,35 +0,0 @@ -npm-edit(1) -- Edit an installed package -======================================== - -## SYNOPSIS - - npm edit [@] - -## 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) diff --git a/deps/npm/doc/cli/explore.md b/deps/npm/doc/cli/explore.md deleted file mode 100644 index 00701b392..000000000 --- a/deps/npm/doc/cli/explore.md +++ /dev/null @@ -1,40 +0,0 @@ -npm-explore(1) -- Browse an installed package -============================================= - -## SYNOPSIS - - npm explore [@] [ -- ] - -## 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 ` 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) diff --git a/deps/npm/doc/cli/faq.md b/deps/npm/doc/cli/faq.md deleted file mode 100644 index e00fec61d..000000000 --- a/deps/npm/doc/cli/faq.md +++ /dev/null @@ -1,352 +0,0 @@ -npm-faq(1) -- Frequently Asked Questions -======================================== - -## Where can I find these docs in HTML? - -, 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 on my computer in a central location? - -Install it globally by tacking `-g` or `--global` to the command. (This -is especially important for command line utilities that need to add -their bins to the global system `PATH`.) - -## I installed something globally, but I can't `require()` it - -Install it locally. - -The global install location is a place for command-line utilities -to put their bins in the system `PATH`. It's not for use with `require()`. - -If you `require()` a module in your code, then that means it's a -dependency, and a part of your program. You need to install it locally -in your program. - -## Why can't npm just put everything in one place, like other package managers? - -Not every change is an improvement, but every improvement is a change. -This would be like asking git to do network IO for every commit. It's -not going to happen, because it's a terrible idea that causes more -problems than it solves. - -It is much harder to avoid dependency conflicts without nesting -dependencies. This is fundamental to the way that npm works, and has -proven to be an extremely successful approach. See `npm-folders(1)` for -more details. - -If you want a package to be installed in one place, and have all your -programs reference the same copy of it, then use the `npm link` command. -That's what it's for. Install it globally, then link it into each -program that uses it. - -## Whatever, I really want the old style 'everything global' style. - -Write your own package manager, then. It's not that hard. - -npm will not help you do something that is known to be a bad idea. - -## Should I check my `node_modules` folder into git? - -Mikeal Rogers answered this question very well: - - - -tl;dr - -* Check `node_modules` into git for things you **deploy**, such as - websites and apps. -* Do not check `node_modules` into git for libraries and modules - intended to be reused. -* Use npm to manage dependencies in your dev environment, but not in - your deployment scripts. - -## Is it 'npm' or 'NPM' or 'Npm'? - -npm should never be capitalized unless it is being displayed in a -location that is customarily all-caps (such as the title of man pages.) - -## 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 . - -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 . - -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 https://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 `@` that is published on the registry with (c) -* e) a `@` that points to (d) -* f) a `` 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`. - -## What is a `module`? - -A module is anything that can be loaded with `require()` in a Node.js -program. The following things are all examples of things that can be -loaded as modules: - -* A folder with a `package.json` file containing a `main` field. -* A folder with an `index.js` file in it. -* A JavaScript file. - -Most npm packages are modules, because they are libraries that you -load with `require`. However, there's no requirement that an npm -package be a module! Some only contain an executable command-line -interface, and don't provide a `main` field for use in Node programs. - -Almost all npm packages (at least, those that are Node programs) -*contain* many modules within them (because every file they load with -`require()` is a module). - -In the context of a Node program, the `module` is also the thing that -was loaded *from* a file. For example, in the following program: - - var req = require('request') - -we might say that "The variable `req` refers to the `request` module". - -## So, why is it the "`node_modules`" folder, but "`package.json`" file? Why not `node_packages` or `module.json`? - -The `package.json` file defines the package. (See "What is a -package?" above.) - -The `node_modules` folder is the place Node.js looks for modules. -(See "What is a module?" above.) - -For example, if you create a file at `node_modules/foo.js` and then -had a program that did `var f = require('foo.js')` then it would load -the module. However, `foo.js` is not a "package" in this case, -because it does not have a package.json. - -Alternatively, if you create a package which does not have an -`index.js` or a `"main"` field in the `package.json` file, then it is -not a module. Even if it's installed in `node_modules`, it can't be -an argument to `require()`. - -## `"node_modules"` is the name of my deity's arch-rival, and a Forbidden Word in my religion. Can I configure npm to use a different folder? - -No. This will never happen. This question comes up sometimes, -because it seems silly from the outside that npm couldn't just be -configured to put stuff somewhere else, and then npm could load them -from there. It's an arbitrary spelling choice, right? What's the big -deal? - -At the time of this writing, the string `'node_modules'` appears 151 -times in 53 separate files in npm and node core (excluding tests and -documentation). - -Some of these references are in node's built-in module loader. Since -npm is not involved **at all** at run-time, node itself would have to -be configured to know where you've decided to stick stuff. Complexity -hurdle #1. Since the Node module system is locked, this cannot be -changed, and is enough to kill this request. But I'll continue, in -deference to your deity's delicate feelings regarding spelling. - -Many of the others are in dependencies that npm uses, which are not -necessarily tightly coupled to npm (in the sense that they do not read -npm's configuration files, etc.) Each of these would have to be -configured to take the name of the `node_modules` folder as a -parameter. Complexity hurdle #2. - -Furthermore, npm has the ability to "bundle" dependencies by adding -the dep names to the `"bundledDependencies"` list in package.json, -which causes the folder to be included in the package tarball. What -if the author of a module bundles its dependencies, and they use a -different spelling for `node_modules`? npm would have to rename the -folder at publish time, and then be smart enough to unpack it using -your locally configured name. Complexity hurdle #3. - -Furthermore, what happens when you *change* this name? Fine, it's -easy enough the first time, just rename the `node_modules` folders to -`./blergyblerp/` or whatever name you choose. But what about when you -change it again? npm doesn't currently track any state about past -configuration settings, so this would be rather difficult to do -properly. It would have to track every previous value for this -config, and always accept any of them, or else yesterday's install may -be broken tomorrow. Complexity hurdle #5. - -Never going to happen. The folder is named `node_modules`. It is -written indelibly in the Node Way, handed down from the ancient times -of Node 0.3. - -## How do I install node with npm? - -You don't. Try one of these node version managers: - -Unix: - -* -* -* - -Windows: - -* -* - -## 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)`. - -## I forgot my password, and can't publish. How do I reset it? - -Go to . - -## I get ECONNREFUSED a lot. What's up? - -Either the registry is down, or node's DNS isn't able to reach out. - -To check if the registry is down, open up -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 at . We'll have -someone kick it or something. - -## Why no namespaces? - -Please see this discussion: - -tl;dr - It doesn't actually make things better, and can make them worse. - -If you want to namespace your own packages, you may: simply use the -`-` character to separate the names. npm is a mostly anarchic system. -There is not sufficient need to impose namespace rules on everyone. - -## 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? - -Post an issue on the github project: - -* - -## 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) diff --git a/deps/npm/doc/cli/folders.md b/deps/npm/doc/cli/folders.md deleted file mode 100644 index 04fc13cfb..000000000 --- a/deps/npm/doc/cli/folders.md +++ /dev/null @@ -1,209 +0,0 @@ -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 satisfies bar's dependency on `blerg@1.x`, -it does not install another copy under [B]. - -Bar [B] also has dependencies on baz and asdf, so those are installed in -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) diff --git a/deps/npm/doc/cli/global.md b/deps/npm/doc/cli/global.md deleted file mode 100644 index 20358612a..000000000 --- a/deps/npm/doc/cli/global.md +++ /dev/null @@ -1,209 +0,0 @@ -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) diff --git a/deps/npm/doc/cli/help-search.md b/deps/npm/doc/cli/help-search.md deleted file mode 100644 index 9c16901eb..000000000 --- a/deps/npm/doc/cli/help-search.md +++ /dev/null @@ -1,35 +0,0 @@ -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) diff --git a/deps/npm/doc/cli/help.md b/deps/npm/doc/cli/help.md deleted file mode 100644 index b51b0f164..000000000 --- a/deps/npm/doc/cli/help.md +++ /dev/null @@ -1,38 +0,0 @@ -npm-help(1) -- Get help on npm -============================== - -## SYNOPSIS - - npm help - 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) diff --git a/deps/npm/doc/cli/index.md b/deps/npm/doc/cli/index.md deleted file mode 100644 index 903812dc2..000000000 --- a/deps/npm/doc/cli/index.md +++ /dev/null @@ -1,393 +0,0 @@ -npm-index(1) -- Index of all npm documentation -============================================== - -## npm-README(1) - - node package manager - -# Command Line Documentation -## npm-adduser(1) - - Add a registry user account - -## npm-bin(1) - - Display npm bin folder - -## npm-bugs(1) - - Bugs for a package in a web browser maybe - -## npm-build(1) - - Build a package - -## npm-bundle(1) - - REMOVED - -## npm-cache(1) - - Manipulates packages cache - -## npm-changelog(1) - - Changes - -## npm-coding-style(1) - - npm's "funny" coding style - -## npm-completion(1) - - Tab Completion for npm - -## npm-config(1) - - Manage the npm configuration file - -## npm-dedupe(1) - - Reduce duplication - -## npm-deprecate(1) - - Deprecate a version of a package - -## npm-developers(1) - - Developer Guide - -## npm-disputes(1) - - Handling Module Name Disputes - -## npm-docs(1) - - Docs for a package in a web browser maybe - -## npm-edit(1) - - Edit an installed package - -## npm-explore(1) - - Browse an installed package - -## npm-faq(1) - - Frequently Asked Questions - -## npm-folders(1) - - Folder Structures Used by npm - -## npm-global(1) - - Folder Structures Used by npm - -## npm-help-search(1) - - Search npm help documentation - -## npm-help(1) - - Get help on npm - -## npm-init(1) - - Interactively create a package.json file - -## npm-install(1) - - Install a package - -## npm-json(1) - - Specifics of npm's package.json handling - -## npm-link(1) - - Symlink a package folder - -## npm-ls(1) - - List installed packages - -## npm-npm(1) - - node package manager - -## npm-outdated(1) - - Check for outdated packages - -## npm-owner(1) - - Manage package owners - -## npm-pack(1) - - Create a tarball from a package - -## npm-prefix(1) - - Display prefix - -## npm-prune(1) - - Remove extraneous packages - -## npm-publish(1) - - Publish a package - -## npm-rebuild(1) - - Rebuild a package - -## npm-registry(1) - - The JavaScript Package Registry - -## npm-removing-npm(1) - - Cleaning the Slate - -## npm-restart(1) - - Start a package - -## npm-rm(1) - - Remove a package - -## npm-root(1) - - Display npm root - -## npm-run-script(1) - - Run arbitrary package scripts - -## npm-scripts(1) - - How npm handles the "scripts" field - -## npm-search(1) - - Search for packages - -## npm-semver(1) - - The semantic versioner for npm - -## npm-shrinkwrap(1) - - Lock down dependency versions - -## npm-star(1) - - Mark your favorite packages - -## npm-stars(1) - - View packages marked as favorites - -## npm-start(1) - - Start a package - -## npm-stop(1) - - Stop a package - -## npm-submodule(1) - - Add a package as a git submodule - -## npm-tag(1) - - Tag a published version - -## npm-test(1) - - Test a package - -## npm-uninstall(1) - - Remove a package - -## npm-unpublish(1) - - Remove a package from the registry - -## npm-update(1) - - Update a package - -## npm-version(1) - - Bump a package version - -## npm-view(1) - - View registry info - -## npm-whoami(1) - - Display npm username - -# API Documentation -## npm-bin(3) - - Display npm bin folder - -## npm-bugs(3) - - Bugs for a package in a web browser maybe - -## npm-commands(3) - - npm commands - -## npm-config(3) - - Manage the npm configuration files - -## npm-deprecate(3) - - Deprecate a version of a package - -## npm-docs(3) - - Docs for a package in a web browser maybe - -## npm-edit(3) - - Edit an installed package - -## npm-explore(3) - - Browse an installed package - -## npm-help-search(3) - - Search the help pages - -## npm-init(3) - - Interactively create a package.json file - -## npm-install(3) - - install a package programmatically - -## npm-link(3) - - Symlink a package folder - -## npm-load(3) - - Load config settings - -## npm-ls(3) - - List installed packages - -## npm-npm(3) - - node package manager - -## npm-outdated(3) - - Check for outdated packages - -## npm-owner(3) - - Manage package owners - -## npm-pack(3) - - Create a tarball from a package - -## npm-prefix(3) - - Display prefix - -## npm-prune(3) - - Remove extraneous packages - -## npm-publish(3) - - Publish a package - -## npm-rebuild(3) - - Rebuild a package - -## npm-restart(3) - - Start a package - -## npm-root(3) - - Display npm root - -## npm-run-script(3) - - Run arbitrary package scripts - -## npm-search(3) - - Search for packages - -## npm-shrinkwrap(3) - - programmatically generate package shrinkwrap file - -## npm-start(3) - - Start a package - -## npm-stop(3) - - Stop a package - -## npm-submodule(3) - - Add a package as a git submodule - -## npm-tag(3) - - Tag a published version - -## npm-test(3) - - Test a package - -## npm-uninstall(3) - - uninstall a package programmatically - -## npm-unpublish(3) - - Remove a package from the registry - -## npm-update(3) - - Update a package - -## npm-version(3) - - Bump a package version - -## npm-view(3) - - View registry info - -## npm-whoami(3) - - Display npm username - diff --git a/deps/npm/doc/cli/init.md b/deps/npm/doc/cli/init.md deleted file mode 100644 index d036f924d..000000000 --- a/deps/npm/doc/cli/init.md +++ /dev/null @@ -1,25 +0,0 @@ -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) diff --git a/deps/npm/doc/cli/install.md b/deps/npm/doc/cli/install.md deleted file mode 100644 index 44885f318..000000000 --- a/deps/npm/doc/cli/install.md +++ /dev/null @@ -1,242 +0,0 @@ -npm-install(1) -- Install a package -=================================== - -## SYNOPSIS - - npm install (with no args in a package dir) - npm install - npm install - npm install - npm install [--save|--save-dev|--save-optional] - npm install @ - npm install @ - npm install @ - npm install @ - -## DESCRIPTION - -This command installs a package, and any packages that it depends on. If the -package has a shrinkwrap file, the installation of dependencies will be driven -by that. See npm-shrinkwrap(1). - -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 `@` that is published on the registry with (c) -* e) a `@` that points to (d) -* f) a `` that has a "latest" tag satisfying (e) -* g) a `` 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 `: - - Install a package that is sitting in a folder on the filesystem. - -* `npm install `: - - 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 `: - - 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 [--save|--save-dev|--save-optional]`: - - Do a `@` install, where `` is the "tag" config. (See - `npm-config(1)`.) - - In most cases, this will install the latest version - of the module published on npm. - - Example: - - npm install sax - - `npm install` takes 3 exclusive, optional flags which save or update - the package version in your main package.json: - - * `--save`: Package will appear in your `dependencies`. - - * `--save-dev`: Package will appear in your `devDependencies`. - - * `--save-optional`: Package will appear in your `optionalDependencies`. - - Examples: - - npm install sax --save - npm install node-tap --save-dev - npm install dtrace-provider --save-optional - - - **Note**: If there is a file or folder named `` 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 @`: - - 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 @`: - - 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 @`: - - 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 `: - - Install a package by cloning a git remote url. The format of the git - url is: - - ://[@][#] - - `` is one of `git`, `git+ssh`, `git+http`, or - `git+https`. If no `` 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-folders(1)`. - -The `--link` argument will cause npm to link global installs into the -local space in some cases. - -The `--no-bin-links` argument will prevent npm from creating symlinks for -any binaries the package might contain. - -The `--no-shrinkwrap` argument, which will ignore an available -shrinkwrap file and use the package.json instead. - -The `--nodedir=/path/to/node/source` argument will allow npm to find the -node source code so that npm can compile native modules. - -See `npm-config(1)`. Many of the configuration params have some -effect on installation, since that's most of what npm does. - -## ALGORITHM - -To install a package, npm uses the following algorithm: - - install(where, what, family, ancestors) - fetch what, unpack to /node_modules/ - for each dep in what.dependencies - resolve dep to precise version - for each dep@version in what.dependencies - not in /node_modules//node_modules/* - and not in - add precise version deps to - install(/node_modules/, 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) -* npm-shrinkwrap(1) diff --git a/deps/npm/doc/cli/json.md b/deps/npm/doc/cli/json.md deleted file mode 100644 index 403f7f856..000000000 --- a/deps/npm/doc/cli/json.md +++ /dev/null @@ -1,587 +0,0 @@ -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. - -* `"scripts":{"preinstall": "node-gyp rebuild"}` - - If there is a `binding.gyp` file in the root of your package, npm will - default the `preinstall` command to compile using node-gyp. - -* `"contributors": [...]` - - If there is an `AUTHORS` file in the root of your package, npm will - treat each line as a `Name (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. - -## license - -You should specify a license for your package so that people know how they are -permitted to use it, and any restrictions you're placing on it. - -The simplest way, assuming you're using a common license such as BSD or MIT, is -to just specify the name of the license you're using, like this: - - { "license" : "BSD" } - -If you have more complex licensing terms, or you want to provide more detail -in your package.json file, you can use the more verbose plural form, like this: - - "licenses" : [ - { "type" : "MyLicense" - , "url" : "http://github.com/owner/project/path/to/license" - } - ] - -It's also a good idea to include a license file at the top level in your package. - -## people fields: author, contributors - -The "author" is one person. "contributors" is an array of people. A "person" -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 (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 `, 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 -* `=version1 <=version2`. -* `range1 || range2` Passes if either range1 or range2 are satisfied. -* `git...` See 'Git URLs as Dependencies' below - -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 <1.3.0"` -* `"~1" = ">=1.0.0 <1.1.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. - -### Git URLs as Dependencies - -Git urls can be of the form: - - git://github.com/user/project.git#commit-ish - git+ssh://user@hostname: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`. - -## 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` or when doing -`npm install` from the root of a package, and can be managed like any other npm -configuration param. See `npm-config(1)` for more on the topic. - -## bundledDependencies - -Array of package names that will be bundled when publishing the package. - -If this is spelled `"bundleDependencies"`, then that is also honorable. - -## optionalDependencies - -If a dependency can be used, but you would like npm to proceed if it -cannot be found or fails to install, then you may put it in the -`optionalDependencies` hash. This is a map of package name to version -or url, just like the `dependencies` hash. The difference is that -failure is tolerated. - -It is still your program's responsibility to handle the lack of the -dependency. For example, something like this: - - try { - var foo = require('foo') - var fooVersion = require('foo/package.json').version - } catch (er) { - foo = null - } - if ( notGoodFooVersion(fooVersion) ) { - foo = null - } - - // .. then later in your program .. - - if (foo) { - foo.doFooThings() - } - -Entries in `optionalDependencies` will override entries of the same name in -`dependencies`, so it's usually best to only put in one place. - -## 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" } } - -Note that, unless the user has set the `engine-strict` config flag, this -field is advisory only. - -## engineStrict - -If you are sure that your module will *definitely not* run properly on -versions of Node/npm other than those specified in the `engines` hash, -then you can set `"engineStrict": true` in your package.json file. -This will override the user's `engine-strict` config setting. - -Please do not do this unless you are really very very sure. If your -engines hash is something overly restrictive, you can quite easily and -inadvertently lock yourself into obscurity and prevent your users from -updating to new versions of Node. Consider this choice carefully. If -people abuse it, it will be removed in a future version of npm. - -## os - -You can specify which operating systems your -module will run on: - - "os" : [ "darwin", "linux" ] - -You can also blacklist instead of whitelist operating systems, -just prepend the blacklisted os with a '!': - - "os" : [ "!win32" ] - -The host operating system is determined by `process.platform` - -It is allowed to both blacklist, and whitelist, although there isn't any -good reason to do this. - -## cpu - -If your code only runs on certain cpu architectures, -you can specify which ones. - - "cpu" : [ "x64", "ia32" ] - -Like the `os` option, you can also blacklist architectures: - - "cpu" : [ "!arm", "!mips" ] - -The host architecture is determined by `process.arch` - -## 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 specific 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) diff --git a/deps/npm/doc/cli/link.md b/deps/npm/doc/cli/link.md deleted file mode 100644 index 4e4ef799b..000000000 --- a/deps/npm/doc/cli/link.md +++ /dev/null @@ -1,60 +0,0 @@ -npm-link(1) -- Symlink a package folder -======================================= - -## SYNOPSIS - - npm link (in package folder) - npm link - -## 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. - -Note that `package-name` is taken from `package.json` , -not from directory name. - -When creating tarballs for `npm publish`, the linked packages are -"snapshotted" to their current state by resolving the symbolic links. - -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) diff --git a/deps/npm/doc/cli/ls.md b/deps/npm/doc/cli/ls.md deleted file mode 100644 index 9b69b8585..000000000 --- a/deps/npm/doc/cli/ls.md +++ /dev/null @@ -1,72 +0,0 @@ -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. - -Positional arguments are `name@version-range` identifiers, which will -limit the results to only the paths to the packages named. Note that -nested packages will *also* show the paths to the specified packages. -For example, running `npm ls promzard` in npm's source tree will show: - - npm@@VERSION@ /path/to/npm - └─┬ init-package-json@0.0.4 - └── promzard@0.1.5 - -It will print out extraneous, missing, and invalid packages. - -If a project specifies git urls for dependencies these are shown -in parentheses after the name@version to make it easier for users to -recognize potential forks of a project. - -When run as `ll` or `la`, it shows extended information by default. - -## CONFIGURATION - -### json - -* Default: false -* Type: Boolean - -Show information in JSON format. - -### 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) diff --git a/deps/npm/doc/cli/npm-adduser.md b/deps/npm/doc/cli/npm-adduser.md new file mode 100644 index 000000000..ee5c3bd27 --- /dev/null +++ b/deps/npm/doc/cli/npm-adduser.md @@ -0,0 +1,38 @@ +npm-adduser(1) -- Add a registry user account +============================================= + +## SYNOPSIS + + npm adduser + +## DESCRIPTION + +Create or verify a user named `` 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 + +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(7) +* npm-config(1) +* npm-config(7) +* npmrc(5) +* npm-owner(1) +* npm-whoami(1) diff --git a/deps/npm/doc/cli/npm-bin.md b/deps/npm/doc/cli/npm-bin.md new file mode 100644 index 000000000..49d209d7f --- /dev/null +++ b/deps/npm/doc/cli/npm-bin.md @@ -0,0 +1,19 @@ +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(7) +* npm-config(1) +* npm-config(7) +* npmrc(5) diff --git a/deps/npm/doc/cli/npm-bugs.md b/deps/npm/doc/cli/npm-bugs.md new file mode 100644 index 000000000..2a7dae98d --- /dev/null +++ b/deps/npm/doc/cli/npm-bugs.md @@ -0,0 +1,40 @@ +npm-bugs(1) -- Bugs for a package in a web browser maybe +======================================================== + +## SYNOPSIS + + npm bugs + +## 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"`, Windows: `"start"`, Others: `"xdg-open"` +* 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(7) +* npm-config(1) +* npm-config(7) +* npmrc(5) +* package.json(5) diff --git a/deps/npm/doc/cli/npm-build.md b/deps/npm/doc/cli/npm-build.md new file mode 100644 index 000000000..53813c1fd --- /dev/null +++ b/deps/npm/doc/cli/npm-build.md @@ -0,0 +1,22 @@ +npm-build(1) -- Build a package +=============================== + +## SYNOPSIS + + npm build + +* ``: + 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(7) +* package.json(5) diff --git a/deps/npm/doc/cli/npm-bundle.md b/deps/npm/doc/cli/npm-bundle.md new file mode 100644 index 000000000..69b3d83e4 --- /dev/null +++ b/deps/npm/doc/cli/npm-bundle.md @@ -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) diff --git a/deps/npm/doc/cli/npm-cache.md b/deps/npm/doc/cli/npm-cache.md new file mode 100644 index 000000000..195c4aa20 --- /dev/null +++ b/deps/npm/doc/cli/npm-cache.md @@ -0,0 +1,72 @@ +npm-cache(1) -- Manipulates packages cache +========================================== + +## SYNOPSIS + + npm cache add + npm cache add + npm cache add + npm cache add @ + + npm cache ls [] + + npm cache clean [] + +## 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(7) +* npm-config(1) +* npm-config(7) +* npmrc(5) +* npm-install(1) +* npm-publish(1) +* npm-pack(1) diff --git a/deps/npm/doc/cli/npm-completion.md b/deps/npm/doc/cli/npm-completion.md new file mode 100644 index 000000000..bec0f6086 --- /dev/null +++ b/deps/npm/doc/cli/npm-completion.md @@ -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(7) +* npm-faq(7) +* npm(1) diff --git a/deps/npm/doc/cli/npm-config.md b/deps/npm/doc/cli/npm-config.md new file mode 100644 index 000000000..119840ef0 --- /dev/null +++ b/deps/npm/doc/cli/npm-config.md @@ -0,0 +1,70 @@ +npm-config(1) -- Manage the npm configuration files +=================================================== + +## SYNOPSIS + + npm config set [--global] + npm config get + npm config delete + npm config list + npm config edit + npm get + npm set [--global] + +## DESCRIPTION + +npm gets its config settings from the command line, environment +variables, `npmrc` files, and in some cases, the `package.json` file. + +See npmrc(5) for more information about the npmrc files. + +See `npm-config(7)` for a more thorough discussion of the mechanisms +involved. + +The `npm config` command can be used to update and edit the contents +of the user and global npmrc files. + +## 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. + +## SEE ALSO + +* npm-folders(5) +* npm-config(7) +* package.json(5) +* npmrc(5) +* npm(1) diff --git a/deps/npm/doc/cli/npm-dedupe.md b/deps/npm/doc/cli/npm-dedupe.md new file mode 100644 index 000000000..220329acb --- /dev/null +++ b/deps/npm/doc/cli/npm-dedupe.md @@ -0,0 +1,53 @@ +npm-dedupe(1) -- Reduce duplication +=================================== + +## SYNOPSIS + + npm dedupe [package names...] + +## DESCRIPTION + +Searches the local package tree and attempts to simplify the overall +structure by moving dependencies further up the tree, where they can +be more effectively shared by multiple dependent packages. + +For example, consider this dependency graph: + + a + +-- b <-- depends on c@1.0.x + | `-- c@1.0.3 + `-- d <-- depends on c@~1.0.9 + `-- c@1.0.10 + +In this case, `npm-dedupe(1)` will transform the tree to: + + a + +-- b + +-- d + `-- c@1.0.10 + +Because of the hierarchical nature of node's module lookup, b and d +will both get their dependency met by the single c package at the root +level of the tree. + +If a suitable version exists at the target location in the tree +already, then it will be left untouched, but the other duplicates will +be deleted. + +If no suitable version can be found, then a warning is printed, and +nothing is done. + +If any arguments are supplied, then they are filters, and only the +named packages will be touched. + +Note that this operation transforms the dependency tree, and may +result in packages getting updated versions, perhaps from the npm +registry. + +This feature is experimental, and may change in future versions. + +## SEE ALSO + +* npm-ls(1) +* npm-update(1) +* npm-install(1) diff --git a/deps/npm/doc/cli/npm-deprecate.md b/deps/npm/doc/cli/npm-deprecate.md new file mode 100644 index 000000000..e62579349 --- /dev/null +++ b/deps/npm/doc/cli/npm-deprecate.md @@ -0,0 +1,26 @@ +npm-deprecate(1) -- Deprecate a version of a package +==================================================== + +## SYNOPSIS + + npm deprecate [@] + +## 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. + +To un-deprecate a package, specify an empty string (`""`) for the `message` argument. + +## SEE ALSO + +* npm-publish(1) +* npm-registry(7) diff --git a/deps/npm/doc/cli/npm-docs.md b/deps/npm/doc/cli/npm-docs.md new file mode 100644 index 000000000..cc39e82c4 --- /dev/null +++ b/deps/npm/doc/cli/npm-docs.md @@ -0,0 +1,40 @@ +npm-docs(1) -- Docs for a package in a web browser maybe +======================================================== + +## SYNOPSIS + + npm docs + npm home + +## 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"`, Windows: `"start"`, Others: `"xdg-open"` +* 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(7) +* npm-config(1) +* npm-config(7) +* npmrc(5) +* package.json(5) diff --git a/deps/npm/doc/cli/npm-edit.md b/deps/npm/doc/cli/npm-edit.md new file mode 100644 index 000000000..d833bc06f --- /dev/null +++ b/deps/npm/doc/cli/npm-edit.md @@ -0,0 +1,37 @@ +npm-edit(1) -- Edit an installed package +======================================== + +## SYNOPSIS + + npm edit [@] + +## DESCRIPTION + +Opens the package folder in the default editor (or whatever you've +configured as the npm `editor` config -- see `npm-config(7)`.) + +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(7) +* npm-explore(1) +* npm-install(1) +* npm-config(1) +* npm-config(7) +* npmrc(5) diff --git a/deps/npm/doc/cli/npm-explore.md b/deps/npm/doc/cli/npm-explore.md new file mode 100644 index 000000000..51846f531 --- /dev/null +++ b/deps/npm/doc/cli/npm-explore.md @@ -0,0 +1,40 @@ +npm-explore(1) -- Browse an installed package +============================================= + +## SYNOPSIS + + npm explore [@] [ -- ] + +## 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 ` 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(7) +* npm-edit(1) +* npm-rebuild(1) +* npm-build(1) +* npm-install(1) diff --git a/deps/npm/doc/cli/npm-help-search.md b/deps/npm/doc/cli/npm-help-search.md new file mode 100644 index 000000000..7bf7401ba --- /dev/null +++ b/deps/npm/doc/cli/npm-help-search.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(7) +* npm-help(1) diff --git a/deps/npm/doc/cli/npm-help.md b/deps/npm/doc/cli/npm-help.md new file mode 100644 index 000000000..7a7eadf1f --- /dev/null +++ b/deps/npm/doc/cli/npm-help.md @@ -0,0 +1,40 @@ +npm-help(1) -- Get help on npm +============================== + +## SYNOPSIS + + npm help + 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(7) +* npm-folders(7) +* npm-config(1) +* npm-config(7) +* npmrc(5) +* package.json(5) +* npm-help-search(1) +* npm-index(7) diff --git a/deps/npm/doc/cli/npm-init.md b/deps/npm/doc/cli/npm-init.md new file mode 100644 index 000000000..bd63a8879 --- /dev/null +++ b/deps/npm/doc/cli/npm-init.md @@ -0,0 +1,25 @@ +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 + +* +* package.json(5) +* npm-version(1) diff --git a/deps/npm/doc/cli/npm-install.md b/deps/npm/doc/cli/npm-install.md new file mode 100644 index 000000000..f460f2c96 --- /dev/null +++ b/deps/npm/doc/cli/npm-install.md @@ -0,0 +1,244 @@ +npm-install(1) -- Install a package +=================================== + +## SYNOPSIS + + npm install (with no args in a package dir) + npm install + npm install + npm install + npm install [--save|--save-dev|--save-optional] + npm install @ + npm install @ + npm install @ + npm install @ + +## DESCRIPTION + +This command installs a package, and any packages that it depends on. If the +package has a shrinkwrap file, the installation of dependencies will be driven +by that. See npm-shrinkwrap(1). + +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 `@` that is published on the registry with (c) +* e) a `@` that points to (d) +* f) a `` that has a "latest" tag satisfying (e) +* g) a `` 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 `: + + Install a package that is sitting in a folder on the filesystem. + +* `npm install `: + + 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 `: + + 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 [--save|--save-dev|--save-optional]`: + + Do a `@` install, where `` is the "tag" config. (See + `npm-config(7)`.) + + In most cases, this will install the latest version + of the module published on npm. + + Example: + + npm install sax + + `npm install` takes 3 exclusive, optional flags which save or update + the package version in your main package.json: + + * `--save`: Package will appear in your `dependencies`. + + * `--save-dev`: Package will appear in your `devDependencies`. + + * `--save-optional`: Package will appear in your `optionalDependencies`. + + Examples: + + npm install sax --save + npm install node-tap --save-dev + npm install dtrace-provider --save-optional + + + **Note**: If there is a file or folder named `` 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 @`: + + 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 @`: + + 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 @`: + + Install a version of the package matching the specified version range. This + will follow the same rules for resolving dependencies described in `package.json(5)`. + + 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 `: + + Install a package by cloning a git remote url. The format of the git + url is: + + ://[@][#] + + `` is one of `git`, `git+ssh`, `git+http`, or + `git+https`. If no `` 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-folders(7)`. + +The `--link` argument will cause npm to link global installs into the +local space in some cases. + +The `--no-bin-links` argument will prevent npm from creating symlinks for +any binaries the package might contain. + +The `--no-shrinkwrap` argument, which will ignore an available +shrinkwrap file and use the package.json instead. + +The `--nodedir=/path/to/node/source` argument will allow npm to find the +node source code so that npm can compile native modules. + +See `npm-config(7)`. 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 /node_modules/ + for each dep in what.dependencies + resolve dep to precise version + for each dep@version in what.dependencies + not in /node_modules//node_modules/* + and not in + add precise version deps to + install(/node_modules/, 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(7) 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(7) +* npm-update(1) +* npm-link(1) +* npm-rebuild(1) +* npm-scripts(7) +* npm-build(1) +* npm-config(1) +* npm-config(7) +* npmrc(5) +* npm-registry(7) +* npm-folders(7) +* npm-tag(1) +* npm-rm(1) +* npm-shrinkwrap(1) diff --git a/deps/npm/doc/cli/npm-link.md b/deps/npm/doc/cli/npm-link.md new file mode 100644 index 000000000..65476d5c1 --- /dev/null +++ b/deps/npm/doc/cli/npm-link.md @@ -0,0 +1,62 @@ +npm-link(1) -- Symlink a package folder +======================================= + +## SYNOPSIS + + npm link (in package folder) + npm link + +## 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. + +Note that `package-name` is taken from `package.json` , +not from directory name. + +When creating tarballs for `npm publish`, the linked packages are +"snapshotted" to their current state by resolving the symbolic links. + +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(7) +* npm-faq(7) +* package.json(5) +* npm-install(1) +* npm-folders(7) +* npm-config(1) +* npm-config(7) +* npmrc(5) diff --git a/deps/npm/doc/cli/npm-ls.md b/deps/npm/doc/cli/npm-ls.md new file mode 100644 index 000000000..7f1fda669 --- /dev/null +++ b/deps/npm/doc/cli/npm-ls.md @@ -0,0 +1,74 @@ +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. + +Positional arguments are `name@version-range` identifiers, which will +limit the results to only the paths to the packages named. Note that +nested packages will *also* show the paths to the specified packages. +For example, running `npm ls promzard` in npm's source tree will show: + + npm@@VERSION@ /path/to/npm + └─┬ init-package-json@0.0.4 + └── promzard@0.1.5 + +It will print out extraneous, missing, and invalid packages. + +If a project specifies git urls for dependencies these are shown +in parentheses after the name@version to make it easier for users to +recognize potential forks of a project. + +When run as `ll` or `la`, it shows extended information by default. + +## CONFIGURATION + +### json + +* Default: false +* Type: Boolean + +Show information in JSON format. + +### 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-config(7) +* npmrc(5) +* npm-folders(7) +* npm-install(1) +* npm-link(1) +* npm-prune(1) +* npm-outdated(1) +* npm-update(1) diff --git a/deps/npm/doc/cli/npm-outdated.md b/deps/npm/doc/cli/npm-outdated.md new file mode 100644 index 000000000..b82b666fd --- /dev/null +++ b/deps/npm/doc/cli/npm-outdated.md @@ -0,0 +1,17 @@ +npm-outdated(1) -- Check for outdated packages +============================================== + +## SYNOPSIS + + npm outdated [ [ ...]] + +## DESCRIPTION + +This command will check the registry to see if any (or, specific) installed +packages are currently outdated. + +## SEE ALSO + +* npm-update(1) +* npm-registry(7) +* npm-folders(7) diff --git a/deps/npm/doc/cli/npm-owner.md b/deps/npm/doc/cli/npm-owner.md new file mode 100644 index 000000000..b400f7637 --- /dev/null +++ b/deps/npm/doc/cli/npm-owner.md @@ -0,0 +1,33 @@ +npm-owner(1) -- Manage package owners +===================================== + +## SYNOPSIS + + npm owner ls + npm owner add + npm owner rm + +## DESCRIPTION + +Manage ownership of published packages. + +* ls: + List all the users who have access to modify a package and push new versions. + Handy when you need to know who to bug for help. +* add: + Add a new user as a maintainer of a package. This user is enabled to modify + metadata, publish new versions, and add other owners. +* rm: + Remove a user from the package owner list. This immediately revokes their + privileges. + +Note that there is only one level of access. Either you can modify a package, +or you can't. Future versions may contain more fine-grained access levels, but +that is not implemented at this time. + +## SEE ALSO + +* npm-publish(1) +* npm-registry(7) +* npm-adduser(1) +* npm-disputes(7) diff --git a/deps/npm/doc/cli/npm-pack.md b/deps/npm/doc/cli/npm-pack.md new file mode 100644 index 000000000..42bc1564b --- /dev/null +++ b/deps/npm/doc/cli/npm-pack.md @@ -0,0 +1,27 @@ +npm-pack(1) -- Create a tarball from a package +============================================== + +## SYNOPSIS + + npm pack [ [ ...]] + +## 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 `-.tgz`, and then write the filenames out to +stdout. + +If the same package is specified multiple times, then the file will be +overwritten the second time. + +If no arguments are supplied, then npm packs the current package folder. + +## SEE ALSO + +* npm-cache(1) +* npm-publish(1) +* npm-config(1) +* npm-config(7) +* npmrc(5) diff --git a/deps/npm/doc/cli/npm-prefix.md b/deps/npm/doc/cli/npm-prefix.md new file mode 100644 index 000000000..8d88737a9 --- /dev/null +++ b/deps/npm/doc/cli/npm-prefix.md @@ -0,0 +1,19 @@ +npm-prefix(1) -- Display prefix +=============================== + +## SYNOPSIS + + npm prefix + +## DESCRIPTION + +Print the prefix to standard out. + +## SEE ALSO + +* npm-root(1) +* npm-bin(1) +* npm-folders(7) +* npm-config(1) +* npm-config(7) +* npmrc(5) diff --git a/deps/npm/doc/cli/npm-prune.md b/deps/npm/doc/cli/npm-prune.md new file mode 100644 index 000000000..292bacc91 --- /dev/null +++ b/deps/npm/doc/cli/npm-prune.md @@ -0,0 +1,21 @@ +npm-prune(1) -- Remove extraneous packages +========================================== + +## SYNOPSIS + + npm prune [ [ + npm publish + +## DESCRIPTION + +Publishes a package to the registry so that it can be installed by name. + +* ``: + A folder containing a package.json file + +* ``: + A url or file path to a gzipped tar archive containing a single folder + with a package.json file inside. + +Fails if the package name and version combination already exists in +the registry. Overwrites when the "--force" flag is set. + +## SEE ALSO + +* npm-registry(7) +* npm-adduser(1) +* npm-owner(1) +* npm-deprecate(1) +* npm-tag(1) diff --git a/deps/npm/doc/cli/npm-rebuild.md b/deps/npm/doc/cli/npm-rebuild.md new file mode 100644 index 000000000..6985a7bdd --- /dev/null +++ b/deps/npm/doc/cli/npm-rebuild.md @@ -0,0 +1,20 @@ +npm-rebuild(1) -- Rebuild a package +=================================== + +## SYNOPSIS + + npm rebuild [ [ ...]] + +* ``: + The package to rebuild + +## DESCRIPTION + +This command runs the `npm build` command on the matched folders. This is useful +when you install a new version of node, and must recompile all your C++ addons with +the new binary. + +## SEE ALSO + +* npm-build(1) +* npm-install(1) diff --git a/deps/npm/doc/cli/npm-restart.md b/deps/npm/doc/cli/npm-restart.md new file mode 100644 index 000000000..4661d6b23 --- /dev/null +++ b/deps/npm/doc/cli/npm-restart.md @@ -0,0 +1,22 @@ +npm-restart(1) -- Start a package +================================= + +## SYNOPSIS + + npm restart + +## 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. + +## SEE ALSO + +* npm-run-script(1) +* npm-scripts(7) +* npm-test(1) +* npm-start(1) +* npm-stop(1) diff --git a/deps/npm/doc/cli/npm-rm.md b/deps/npm/doc/cli/npm-rm.md new file mode 100644 index 000000000..7839d9ddd --- /dev/null +++ b/deps/npm/doc/cli/npm-rm.md @@ -0,0 +1,21 @@ +npm-rm(1) -- Remove a package +============================= + +## SYNOPSIS + + npm rm + npm uninstall + +## DESCRIPTION + +This uninstalls a package, completely removing everything npm installed +on its behalf. + +## SEE ALSO + +* npm-prune(1) +* npm-install(1) +* npm-folders(7) +* npm-config(1) +* npm-config(7) +* npmrc(5) diff --git a/deps/npm/doc/cli/npm-root.md b/deps/npm/doc/cli/npm-root.md new file mode 100644 index 000000000..346733160 --- /dev/null +++ b/deps/npm/doc/cli/npm-root.md @@ -0,0 +1,19 @@ +npm-root(1) -- Display npm root +=============================== + +## SYNOPSIS + + npm root + +## DESCRIPTION + +Print the effective `node_modules` folder to standard out. + +## SEE ALSO + +* npm-prefix(1) +* npm-bin(1) +* npm-folders(7) +* npm-config(1) +* npm-config(7) +* npmrc(5) diff --git a/deps/npm/doc/cli/npm-run-script.md b/deps/npm/doc/cli/npm-run-script.md new file mode 100644 index 000000000..6c3c2b7a9 --- /dev/null +++ b/deps/npm/doc/cli/npm-run-script.md @@ -0,0 +1,21 @@ +npm-run-script(1) -- Run arbitrary package scripts +================================================== + +## SYNOPSIS + + npm run-script - diff --git a/deps/npm/html/api/bugs.html b/deps/npm/html/api/bugs.html deleted file mode 100644 index 1b95fd202..000000000 --- a/deps/npm/html/api/bugs.html +++ /dev/null @@ -1,60 +0,0 @@ - - - bugs - - - - -
-

bugs

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.

-
- - - diff --git a/deps/npm/html/api/commands.html b/deps/npm/html/api/commands.html deleted file mode 100644 index 6d9631a8d..000000000 --- a/deps/npm/html/api/commands.html +++ /dev/null @@ -1,63 +0,0 @@ - - - commands - - - - -
-

commands

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

- - -
- - - diff --git a/deps/npm/html/api/config.html b/deps/npm/html/api/config.html deleted file mode 100644 index 8afad7633..000000000 --- a/deps/npm/html/api/config.html +++ /dev/null @@ -1,68 +0,0 @@ - - - config - - - - -
-

config

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

- - -
- - - diff --git a/deps/npm/html/api/deprecate.html b/deps/npm/html/api/deprecate.html deleted file mode 100644 index 36f296168..000000000 --- a/deps/npm/html/api/deprecate.html +++ /dev/null @@ -1,67 +0,0 @@ - - - deprecate - - - - -
-

deprecate

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.

- -

To un-deprecate a package, specify an empty string ("") for the message argument.

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/api/docs.html b/deps/npm/html/api/docs.html deleted file mode 100644 index 32e0b9152..000000000 --- a/deps/npm/html/api/docs.html +++ /dev/null @@ -1,60 +0,0 @@ - - - docs - - - - -
-

docs

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.

-
- - - diff --git a/deps/npm/html/api/edit.html b/deps/npm/html/api/edit.html deleted file mode 100644 index fbe7c7084..000000000 --- a/deps/npm/html/api/edit.html +++ /dev/null @@ -1,65 +0,0 @@ - - - edit - - - - -
-

edit

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.

-
- - - diff --git a/deps/npm/html/api/explore.html b/deps/npm/html/api/explore.html deleted file mode 100644 index 757b88c8c..000000000 --- a/deps/npm/html/api/explore.html +++ /dev/null @@ -1,59 +0,0 @@ - - - explore - - - - -
-

explore

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.

-
- - - diff --git a/deps/npm/html/api/help-search.html b/deps/npm/html/api/help-search.html deleted file mode 100644 index a13a8f147..000000000 --- a/deps/npm/html/api/help-search.html +++ /dev/null @@ -1,67 +0,0 @@ - - - help-search - - - - -
-

help-search

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.

-
- - - diff --git a/deps/npm/html/api/init.html b/deps/npm/html/api/init.html deleted file mode 100644 index f7c1f8793..000000000 --- a/deps/npm/html/api/init.html +++ /dev/null @@ -1,70 +0,0 @@ - - - init - - - - -
-

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

- -

json(1)

-
- - - diff --git a/deps/npm/html/api/install.html b/deps/npm/html/api/install.html deleted file mode 100644 index 88243dfb2..000000000 --- a/deps/npm/html/api/install.html +++ /dev/null @@ -1,60 +0,0 @@ - - - install - - - - -
-

install

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.

-
- - - diff --git a/deps/npm/html/api/link.html b/deps/npm/html/api/link.html deleted file mode 100644 index 92758ca74..000000000 --- a/deps/npm/html/api/link.html +++ /dev/null @@ -1,74 +0,0 @@ - - - link - - - - -
-

link

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

-
- - - diff --git a/deps/npm/html/api/load.html b/deps/npm/html/api/load.html deleted file mode 100644 index 8e943e017..000000000 --- a/deps/npm/html/api/load.html +++ /dev/null @@ -1,67 +0,0 @@ - - - load - - - - -
-

load

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

-
- - - diff --git a/deps/npm/html/api/ls.html b/deps/npm/html/api/ls.html deleted file mode 100644 index c54a85637..000000000 --- a/deps/npm/html/api/ls.html +++ /dev/null @@ -1,94 +0,0 @@ - - - ls - - - - -
-

ls

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.

- -

Callback is provided an error if one occurred, the full data about which -packages are installed and which dependencies they will receive, and a -"lite" data object which just shows which versions are installed where. -Note that the full data object is a circular structure, so care must be -taken if it is serialized to JSON.

- -

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.

-
- - - diff --git a/deps/npm/html/api/npm.html b/deps/npm/html/api/npm.html deleted file mode 100644 index 2ec22fe91..000000000 --- a/deps/npm/html/api/npm.html +++ /dev/null @@ -1,127 +0,0 @@ - - - npm - - - - -
-

npm

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

- -

1.3.2

- -

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. -If you provide configObject as an object hash of top-level -configs, they override the values stored in the various config -locations. In the npm command line client, this set of configs -is parsed from the command line options. Additional configuration -params are loaded from two configuration files. See config(1) -for more information.

- -

After that, each of the functions are accessible in the -commands object: npm.commands.<cmd>. See 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"
-
- - - diff --git a/deps/npm/html/api/outdated.html b/deps/npm/html/api/outdated.html deleted file mode 100644 index 541276999..000000000 --- a/deps/npm/html/api/outdated.html +++ /dev/null @@ -1,54 +0,0 @@ - - - outdated - - - - -
-

outdated

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.

-
- - - diff --git a/deps/npm/html/api/owner.html b/deps/npm/html/api/owner.html deleted file mode 100644 index 3410fec3c..000000000 --- a/deps/npm/html/api/owner.html +++ /dev/null @@ -1,69 +0,0 @@ - - - owner - - - - -
-

owner

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

- - -
- - - diff --git a/deps/npm/html/api/pack.html b/deps/npm/html/api/pack.html deleted file mode 100644 index 3f9ebeddd..000000000 --- a/deps/npm/html/api/pack.html +++ /dev/null @@ -1,60 +0,0 @@ - - - pack - - - - -
-

pack

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.

-
- - - diff --git a/deps/npm/html/api/prefix.html b/deps/npm/html/api/prefix.html deleted file mode 100644 index df8f14d06..000000000 --- a/deps/npm/html/api/prefix.html +++ /dev/null @@ -1,56 +0,0 @@ - - - prefix - - - - -
-

prefix

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

-
- - - diff --git a/deps/npm/html/api/prune.html b/deps/npm/html/api/prune.html deleted file mode 100644 index b24b7b046..000000000 --- a/deps/npm/html/api/prune.html +++ /dev/null @@ -1,58 +0,0 @@ - - - prune - - - - -
-

prune

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.

-
- - - diff --git a/deps/npm/html/api/publish.html b/deps/npm/html/api/publish.html deleted file mode 100644 index 6f3d9db49..000000000 --- a/deps/npm/html/api/publish.html +++ /dev/null @@ -1,67 +0,0 @@ - - - publish - - - - -
-

publish

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

- - -
- - - diff --git a/deps/npm/html/api/rebuild.html b/deps/npm/html/api/rebuild.html deleted file mode 100644 index da4929e38..000000000 --- a/deps/npm/html/api/rebuild.html +++ /dev/null @@ -1,57 +0,0 @@ - - - rebuild - - - - -
-

rebuild

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

-
- - - diff --git a/deps/npm/html/api/restart.html b/deps/npm/html/api/restart.html deleted file mode 100644 index fae57f3f0..000000000 --- a/deps/npm/html/api/restart.html +++ /dev/null @@ -1,62 +0,0 @@ - - - restart - - - - -
-

restart

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

- - -
- - - diff --git a/deps/npm/html/api/root.html b/deps/npm/html/api/root.html deleted file mode 100644 index 6c8100a18..000000000 --- a/deps/npm/html/api/root.html +++ /dev/null @@ -1,56 +0,0 @@ - - - root - - - - -
-

root

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.

-
- - - diff --git a/deps/npm/html/api/run-script.html b/deps/npm/html/api/run-script.html deleted file mode 100644 index 91d27aeb5..000000000 --- a/deps/npm/html/api/run-script.html +++ /dev/null @@ -1,64 +0,0 @@ - - - run-script - - - - -
-

run-script

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

- - -
- - - diff --git a/deps/npm/html/api/search.html b/deps/npm/html/api/search.html deleted file mode 100644 index ffb4b54b8..000000000 --- a/deps/npm/html/api/search.html +++ /dev/null @@ -1,67 +0,0 @@ - - - search - - - - -
-

search

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

-
- - - diff --git a/deps/npm/html/api/shrinkwrap.html b/deps/npm/html/api/shrinkwrap.html deleted file mode 100644 index b17aa0a68..000000000 --- a/deps/npm/html/api/shrinkwrap.html +++ /dev/null @@ -1,61 +0,0 @@ - - - shrinkwrap - - - - -
-

shrinkwrap

programmatically generate package shrinkwrap file

- -

SYNOPSIS

- -
npm.commands.shrinkwrap(args, [silent,] callback)
- -

DESCRIPTION

- -

This acts much the same ways as shrinkwrapping on the command-line.

- -

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.

- -

If the 'silent' parameter is set to true, nothing will be output to the screen, -but the shrinkwrap file will still be written.

- -

Finally, 'callback' is a function that will be called when the shrinkwrap has -been saved.

-
- - - diff --git a/deps/npm/html/api/start.html b/deps/npm/html/api/start.html deleted file mode 100644 index 474758def..000000000 --- a/deps/npm/html/api/start.html +++ /dev/null @@ -1,54 +0,0 @@ - - - start - - - - -
-

start

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.

-
- - - diff --git a/deps/npm/html/api/stop.html b/deps/npm/html/api/stop.html deleted file mode 100644 index 806f4b5e5..000000000 --- a/deps/npm/html/api/stop.html +++ /dev/null @@ -1,54 +0,0 @@ - - - stop - - - - -
-

stop

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.

-
- - - diff --git a/deps/npm/html/api/submodule.html b/deps/npm/html/api/submodule.html deleted file mode 100644 index 07cb0c8f1..000000000 --- a/deps/npm/html/api/submodule.html +++ /dev/null @@ -1,68 +0,0 @@ - - - submodule - - - - -
-

submodule

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
-
- - - diff --git a/deps/npm/html/api/tag.html b/deps/npm/html/api/tag.html deleted file mode 100644 index b5d185e08..000000000 --- a/deps/npm/html/api/tag.html +++ /dev/null @@ -1,64 +0,0 @@ - - - tag - - - - -
-

tag

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.

-
- - - diff --git a/deps/npm/html/api/test.html b/deps/npm/html/api/test.html deleted file mode 100644 index 0048f1390..000000000 --- a/deps/npm/html/api/test.html +++ /dev/null @@ -1,57 +0,0 @@ - - - test - - - - -
-

test

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.

-
- - - diff --git a/deps/npm/html/api/uninstall.html b/deps/npm/html/api/uninstall.html deleted file mode 100644 index d1714bbb8..000000000 --- a/deps/npm/html/api/uninstall.html +++ /dev/null @@ -1,57 +0,0 @@ - - - uninstall - - - - -
-

uninstall

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.

-
- - - diff --git a/deps/npm/html/api/unpublish.html b/deps/npm/html/api/unpublish.html deleted file mode 100644 index a2be62ee6..000000000 --- a/deps/npm/html/api/unpublish.html +++ /dev/null @@ -1,61 +0,0 @@ - - - unpublish - - - - -
-

unpublish

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.

-
- - - diff --git a/deps/npm/html/api/update.html b/deps/npm/html/api/update.html deleted file mode 100644 index 610e7798a..000000000 --- a/deps/npm/html/api/update.html +++ /dev/null @@ -1,53 +0,0 @@ - - - update - - - - -
-

update

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.

-
- - - diff --git a/deps/npm/html/api/version.html b/deps/npm/html/api/version.html deleted file mode 100644 index c4a4dcbf1..000000000 --- a/deps/npm/html/api/version.html +++ /dev/null @@ -1,59 +0,0 @@ - - - version - - - - -
-

version

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.

-
- - - diff --git a/deps/npm/html/api/view.html b/deps/npm/html/api/view.html deleted file mode 100644 index 667cf391d..000000000 --- a/deps/npm/html/api/view.html +++ /dev/null @@ -1,134 +0,0 @@ - - - view - - - - -
-

view

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.

-
- - - diff --git a/deps/npm/html/api/whoami.html b/deps/npm/html/api/whoami.html deleted file mode 100644 index 445fe40f9..000000000 --- a/deps/npm/html/api/whoami.html +++ /dev/null @@ -1,56 +0,0 @@ - - - whoami - - - - -
-

whoami

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

-
- - - diff --git a/deps/npm/html/doc/README.html b/deps/npm/html/doc/README.html index edaf7379c..9d666ede3 100644 --- a/deps/npm/html/doc/README.html +++ b/deps/npm/html/doc/README.html @@ -6,7 +6,7 @@
-

npm

node package manager

+

npm

node package manager

SYNOPSIS

@@ -238,9 +238,9 @@ will no doubt tell you to put the output in a gist or email.

SEE ALSO

- +
- + - diff --git a/deps/npm/html/doc/adduser.html b/deps/npm/html/doc/adduser.html deleted file mode 100644 index 83a6af40b..000000000 --- a/deps/npm/html/doc/adduser.html +++ /dev/null @@ -1,74 +0,0 @@ - - - adduser - - - - -
-

adduser

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

- - -
- - - diff --git a/deps/npm/html/doc/api/npm-bin.html b/deps/npm/html/doc/api/npm-bin.html new file mode 100644 index 000000000..d382f6cc5 --- /dev/null +++ b/deps/npm/html/doc/api/npm-bin.html @@ -0,0 +1,53 @@ + + + npm-bin + + + + +
+

npm-bin

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.

+
+ + diff --git a/deps/npm/html/doc/api/npm-bugs.html b/deps/npm/html/doc/api/npm-bugs.html new file mode 100644 index 000000000..0c7baa416 --- /dev/null +++ b/deps/npm/html/doc/api/npm-bugs.html @@ -0,0 +1,59 @@ + + + npm-bugs + + + + +
+

npm-bugs

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.

+
+ + diff --git a/deps/npm/html/doc/api/npm-commands.html b/deps/npm/html/doc/api/npm-commands.html new file mode 100644 index 000000000..f06443906 --- /dev/null +++ b/deps/npm/html/doc/api/npm-commands.html @@ -0,0 +1,62 @@ + + + npm-commands + + + + +
+

npm-commands

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

+ + +
+ + diff --git a/deps/npm/html/doc/api/npm-config.html b/deps/npm/html/doc/api/npm-config.html new file mode 100644 index 000000000..ba89c10b7 --- /dev/null +++ b/deps/npm/html/doc/api/npm-config.html @@ -0,0 +1,67 @@ + + + npm-config + + + + +
+

npm-config

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

+ + +
+ + diff --git a/deps/npm/html/doc/api/npm-deprecate.html b/deps/npm/html/doc/api/npm-deprecate.html new file mode 100644 index 000000000..710b1317c --- /dev/null +++ b/deps/npm/html/doc/api/npm-deprecate.html @@ -0,0 +1,66 @@ + + + npm-deprecate + + + + +
+

npm-deprecate

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.

+ +

To un-deprecate a package, specify an empty string ("") for the message argument.

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/api/npm-docs.html b/deps/npm/html/doc/api/npm-docs.html new file mode 100644 index 000000000..dc4066faa --- /dev/null +++ b/deps/npm/html/doc/api/npm-docs.html @@ -0,0 +1,59 @@ + + + npm-docs + + + + +
+

npm-docs

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.

+
+ + diff --git a/deps/npm/html/doc/api/npm-edit.html b/deps/npm/html/doc/api/npm-edit.html new file mode 100644 index 000000000..4cebcaf7d --- /dev/null +++ b/deps/npm/html/doc/api/npm-edit.html @@ -0,0 +1,64 @@ + + + npm-edit + + + + +
+

npm-edit

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.

+
+ + diff --git a/deps/npm/html/doc/api/npm-explore.html b/deps/npm/html/doc/api/npm-explore.html new file mode 100644 index 000000000..2490a1629 --- /dev/null +++ b/deps/npm/html/doc/api/npm-explore.html @@ -0,0 +1,58 @@ + + + npm-explore + + + + +
+

npm-explore

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.

+
+ + diff --git a/deps/npm/html/doc/api/npm-help-search.html b/deps/npm/html/doc/api/npm-help-search.html new file mode 100644 index 000000000..23b538bbc --- /dev/null +++ b/deps/npm/html/doc/api/npm-help-search.html @@ -0,0 +1,66 @@ + + + npm-help-search + + + + +
+

npm-help-search

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.

+
+ + diff --git a/deps/npm/html/doc/api/npm-init.html b/deps/npm/html/doc/api/npm-init.html new file mode 100644 index 000000000..5351ae640 --- /dev/null +++ b/deps/npm/html/doc/api/npm-init.html @@ -0,0 +1,69 @@ + + + npm-init + + + + +
+

npm init

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

+ +

package.json(5)

+
+ + diff --git a/deps/npm/html/doc/api/npm-install.html b/deps/npm/html/doc/api/npm-install.html new file mode 100644 index 000000000..3dd99b0ba --- /dev/null +++ b/deps/npm/html/doc/api/npm-install.html @@ -0,0 +1,59 @@ + + + npm-install + + + + +
+

npm-install

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.

+
+ + diff --git a/deps/npm/html/doc/api/npm-link.html b/deps/npm/html/doc/api/npm-link.html new file mode 100644 index 000000000..1927bbb58 --- /dev/null +++ b/deps/npm/html/doc/api/npm-link.html @@ -0,0 +1,73 @@ + + + npm-link + + + + +
+

npm-link

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

+
+ + diff --git a/deps/npm/html/doc/api/npm-load.html b/deps/npm/html/doc/api/npm-load.html new file mode 100644 index 000000000..0304848c8 --- /dev/null +++ b/deps/npm/html/doc/api/npm-load.html @@ -0,0 +1,66 @@ + + + npm-load + + + + +
+

npm-load

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

+
+ + diff --git a/deps/npm/html/doc/api/npm-ls.html b/deps/npm/html/doc/api/npm-ls.html new file mode 100644 index 000000000..29edbd52b --- /dev/null +++ b/deps/npm/html/doc/api/npm-ls.html @@ -0,0 +1,93 @@ + + + npm-ls + + + + +
+

npm-ls

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.

+ +

Callback is provided an error if one occurred, the full data about which +packages are installed and which dependencies they will receive, and a +"lite" data object which just shows which versions are installed where. +Note that the full data object is a circular structure, so care must be +taken if it is serialized to JSON.

+ +

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.

+
+ + diff --git a/deps/npm/html/doc/api/npm-outdated.html b/deps/npm/html/doc/api/npm-outdated.html new file mode 100644 index 000000000..b4b0b5eb4 --- /dev/null +++ b/deps/npm/html/doc/api/npm-outdated.html @@ -0,0 +1,53 @@ + + + npm-outdated + + + + +
+

npm-outdated

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.

+
+ + diff --git a/deps/npm/html/doc/api/npm-owner.html b/deps/npm/html/doc/api/npm-owner.html new file mode 100644 index 000000000..329c999a3 --- /dev/null +++ b/deps/npm/html/doc/api/npm-owner.html @@ -0,0 +1,68 @@ + + + npm-owner + + + + +
+

npm-owner

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

+ + +
+ + diff --git a/deps/npm/html/doc/api/npm-pack.html b/deps/npm/html/doc/api/npm-pack.html new file mode 100644 index 000000000..9865de5b2 --- /dev/null +++ b/deps/npm/html/doc/api/npm-pack.html @@ -0,0 +1,59 @@ + + + npm-pack + + + + +
+

npm-pack

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.

+
+ + diff --git a/deps/npm/html/doc/api/npm-prefix.html b/deps/npm/html/doc/api/npm-prefix.html new file mode 100644 index 000000000..70f023d32 --- /dev/null +++ b/deps/npm/html/doc/api/npm-prefix.html @@ -0,0 +1,55 @@ + + + npm-prefix + + + + +
+

npm-prefix

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

+
+ + diff --git a/deps/npm/html/doc/api/npm-prune.html b/deps/npm/html/doc/api/npm-prune.html new file mode 100644 index 000000000..0deaa39da --- /dev/null +++ b/deps/npm/html/doc/api/npm-prune.html @@ -0,0 +1,57 @@ + + + npm-prune + + + + +
+

npm-prune

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.

+
+ + diff --git a/deps/npm/html/doc/api/npm-publish.html b/deps/npm/html/doc/api/npm-publish.html new file mode 100644 index 000000000..d6738cb22 --- /dev/null +++ b/deps/npm/html/doc/api/npm-publish.html @@ -0,0 +1,66 @@ + + + npm-publish + + + + +
+

npm-publish

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

+ + +
+ + diff --git a/deps/npm/html/doc/api/npm-rebuild.html b/deps/npm/html/doc/api/npm-rebuild.html new file mode 100644 index 000000000..f7049b7c6 --- /dev/null +++ b/deps/npm/html/doc/api/npm-rebuild.html @@ -0,0 +1,56 @@ + + + npm-rebuild + + + + +
+

npm-rebuild

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

+
+ + diff --git a/deps/npm/html/doc/api/npm-restart.html b/deps/npm/html/doc/api/npm-restart.html new file mode 100644 index 000000000..8f9bea94d --- /dev/null +++ b/deps/npm/html/doc/api/npm-restart.html @@ -0,0 +1,61 @@ + + + npm-restart + + + + +
+

npm-restart

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

+ + +
+ + diff --git a/deps/npm/html/doc/api/npm-root.html b/deps/npm/html/doc/api/npm-root.html new file mode 100644 index 000000000..41620111e --- /dev/null +++ b/deps/npm/html/doc/api/npm-root.html @@ -0,0 +1,55 @@ + + + npm-root + + + + +
+

npm-root

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.

+
+ + diff --git a/deps/npm/html/doc/api/npm-run-script.html b/deps/npm/html/doc/api/npm-run-script.html new file mode 100644 index 000000000..b774624be --- /dev/null +++ b/deps/npm/html/doc/api/npm-run-script.html @@ -0,0 +1,63 @@ + + + npm-run-script + + + + +
+

npm-run-script

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

+ + +
+ + diff --git a/deps/npm/html/doc/api/npm-search.html b/deps/npm/html/doc/api/npm-search.html new file mode 100644 index 000000000..ebda46651 --- /dev/null +++ b/deps/npm/html/doc/api/npm-search.html @@ -0,0 +1,66 @@ + + + npm-search + + + + +
+

npm-search

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

+
+ + diff --git a/deps/npm/html/doc/api/npm-shrinkwrap.html b/deps/npm/html/doc/api/npm-shrinkwrap.html new file mode 100644 index 000000000..5100bb9d0 --- /dev/null +++ b/deps/npm/html/doc/api/npm-shrinkwrap.html @@ -0,0 +1,60 @@ + + + npm-shrinkwrap + + + + +
+

npm-shrinkwrap

programmatically generate package shrinkwrap file

+ +

SYNOPSIS

+ +
npm.commands.shrinkwrap(args, [silent,] callback)
+ +

DESCRIPTION

+ +

This acts much the same ways as shrinkwrapping on the command-line.

+ +

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.

+ +

If the 'silent' parameter is set to true, nothing will be output to the screen, +but the shrinkwrap file will still be written.

+ +

Finally, 'callback' is a function that will be called when the shrinkwrap has +been saved.

+
+ + diff --git a/deps/npm/html/doc/api/npm-start.html b/deps/npm/html/doc/api/npm-start.html new file mode 100644 index 000000000..9971516a0 --- /dev/null +++ b/deps/npm/html/doc/api/npm-start.html @@ -0,0 +1,53 @@ + + + npm-start + + + + +
+

npm-start

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.

+
+ + diff --git a/deps/npm/html/doc/api/npm-stop.html b/deps/npm/html/doc/api/npm-stop.html new file mode 100644 index 000000000..677de4208 --- /dev/null +++ b/deps/npm/html/doc/api/npm-stop.html @@ -0,0 +1,53 @@ + + + npm-stop + + + + +
+

npm-stop

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.

+
+ + diff --git a/deps/npm/html/doc/api/npm-submodule.html b/deps/npm/html/doc/api/npm-submodule.html new file mode 100644 index 000000000..3b23c5fca --- /dev/null +++ b/deps/npm/html/doc/api/npm-submodule.html @@ -0,0 +1,67 @@ + + + npm-submodule + + + + +
+

npm-submodule

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
+
+ + diff --git a/deps/npm/html/doc/api/npm-tag.html b/deps/npm/html/doc/api/npm-tag.html new file mode 100644 index 000000000..0eaee2b53 --- /dev/null +++ b/deps/npm/html/doc/api/npm-tag.html @@ -0,0 +1,63 @@ + + + npm-tag + + + + +
+

npm-tag

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.

+
+ + diff --git a/deps/npm/html/doc/api/npm-test.html b/deps/npm/html/doc/api/npm-test.html new file mode 100644 index 000000000..68c64bb04 --- /dev/null +++ b/deps/npm/html/doc/api/npm-test.html @@ -0,0 +1,56 @@ + + + npm-test + + + + +
+

npm-test

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.

+
+ + diff --git a/deps/npm/html/doc/api/npm-uninstall.html b/deps/npm/html/doc/api/npm-uninstall.html new file mode 100644 index 000000000..67d7ae780 --- /dev/null +++ b/deps/npm/html/doc/api/npm-uninstall.html @@ -0,0 +1,56 @@ + + + npm-uninstall + + + + +
+

npm-uninstall

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.

+
+ + diff --git a/deps/npm/html/doc/api/npm-unpublish.html b/deps/npm/html/doc/api/npm-unpublish.html new file mode 100644 index 000000000..195fc987c --- /dev/null +++ b/deps/npm/html/doc/api/npm-unpublish.html @@ -0,0 +1,60 @@ + + + npm-unpublish + + + + +
+

npm-unpublish

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.

+
+ + diff --git a/deps/npm/html/doc/api/npm-update.html b/deps/npm/html/doc/api/npm-update.html new file mode 100644 index 000000000..f6f8a926a --- /dev/null +++ b/deps/npm/html/doc/api/npm-update.html @@ -0,0 +1,52 @@ + + + npm-update + + + + +
+

npm-update

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.

+
+ + diff --git a/deps/npm/html/doc/api/npm-version.html b/deps/npm/html/doc/api/npm-version.html new file mode 100644 index 000000000..33f66a4bc --- /dev/null +++ b/deps/npm/html/doc/api/npm-version.html @@ -0,0 +1,58 @@ + + + npm-version + + + + +
+

npm-version

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.

+
+ + diff --git a/deps/npm/html/doc/api/npm-view.html b/deps/npm/html/doc/api/npm-view.html new file mode 100644 index 000000000..aef457fd9 --- /dev/null +++ b/deps/npm/html/doc/api/npm-view.html @@ -0,0 +1,133 @@ + + + npm-view + + + + +
+

npm-view

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.

+
+ + diff --git a/deps/npm/html/doc/api/npm-whoami.html b/deps/npm/html/doc/api/npm-whoami.html new file mode 100644 index 000000000..50fcfe925 --- /dev/null +++ b/deps/npm/html/doc/api/npm-whoami.html @@ -0,0 +1,55 @@ + + + npm-whoami + + + + +
+

npm-whoami

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

+
+ + diff --git a/deps/npm/html/doc/api/npm.html b/deps/npm/html/doc/api/npm.html new file mode 100644 index 000000000..5c0aa6c2e --- /dev/null +++ b/deps/npm/html/doc/api/npm.html @@ -0,0 +1,126 @@ + + + npm + + + + +
+

npm

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

+ +

1.3.3

+ +

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. +If you provide configObject as an object hash of top-level +configs, they override the values stored in the various config +locations. In the npm command line client, this set of configs +is parsed from the command line options. Additional configuration +params are loaded from two configuration files. See npm-config(1), +npm-config(7), and npmrc(5) for more information.

+ +

After that, each of the functions are accessible in the +commands object: npm.commands.<cmd>. See npm-index(7) 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"
+
+ + diff --git a/deps/npm/html/doc/bin.html b/deps/npm/html/doc/bin.html deleted file mode 100644 index 5e02f5f66..000000000 --- a/deps/npm/html/doc/bin.html +++ /dev/null @@ -1,55 +0,0 @@ - - - bin - - - - -
-

bin

Display npm bin folder

- -

SYNOPSIS

- -
npm bin
- -

DESCRIPTION

- -

Print the folder where npm will install executables.

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/bugs.html b/deps/npm/html/doc/bugs.html deleted file mode 100644 index effc9ea34..000000000 --- a/deps/npm/html/doc/bugs.html +++ /dev/null @@ -1,71 +0,0 @@ - - - bugs - - - - -
-

bugs

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", Windows: "start", Others: "xdg-open"
  • 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

- - -
- - - diff --git a/deps/npm/html/doc/build.html b/deps/npm/html/doc/build.html deleted file mode 100644 index ca5bbe872..000000000 --- a/deps/npm/html/doc/build.html +++ /dev/null @@ -1,60 +0,0 @@ - - - build - - - - -
-

build

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

- - -
- - - diff --git a/deps/npm/html/doc/bundle.html b/deps/npm/html/doc/bundle.html deleted file mode 100644 index 92b627330..000000000 --- a/deps/npm/html/doc/bundle.html +++ /dev/null @@ -1,55 +0,0 @@ - - - bundle - - - - -
-

bundle

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

- - -
- - - diff --git a/deps/npm/html/doc/cache.html b/deps/npm/html/doc/cache.html deleted file mode 100644 index fb9da2d5c..000000000 --- a/deps/npm/html/doc/cache.html +++ /dev/null @@ -1,101 +0,0 @@ - - - cache - - - - -
-

cache

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

- - -
- - - diff --git a/deps/npm/html/doc/changelog.html b/deps/npm/html/doc/changelog.html deleted file mode 100644 index 9be4c8db0..000000000 --- a/deps/npm/html/doc/changelog.html +++ /dev/null @@ -1,100 +0,0 @@ - - - changelog - - - - -
-

changelog

Changes

- -

HISTORY

- -

1.1.3, 1.1.4

- -
  • Update request to support HTTPS-over-HTTP proxy tunneling
  • Throw on undefined envs in config settings
  • Update which to 1.0.5
  • Fix windows UNC busyloop in findPrefix
  • Bundle nested bundleDependencies properly
  • Alias adduser to add-user
  • Doc updates (Christian Howe, Henrik Hodne, Andrew Lunny)
  • ignore logfd/outfd streams in makeEnv() (Rod Vagg)
  • shrinkwrap: Behave properly with url-installed deps
  • install: Support --save with url install targets
  • Support installing naked tars or single-file modules from urls etc.
  • init: Don't add engines section
  • Don't run make clean on rebuild
  • Added missing unicode replacement (atomizer)
- -

1.1.2

- -

Dave Pacheco (2): - add "npm shrinkwrap"

- -

Martin Cooper (1): - Fix #1753 Make a copy of the cached objects we'll modify.

- -

Tim Oxley (1): - correctly remove readme from default npm view command.

- -

Tyler Green (1): - fix #2187 set terminal columns to Infinity if 0

- -

isaacs (19): - update minimatch - update request - Experimental: single-file modules - Fix #2172 Don't remove global mans uninstalling local pkgs - Add --versions flag to show the version of node as well - Support --json flag for ls output - update request to 2.9.151

- -

1.1

- -
  • Replace system tar dependency with a JS tar
  • Continue to refine
- -

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

- - -
- - - diff --git a/deps/npm/html/doc/cli/npm-adduser.html b/deps/npm/html/doc/cli/npm-adduser.html new file mode 100644 index 000000000..bc30e260d --- /dev/null +++ b/deps/npm/html/doc/cli/npm-adduser.html @@ -0,0 +1,73 @@ + + + npm-adduser + + + + +
+

npm-adduser

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

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-bin.html b/deps/npm/html/doc/cli/npm-bin.html new file mode 100644 index 000000000..90fc9b27f --- /dev/null +++ b/deps/npm/html/doc/cli/npm-bin.html @@ -0,0 +1,54 @@ + + + npm-bin + + + + +
+

npm-bin

Display npm bin folder

+ +

SYNOPSIS

+ +
npm bin
+ +

DESCRIPTION

+ +

Print the folder where npm will install executables.

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-bugs.html b/deps/npm/html/doc/cli/npm-bugs.html new file mode 100644 index 000000000..e4fa6c2c0 --- /dev/null +++ b/deps/npm/html/doc/cli/npm-bugs.html @@ -0,0 +1,70 @@ + + + npm-bugs + + + + +
+

npm-bugs

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", Windows: "start", Others: "xdg-open"
  • 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

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-build.html b/deps/npm/html/doc/cli/npm-build.html new file mode 100644 index 000000000..3b5f63a57 --- /dev/null +++ b/deps/npm/html/doc/cli/npm-build.html @@ -0,0 +1,59 @@ + + + npm-build + + + + +
+

npm-build

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

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-bundle.html b/deps/npm/html/doc/cli/npm-bundle.html new file mode 100644 index 000000000..8a6e66eac --- /dev/null +++ b/deps/npm/html/doc/cli/npm-bundle.html @@ -0,0 +1,54 @@ + + + npm-bundle + + + + +
+

npm-bundle

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

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-cache.html b/deps/npm/html/doc/cli/npm-cache.html new file mode 100644 index 000000000..d3565d0f2 --- /dev/null +++ b/deps/npm/html/doc/cli/npm-cache.html @@ -0,0 +1,100 @@ + + + npm-cache + + + + +
+

npm-cache

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

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-completion.html b/deps/npm/html/doc/cli/npm-completion.html new file mode 100644 index 000000000..b411f2d72 --- /dev/null +++ b/deps/npm/html/doc/cli/npm-completion.html @@ -0,0 +1,67 @@ + + + npm-completion + + + + +
+

npm-completion

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

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-config.html b/deps/npm/html/doc/cli/npm-config.html new file mode 100644 index 000000000..c2b0d3e61 --- /dev/null +++ b/deps/npm/html/doc/cli/npm-config.html @@ -0,0 +1,106 @@ + + + npm-config + + + + +
+

npm-config

Manage the npm configuration files

+ +

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 config settings from the command line, environment +variables, npmrc files, and in some cases, the package.json file.

+ +

See npmrc(5) for more information about the npmrc files.

+ +

See npm-config(7) for a more thorough discussion of the mechanisms +involved.

+ +

The npm config command can be used to update and edit the contents +of the user and global npmrc files.

+ +

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.

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-dedupe.html b/deps/npm/html/doc/cli/npm-dedupe.html new file mode 100644 index 000000000..6d541ba8e --- /dev/null +++ b/deps/npm/html/doc/cli/npm-dedupe.html @@ -0,0 +1,91 @@ + + + npm-dedupe + + + + +
+

npm-dedupe

Reduce duplication

+ +

SYNOPSIS

+ +
npm dedupe [package names...]
+ +

DESCRIPTION

+ +

Searches the local package tree and attempts to simplify the overall +structure by moving dependencies further up the tree, where they can +be more effectively shared by multiple dependent packages.

+ +

For example, consider this dependency graph:

+ +
a
++-- b <-- depends on c@1.0.x
+|   `-- c@1.0.3
+`-- d <-- depends on c@~1.0.9
+    `-- c@1.0.10
+ +

In this case, npm-dedupe(1) will transform the tree to:

+ +
a
++-- b
++-- d
+`-- c@1.0.10
+ +

Because of the hierarchical nature of node's module lookup, b and d +will both get their dependency met by the single c package at the root +level of the tree.

+ +

If a suitable version exists at the target location in the tree +already, then it will be left untouched, but the other duplicates will +be deleted.

+ +

If no suitable version can be found, then a warning is printed, and +nothing is done.

+ +

If any arguments are supplied, then they are filters, and only the +named packages will be touched.

+ +

Note that this operation transforms the dependency tree, and may +result in packages getting updated versions, perhaps from the npm +registry.

+ +

This feature is experimental, and may change in future versions.

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-deprecate.html b/deps/npm/html/doc/cli/npm-deprecate.html new file mode 100644 index 000000000..0c446c92f --- /dev/null +++ b/deps/npm/html/doc/cli/npm-deprecate.html @@ -0,0 +1,65 @@ + + + npm-deprecate + + + + +
+

npm-deprecate

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.

+ +

To un-deprecate a package, specify an empty string ("") for the message argument.

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-docs.html b/deps/npm/html/doc/cli/npm-docs.html new file mode 100644 index 000000000..cbb6272e0 --- /dev/null +++ b/deps/npm/html/doc/cli/npm-docs.html @@ -0,0 +1,71 @@ + + + npm-docs + + + + +
+

npm-docs

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", Windows: "start", Others: "xdg-open"
  • 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

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-edit.html b/deps/npm/html/doc/cli/npm-edit.html new file mode 100644 index 000000000..dcaef08f4 --- /dev/null +++ b/deps/npm/html/doc/cli/npm-edit.html @@ -0,0 +1,71 @@ + + + npm-edit + + + + +
+

npm-edit

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(7).)

+ +

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

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-explore.html b/deps/npm/html/doc/cli/npm-explore.html new file mode 100644 index 000000000..2afa7667b --- /dev/null +++ b/deps/npm/html/doc/cli/npm-explore.html @@ -0,0 +1,74 @@ + + + npm-explore + + + + +
+

npm-explore

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

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-help-search.html b/deps/npm/html/doc/cli/npm-help-search.html new file mode 100644 index 000000000..18cebe5cb --- /dev/null +++ b/deps/npm/html/doc/cli/npm-help-search.html @@ -0,0 +1,72 @@ + + + npm-help-search + + + + +
+

npm-help-search

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

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-help.html b/deps/npm/html/doc/cli/npm-help.html new file mode 100644 index 000000000..7e9dfc652 --- /dev/null +++ b/deps/npm/html/doc/cli/npm-help.html @@ -0,0 +1,70 @@ + + + npm-help + + + + +
+

npm-help

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

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-init.html b/deps/npm/html/doc/cli/npm-init.html new file mode 100644 index 000000000..d44912f8d --- /dev/null +++ b/deps/npm/html/doc/cli/npm-init.html @@ -0,0 +1,63 @@ + + + npm-init + + + + +
+

npm-init

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

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-install.html b/deps/npm/html/doc/cli/npm-install.html new file mode 100644 index 000000000..eddb9379a --- /dev/null +++ b/deps/npm/html/doc/cli/npm-install.html @@ -0,0 +1,176 @@ + + + npm-install + + + + +
+

npm-install

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> [--save|--save-dev|--save-optional]
+npm install <name>@<tag>
+npm install <name>@<version>
+npm install <name>@<version range>
+npm install <name>@<version range>
+ +

DESCRIPTION

+ +

This command installs a package, and any packages that it depends on. If the +package has a shrinkwrap file, the installation of dependencies will be driven +by that. See npm-shrinkwrap(1).

+ +

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> [--save|--save-dev|--save-optional]:

    Do a <name>@<tag> install, where <tag> is the "tag" config. (See +npm-config(7).)

    In most cases, this will install the latest version +of the module published on npm.

    Example:

    npm install sax

    npm install takes 3 exclusive, optional flags which save or update +the package version in your main package.json:

    • --save: Package will appear in your dependencies.

    • --save-dev: Package will appear in your devDependencies.

    • --save-optional: Package will appear in your optionalDependencies.

      Examples:

      npm install sax --save + npm install node-tap --save-dev + npm install dtrace-provider --save-optional

      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 package.json(5).

    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-folders(7).

+ +

The --link argument will cause npm to link global installs into the +local space in some cases.

+ +

The --no-bin-links argument will prevent npm from creating symlinks for +any binaries the package might contain.

+ +

The --no-shrinkwrap argument, which will ignore an available +shrinkwrap file and use the package.json instead.

+ +

The --nodedir=/path/to/node/source argument will allow npm to find the +node source code so that npm can compile native modules.

+ +

See npm-config(7). 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(7) 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

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-link.html b/deps/npm/html/doc/cli/npm-link.html new file mode 100644 index 000000000..acf1fbd27 --- /dev/null +++ b/deps/npm/html/doc/cli/npm-link.html @@ -0,0 +1,95 @@ + + + npm-link + + + + +
+

npm-link

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.

+ +

Note that package-name is taken from package.json , +not from directory name.

+ +

When creating tarballs for npm publish, the linked packages are +"snapshotted" to their current state by resolving the symbolic links.

+ +

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

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-ls.html b/deps/npm/html/doc/cli/npm-ls.html new file mode 100644 index 000000000..112a74fde --- /dev/null +++ b/deps/npm/html/doc/cli/npm-ls.html @@ -0,0 +1,102 @@ + + + npm-ls + + + + +
+

npm-ls

List installed packages

+ +

SYNOPSIS

+ +
npm list [<pkg> ...]
+npm ls [<pkg> ...]
+npm la [<pkg> ...]
+npm ll [<pkg> ...]
+ +

DESCRIPTION

+ +

This command will print to stdout all the versions of packages that are +installed, as well as their dependencies, in a tree-structure.

+ +

Positional arguments are name@version-range identifiers, which will +limit the results to only the paths to the packages named. Note that +nested packages will also show the paths to the specified packages. +For example, running npm ls promzard in npm's source tree will show:

+ +
npm@1.3.3 /path/to/npm
+└─┬ init-package-json@0.0.4
+  └── promzard@0.1.5
+ +

It will print out extraneous, missing, and invalid packages.

+ +

If a project specifies git urls for dependencies these are shown +in parentheses after the name@version to make it easier for users to +recognize potential forks of a project.

+ +

When run as ll or la, it shows extended information by default.

+ +

CONFIGURATION

+ +

json

+ +
  • Default: false
  • Type: Boolean
+ +

Show information in JSON format.

+ +

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

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-outdated.html b/deps/npm/html/doc/cli/npm-outdated.html new file mode 100644 index 000000000..e4361be14 --- /dev/null +++ b/deps/npm/html/doc/cli/npm-outdated.html @@ -0,0 +1,55 @@ + + + npm-outdated + + + + +
+

npm-outdated

Check for outdated packages

+ +

SYNOPSIS

+ +
npm outdated [<name> [<name> ...]]
+ +

DESCRIPTION

+ +

This command will check the registry to see if any (or, specific) installed +packages are currently outdated.

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-owner.html b/deps/npm/html/doc/cli/npm-owner.html new file mode 100644 index 000000000..a90a1d812 --- /dev/null +++ b/deps/npm/html/doc/cli/npm-owner.html @@ -0,0 +1,68 @@ + + + npm-owner + + + + +
+

npm-owner

Manage package owners

+ +

SYNOPSIS

+ +
npm owner ls <package name>
+npm owner add <user> <package name>
+npm owner rm <user> <package name>
+ +

DESCRIPTION

+ +

Manage ownership of published packages.

+ +
  • ls: +List all the users who have access to modify a package and push new versions. +Handy when you need to know who to bug for help.
  • add: +Add a new user as a maintainer of a package. This user is enabled to modify +metadata, publish new versions, and add other owners.
  • rm: +Remove a user from the package owner list. This immediately revokes their +privileges.
+ +

Note that there is only one level of access. Either you can modify a package, +or you can't. Future versions may contain more fine-grained access levels, but +that is not implemented at this time.

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-pack.html b/deps/npm/html/doc/cli/npm-pack.html new file mode 100644 index 000000000..a58def5a4 --- /dev/null +++ b/deps/npm/html/doc/cli/npm-pack.html @@ -0,0 +1,63 @@ + + + npm-pack + + + + +
+

npm-pack

Create a tarball from a package

+ +

SYNOPSIS

+ +
npm pack [<pkg> [<pkg> ...]]
+ +

DESCRIPTION

+ +

For anything that's installable (that is, a package folder, tarball, +tarball url, name@tag, name@version, or name), this command will fetch +it to the cache, and then copy the tarball to the current working +directory as <name>-<version>.tgz, and then write the filenames out to +stdout.

+ +

If the same package is specified multiple times, then the file will be +overwritten the second time.

+ +

If no arguments are supplied, then npm packs the current package folder.

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-prefix.html b/deps/npm/html/doc/cli/npm-prefix.html new file mode 100644 index 000000000..b803d5b54 --- /dev/null +++ b/deps/npm/html/doc/cli/npm-prefix.html @@ -0,0 +1,54 @@ + + + npm-prefix + + + + +
+

npm-prefix

Display prefix

+ +

SYNOPSIS

+ +
npm prefix
+ +

DESCRIPTION

+ +

Print the prefix to standard out.

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-prune.html b/deps/npm/html/doc/cli/npm-prune.html new file mode 100644 index 000000000..7cdab9518 --- /dev/null +++ b/deps/npm/html/doc/cli/npm-prune.html @@ -0,0 +1,59 @@ + + + npm-prune + + + + +
+

npm-prune

Remove extraneous packages

+ +

SYNOPSIS

+ +
npm prune [<name> [<name ...]]
+ +

DESCRIPTION

+ +

This command removes "extraneous" packages. If a package name is +provided, then only packages matching one of the supplied names are +removed.

+ +

Extraneous packages are packages that are not listed on the parent +package's dependencies list.

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-publish.html b/deps/npm/html/doc/cli/npm-publish.html new file mode 100644 index 000000000..506c95093 --- /dev/null +++ b/deps/npm/html/doc/cli/npm-publish.html @@ -0,0 +1,63 @@ + + + npm-publish + + + + +
+

npm-publish

Publish a package

+ +

SYNOPSIS

+ +
npm publish <tarball>
+npm publish <folder>
+ +

DESCRIPTION

+ +

Publishes a package to the registry so that it can be installed by name.

+ +

  • <folder>: +A folder containing a package.json file

  • <tarball>: +A url or file path to a gzipped tar archive containing a single folder +with a package.json file inside.

+ +

Fails if the package name and version combination already exists in +the registry. Overwrites when the "--force" flag is set.

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-rebuild.html b/deps/npm/html/doc/cli/npm-rebuild.html new file mode 100644 index 000000000..21fe9edc6 --- /dev/null +++ b/deps/npm/html/doc/cli/npm-rebuild.html @@ -0,0 +1,59 @@ + + + npm-rebuild + + + + +
+

npm-rebuild

Rebuild a package

+ +

SYNOPSIS

+ +
npm rebuild [<name> [<name> ...]]
+ +
  • <name>: +The package to rebuild
+ +

DESCRIPTION

+ +

This command runs the npm build command on the matched folders. This is useful +when you install a new version of node, and must recompile all your C++ addons with +the new binary.

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-restart.html b/deps/npm/html/doc/cli/npm-restart.html new file mode 100644 index 000000000..533b70b90 --- /dev/null +++ b/deps/npm/html/doc/cli/npm-restart.html @@ -0,0 +1,58 @@ + + + npm-restart + + + + +
+

npm-restart

Start a package

+ +

SYNOPSIS

+ +
npm restart <name>
+ +

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.

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-rm.html b/deps/npm/html/doc/cli/npm-rm.html new file mode 100644 index 000000000..273be4d97 --- /dev/null +++ b/deps/npm/html/doc/cli/npm-rm.html @@ -0,0 +1,56 @@ + + + npm-rm + + + + +
+

npm-rm

Remove a package

+ +

SYNOPSIS

+ +
npm rm <name>
+npm uninstall <name>
+ +

DESCRIPTION

+ +

This uninstalls a package, completely removing everything npm installed +on its behalf.

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-root.html b/deps/npm/html/doc/cli/npm-root.html new file mode 100644 index 000000000..45ad5884c --- /dev/null +++ b/deps/npm/html/doc/cli/npm-root.html @@ -0,0 +1,54 @@ + + + npm-root + + + + +
+

npm-root

Display npm root

+ +

SYNOPSIS

+ +
npm root
+ +

DESCRIPTION

+ +

Print the effective node_modules folder to standard out.

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-run-script.html b/deps/npm/html/doc/cli/npm-run-script.html new file mode 100644 index 000000000..d2c7ad6a6 --- /dev/null +++ b/deps/npm/html/doc/cli/npm-run-script.html @@ -0,0 +1,57 @@ + + + npm-run-script + + + + +
+

npm-run-script

Run arbitrary package scripts

+ +

SYNOPSIS

+ +
npm run-script <script> <name>
+ +

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.

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-search.html b/deps/npm/html/doc/cli/npm-search.html new file mode 100644 index 000000000..aecbe7d38 --- /dev/null +++ b/deps/npm/html/doc/cli/npm-search.html @@ -0,0 +1,58 @@ + + + npm-search + + + + +
+

npm-search

Search for packages

+ +

SYNOPSIS

+ +
npm search [search terms ...]
+ +

DESCRIPTION

+ +

Search the registry for packages matching the search terms.

+ +

If a term starts with /, then it's interpreted as a regular expression. +A trailing / will be ignored in this case. (Note that many regular +expression characters must be escaped or quoted in most shells.)

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-shrinkwrap.html b/deps/npm/html/doc/cli/npm-shrinkwrap.html new file mode 100644 index 000000000..f126a34f6 --- /dev/null +++ b/deps/npm/html/doc/cli/npm-shrinkwrap.html @@ -0,0 +1,217 @@ + + + npm-shrinkwrap + + + + +
+

npm-shrinkwrap

Lock down dependency versions

+ +

SYNOPSIS

+ +
npm shrinkwrap
+ +

DESCRIPTION

+ +

This command locks down the versions of a package's dependencies so +that you can control exactly which versions of each dependency will be +used when your package is installed. The "package.json" file is still +required if you want to use "npm install".

+ +

By default, "npm install" recursively installs the target's +dependencies (as specified in package.json), choosing the latest +available version that satisfies the dependency's semver pattern. In +some situations, particularly when shipping software where each change +is tightly managed, it's desirable to fully specify each version of +each dependency recursively so that subsequent builds and deploys do +not inadvertently pick up newer versions of a dependency that satisfy +the semver pattern. Specifying specific semver patterns in each +dependency's package.json would facilitate this, but that's not always +possible or desirable, as when another author owns the npm package. +It's also possible to check dependencies directly into source control, +but that may be undesirable for other reasons.

+ +

As an example, consider package A:

+ +
{
+  "name": "A",
+  "version": "0.1.0",
+  "dependencies": {
+    "B": "<0.1.0"
+  }
+}
+ +

package B:

+ +
{
+  "name": "B",
+  "version": "0.0.1",
+  "dependencies": {
+    "C": "<0.1.0"
+  }
+}
+ +

and package C:

+ +
{
+  "name": "C,
+  "version": "0.0.1"
+}
+ +

If these are the only versions of A, B, and C available in the +registry, then a normal "npm install A" will install:

+ +
A@0.1.0
+`-- B@0.0.1
+    `-- C@0.0.1
+ +

However, if B@0.0.2 is published, then a fresh "npm install A" will +install:

+ +
A@0.1.0
+`-- B@0.0.2
+    `-- C@0.0.1
+ +

assuming the new version did not modify B's dependencies. Of course, +the new version of B could include a new version of C and any number +of new dependencies. If such changes are undesirable, the author of A +could specify a dependency on B@0.0.1. However, if A's author and B's +author are not the same person, there's no way for A's author to say +that he or she does not want to pull in newly published versions of C +when B hasn't changed at all.

+ +

In this case, A's author can run

+ +
npm shrinkwrap
+ +

This generates npm-shrinkwrap.json, which will look something like this:

+ +
{
+  "name": "A",
+  "version": "0.1.0",
+  "dependencies": {
+    "B": {
+      "version": "0.0.1",
+      "dependencies": {
+        "C": {
+          "version": "0.1.0"
+        }
+      }
+    }
+  }
+}
+ +

The shrinkwrap command has locked down the dependencies based on +what's currently installed in node_modules. When "npm install" +installs a package with a npm-shrinkwrap.json file in the package +root, the shrinkwrap file (rather than package.json files) completely +drives the installation of that package and all of its dependencies +(recursively). So now the author publishes A@0.1.0, and subsequent +installs of this package will use B@0.0.1 and C@0.1.0, regardless the +dependencies and versions listed in A's, B's, and C's package.json +files.

+ +

Using shrinkwrapped packages

+ +

Using a shrinkwrapped package is no different than using any other +package: you can "npm install" it by hand, or add a dependency to your +package.json file and "npm install" it.

+ +

Building shrinkwrapped packages

+ +

To shrinkwrap an existing package:

+ +
  1. Run "npm install" in the package root to install the current +versions of all dependencies.
  2. Validate that the package works as expected with these versions.
  3. Run "npm shrinkwrap", add npm-shrinkwrap.json to git, and publish +your package.
+ +

To add or update a dependency in a shrinkwrapped package:

+ +
  1. Run "npm install" in the package root to install the current +versions of all dependencies.
  2. Add or update dependencies. "npm install" each new or updated +package individually and then update package.json. Note that they +must be explicitly named in order to be installed: running npm +install with no arguments will merely reproduce the existing +shrinkwrap.
  3. Validate that the package works as expected with the new +dependencies.
  4. Run "npm shrinkwrap", commit the new npm-shrinkwrap.json, and +publish your package.
+ +

You can use npm-outdated(1) to view dependencies with newer versions +available.

+ +

Other Notes

+ +

A shrinkwrap file must be consistent with the package's package.json +file. "npm shrinkwrap" will fail if required dependencies are not +already installed, since that would result in a shrinkwrap that +wouldn't actually work. Similarly, the command will fail if there are +extraneous packages (not referenced by package.json), since that would +indicate that package.json is not correct.

+ +

Since "npm shrinkwrap" is intended to lock down your dependencies for +production use, devDependencies will not be included unless you +explicitly set the --dev flag when you run npm shrinkwrap. If +installed devDependencies are excluded, then npm will print a +warning. If you want them to be installed with your module by +default, please consider adding them to dependencies instead.

+ +

If shrinkwrapped package A depends on shrinkwrapped package B, B's +shrinkwrap will not be used as part of the installation of A. However, +because A's shrinkwrap is constructed from a valid installation of B +and recursively specifies all dependencies, the contents of B's +shrinkwrap will implicitly be included in A's shrinkwrap.

+ +

Caveats

+ +

Shrinkwrap files only lock down package versions, not actual package +contents. While discouraged, a package author can republish an +existing version of a package, causing shrinkwrapped packages using +that version to pick up different code than they were before. If you +want to avoid any risk that a byzantine author replaces a package +you're using with code that breaks your application, you could modify +the shrinkwrap file to use git URL references rather than version +numbers so that npm always fetches all packages from git.

+ +

If you wish to lock down the specific bytes included in a package, for +example to have 100% confidence in being able to reproduce a +deployment or build, then you ought to check your dependencies into +source control, or pursue some other mechanism that can verify +contents rather than versions.

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-star.html b/deps/npm/html/doc/cli/npm-star.html new file mode 100644 index 000000000..c35f26df4 --- /dev/null +++ b/deps/npm/html/doc/cli/npm-star.html @@ -0,0 +1,60 @@ + + + npm-star + + + + +
+

npm-star

Mark your favorite packages

+ +

SYNOPSIS

+ +
npm star <pkgname> [<pkg>, ...]
+npm unstar <pkgname> [<pkg>, ...]
+ +

DESCRIPTION

+ +

"Starring" a package means that you have some interest in it. It's +a vaguely positive way to show that you care.

+ +

"Unstarring" is the same thing, but in reverse.

+ +

It's a boolean thing. Starring repeatedly has no additional effect.

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-stars.html b/deps/npm/html/doc/cli/npm-stars.html new file mode 100644 index 000000000..8775ca63a --- /dev/null +++ b/deps/npm/html/doc/cli/npm-stars.html @@ -0,0 +1,59 @@ + + + npm-stars + + + + +
+

npm-stars

View packages marked as favorites

+ +

SYNOPSIS

+ +
npm stars
+npm stars [username]
+ +

DESCRIPTION

+ +

If you have starred a lot of neat things and want to find them again +quickly this command lets you do just that.

+ +

You may also want to see your friend's favorite packages, in this case +you will most certainly enjoy this command.

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-start.html b/deps/npm/html/doc/cli/npm-start.html new file mode 100644 index 000000000..4eb414b45 --- /dev/null +++ b/deps/npm/html/doc/cli/npm-start.html @@ -0,0 +1,54 @@ + + + npm-start + + + + +
+

npm-start

Start a package

+ +

SYNOPSIS

+ +
npm start <name>
+ +

DESCRIPTION

+ +

This runs a package's "start" script, if one was provided.

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-stop.html b/deps/npm/html/doc/cli/npm-stop.html new file mode 100644 index 000000000..bfc6e690d --- /dev/null +++ b/deps/npm/html/doc/cli/npm-stop.html @@ -0,0 +1,54 @@ + + + npm-stop + + + + +
+

npm-stop

Stop a package

+ +

SYNOPSIS

+ +
npm stop <name>
+ +

DESCRIPTION

+ +

This runs a package's "stop" script, if one was provided.

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-submodule.html b/deps/npm/html/doc/cli/npm-submodule.html new file mode 100644 index 000000000..2960ae5ed --- /dev/null +++ b/deps/npm/html/doc/cli/npm-submodule.html @@ -0,0 +1,67 @@ + + + npm-submodule + + + + +
+

npm-submodule

Add a package as a git submodule

+ +

SYNOPSIS

+ +
npm submodule <pkg>
+ +

DESCRIPTION

+ +

If the specified package has a git repository url in its package.json +description, then this command will 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

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-tag.html b/deps/npm/html/doc/cli/npm-tag.html new file mode 100644 index 000000000..682866f89 --- /dev/null +++ b/deps/npm/html/doc/cli/npm-tag.html @@ -0,0 +1,55 @@ + + + npm-tag + + + + +
+

npm-tag

Tag a published version

+ +

SYNOPSIS

+ +
npm tag <name>@<version> [<tag>]
+ +

DESCRIPTION

+ +

Tags the specified version of the package with the specified tag, or the +--tag config if not specified.

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-test.html b/deps/npm/html/doc/cli/npm-test.html new file mode 100644 index 000000000..7b2bb0876 --- /dev/null +++ b/deps/npm/html/doc/cli/npm-test.html @@ -0,0 +1,57 @@ + + + npm-test + + + + +
+

npm-test

Test a package

+ +

SYNOPSIS

+ +
  npm test <name>
+ +

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.

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-uninstall.html b/deps/npm/html/doc/cli/npm-uninstall.html new file mode 100644 index 000000000..3bd298583 --- /dev/null +++ b/deps/npm/html/doc/cli/npm-uninstall.html @@ -0,0 +1,56 @@ + + + npm-uninstall + + + + +
+

npm-rm

Remove a package

+ +

SYNOPSIS

+ +
npm rm <name>
+npm uninstall <name>
+ +

DESCRIPTION

+ +

This uninstalls a package, completely removing everything npm installed +on its behalf.

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-unpublish.html b/deps/npm/html/doc/cli/npm-unpublish.html new file mode 100644 index 000000000..17be6dc90 --- /dev/null +++ b/deps/npm/html/doc/cli/npm-unpublish.html @@ -0,0 +1,68 @@ + + + npm-unpublish + + + + +
+

npm-unpublish

Remove a package from the registry

+ +

SYNOPSIS

+ +
npm unpublish <name>[@<version>]
+ +

WARNING

+ +

It is generally considered bad behavior to remove versions of a library +that others are depending on!

+ +

Consider using the deprecate command +instead, if your intent is to encourage users to upgrade.

+ +

There is plenty of room on the registry.

+ +

DESCRIPTION

+ +

This removes a package version from the registry, deleting its +entry and removing the tarball.

+ +

If no version is specified, or if all versions are removed then +the root package entry is removed from the registry entirely.

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-update.html b/deps/npm/html/doc/cli/npm-update.html new file mode 100644 index 000000000..133fd61f8 --- /dev/null +++ b/deps/npm/html/doc/cli/npm-update.html @@ -0,0 +1,60 @@ + + + npm-update + + + + +
+

npm-update

Update a package

+ +

SYNOPSIS

+ +
npm update [-g] [<name> [<name> ...]]
+ +

DESCRIPTION

+ +

This command will update all the packages listed to the latest version +(specified by the tag config).

+ +

It will also install missing packages.

+ +

If the -g flag is specified, this command will update globally installed packages. +If no package name is specified, all packages in the specified location (global or local) will be updated.

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-version.html b/deps/npm/html/doc/cli/npm-version.html new file mode 100644 index 000000000..1064250ce --- /dev/null +++ b/deps/npm/html/doc/cli/npm-version.html @@ -0,0 +1,83 @@ + + + npm-version + + + + +
+

npm-version

Bump a package version

+ +

SYNOPSIS

+ +
npm version [<newversion> | major | minor | patch | build]
+ +

DESCRIPTION

+ +

Run this in a package directory to bump the version and write the new +data back to the package.json file.

+ +

The newversion argument should be a valid semver string, or a valid +second argument to semver.inc (one of "build", "patch", "minor", or +"major"). In the second case, the existing version will be incremented +by 1 in the specified field.

+ +

If run in a git repo, it will also create a version commit and tag, and +fail if the repo is not clean.

+ +

If supplied with --message (shorthand: -m) config option, npm will +use it as a commit message when creating a version commit. If the +message config contains %s then that will be replaced with the +resulting version number. For example:

+ +
npm version patch -m "Upgrade to %s for reasons"
+ +

If the sign-git-tag config is set, then the tag will be signed using +the -s flag to git. Note that you must have a default GPG key set up +in your git config for this to work properly. For example:

+ +
$ npm config set sign-git-tag true
+$ npm version patch
+
+You need a passphrase to unlock the secret key for
+user: "isaacs (http://blog.izs.me/) <i@izs.me>"
+2048-bit RSA key, ID 6C481CF6, created 2010-08-31
+
+Enter passphrase:
+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-view.html b/deps/npm/html/doc/cli/npm-view.html new file mode 100644 index 000000000..43c3e7fd3 --- /dev/null +++ b/deps/npm/html/doc/cli/npm-view.html @@ -0,0 +1,124 @@ + + + npm-view + + + + +
+

npm-view

View registry info

+ +

SYNOPSIS

+ +
npm view <name>[@<version>] [<field>[.<subfield>]...]
+ +

DESCRIPTION

+ +

This command shows data about a package and prints it to the stream +referenced by the outfd config, which defaults to stdout.

+ +

To show the package registry entry for the connect package, you can do +this:

+ +
npm view connect
+ +

The default version is "latest" if unspecified.

+ +

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 view ronn@0.3.5 dependencies
+ +

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 view npm repository.url
+ +

This makes it easy to view information about a dependency with a bit of +shell scripting. For example, to view all the data about the version of +opts that ronn depends on, you can do this:

+ +
npm view opts@$(npm view ronn dependencies.opts)
+ +

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 view express contributors.email
+ +

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 view express contributors[0].email
+ +

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 view express contributors.name contributors.email
+ +

"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 package.json(5) for more on this.)

+ +
npm view npm contributors
+ +

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 view yui3@'>0.5.4' dependencies.jsdom
+ +

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 field is an object, it will be output as a JavaScript object literal.

+ +

If the --json flag is given, the outputted fields will be JSON.

+ +

If the version range matches multiple versions, than each printed value +will be prefixed with the version it applies to.

+ +

If multiple fields are requested, than each of them are prefixed with +the field name.

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm-whoami.html b/deps/npm/html/doc/cli/npm-whoami.html new file mode 100644 index 000000000..2c4608cf6 --- /dev/null +++ b/deps/npm/html/doc/cli/npm-whoami.html @@ -0,0 +1,54 @@ + + + npm-whoami + + + + +
+

npm-whoami

Display npm username

+ +

SYNOPSIS

+ +
npm whoami
+ +

DESCRIPTION

+ +

Print the username config to standard output.

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/cli/npm.html b/deps/npm/html/doc/cli/npm.html new file mode 100644 index 000000000..7f7be0b90 --- /dev/null +++ b/deps/npm/html/doc/cli/npm.html @@ -0,0 +1,169 @@ + + + npm + + + + +
+

npm

node package manager

+ +

SYNOPSIS

+ +
npm <command> [args]
+ +

VERSION

+ +

1.3.3

+ +

DESCRIPTION

+ +

npm is the package manager for the Node JavaScript platform. It puts +modules in place so that node can find them, and manages dependency +conflicts intelligently.

+ +

It is extremely configurable to support a wide variety of use cases. +Most commonly, it is used to publish, discover, install, and develop node +programs.

+ +

Run npm help to get a list of available commands.

+ +

INTRODUCTION

+ +

You probably got npm because you want to install stuff.

+ +

Use npm install blerg to install the latest version of "blerg". Check out +npm-install(1) for more info. It can do a lot of stuff.

+ +

Use the npm search command to show everything that's available. +Use npm ls to show everything you've installed.

+ +

DIRECTORIES

+ +

See npm-folders(7) to learn about where npm puts stuff.

+ +

In particular, npm has two modes of operation:

+ +
  • global mode:
    npm installs packages into the install prefix at +prefix/lib/node_modules and bins are installed in prefix/bin.
  • local mode:
    npm installs packages into the current project directory, which +defaults to the current working directory. Packages are installed to +./node_modules, and bins are installed to ./node_modules/.bin.
+ +

Local mode is the default. Use --global or -g on any command to +operate in global mode instead.

+ +

DEVELOPER USAGE

+ +

If you're using npm to develop and publish your code, check out the +following help topics:

+ +
  • json: +Make a package.json file. See package.json(5).
  • link: +For linking your current working code into Node's path, so that you +don't have to reinstall every time you make a change. Use +npm link to do this.
  • install: +It's a good idea to install things if you don't need the symbolic link. +Especially, installing other peoples code from the registry is done via +npm install
  • adduser: +Create an account or log in. Credentials are stored in the +user config file.
  • publish: +Use the npm publish command to upload your code to the registry.
+ +

CONFIGURATION

+ +

npm is extremely configurable. It reads its configuration options from +5 places.

+ +
  • Command line switches:
    Set a config with --key val. All keys take a value, even if they +are booleans (the config parser doesn't know what the options are at +the time of parsing.) If no value is provided, then the option is set +to boolean true.
  • Environment Variables:
    Set any config by prefixing the name in an environment variable with +npm_config_. For example, export npm_config_key=val.
  • User Configs:
    The file at $HOME/.npmrc is an ini-formatted list of configs. If +present, it is parsed. If the userconfig option is set in the cli +or env, then that will be used instead.
  • Global Configs:
    The file found at ../etc/npmrc (from the node executable, by default +this resolves to /usr/local/etc/npmrc) will be parsed if it is found. +If the globalconfig option is set in the cli, env, or user config, +then that file is parsed instead.
  • Defaults:
    npm's default configuration options are defined in +lib/utils/config-defs.js. These must not be changed.
+ +

See npm-config(7) for much much more information.

+ +

CONTRIBUTIONS

+ +

Patches welcome!

+ +
  • code: +Read through npm-coding-style(7) if you plan to submit code. +You don't have to agree with it, but you do have to follow it.
  • docs: +If you find an error in the documentation, edit the appropriate markdown +file in the "doc" folder. (Don't worry about generating the man page.)
+ +

Contributors are listed in npm's package.json file. You can view them +easily by doing npm view npm contributors.

+ +

If you would like to contribute, but don't know what to work on, check +the issues list or ask on the mailing list.

+ + + +

BUGS

+ +

When you find issues, please report them:

+ + + +

Be sure to include all of the output from the npm command that didn't work +as expected. The npm-debug.log file is also helpful to provide.

+ +

You can also look for isaacs in #node.js on irc://irc.freenode.net. He +will no doubt tell you to put the output in a gist or email.

+ +

HISTORY

+ +

See npm-changelog(1)

+ +

AUTHOR

+ +

Isaac Z. Schlueter :: +isaacs :: +@izs :: +i@izs.me

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/coding-style.html b/deps/npm/html/doc/coding-style.html deleted file mode 100644 index 9f959aa93..000000000 --- a/deps/npm/html/doc/coding-style.html +++ /dev/null @@ -1,217 +0,0 @@ - - - coding-style - - - - -
-

coding-style

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.

- -

Note: this concerns npm's code not the specific packages at npmjs.org

- -

Line Length

- -

Keep lines shorter than 80 characters. It's better for lines to be -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.

- -

Logging

- -

Logging is done using the npmlog -utility.

- -

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. See 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

- - -
- - - diff --git a/deps/npm/html/doc/completion.html b/deps/npm/html/doc/completion.html deleted file mode 100644 index 4d67aede4..000000000 --- a/deps/npm/html/doc/completion.html +++ /dev/null @@ -1,68 +0,0 @@ - - - completion - - - - -
-

completion

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

- - -
- - - diff --git a/deps/npm/html/doc/config.html b/deps/npm/html/doc/config.html deleted file mode 100644 index 5f10a6111..000000000 --- a/deps/npm/html/doc/config.html +++ /dev/null @@ -1,813 +0,0 @@ - - - config - - - - -
-

config

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. -Environment variables can be replaced using ${VARIABLE_NAME}. For example:

- -
prefix = ${HOME}/.npm-packages
- -

Global config file

- -

$PREFIX/etc/npmrc (or the globalconfig param, if set above): -This file is an ini-file formatted list of key = value parameters. -Environment variables can be replaced as above.

- -

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
  • -q, --quiet: --loglevel warn
  • -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
  • -desc: --description
  • -S: --save
  • -D: --save-dev
  • -O: --save-optional
  • -B: --save-bundle
  • -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 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.

- - - -
  • Default: true
  • Type: Boolean
- -

Tells npm to create symlinks (or .cmd shims on Windows) for package -executables.

- -

Set to false to have it not do this. This can be used to work around -the fact that some file systems don't support symlinks, even on -ostensibly Unix systems.

- -

browser

- -
  • Default: OS X: "open", Windows: "start", Others: "xdg-open"
  • 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: %APPDATA%\npm-cache, Posix: ~/.npm
  • Type: path
- -

The location of npm's cache directory. See cache(1)

- -

cache-lock-stale

- -
  • Default: 60000 (1 minute)
  • Type: Number
- -

The number of ms before cache folder lockfiles are considered stale.

- -

cache-lock-retries

- -
  • Default: 10
  • Type: Number
- -

Number of times to retry to acquire a lock on cache folder lockfiles.

- -

cache-lock-wait

- -
  • Default: 10000 (10 seconds)
  • Type: Number
- -

Number of ms to wait for cache lock files to expire.

- -

cache-max

- -
  • Default: Infinity
  • Type: Number
- -

The maximum time (in seconds) to keep items in the registry cache before -re-checking against the registry.

- -

Note that no purging is done unless the npm cache clean command is -explicitly used, and that only GET requests use the cache.

- -

cache-min

- -
  • Default: 10
  • Type: Number
- -

The minimum time (in seconds) to keep items in the registry cache before -re-checking against the registry.

- -

Note that no purging is done unless the npm cache clean command is -explicitly used, and that only GET requests use the cache.

- -

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.

- -

coverage

- -
  • Default: false
  • Type: Boolean
- -

A flag to tell test-harness to run with their coverage options enabled, -if they respond to the npm_config_coverage environment variable.

- -

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.

- -

engine-strict

- -
  • Default: false
  • Type: Boolean
- -

If set to true, then npm will stubbornly refuse to install (or even -consider installing) any package that claims to not be compatible with -the current Node.js version.

- -

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.
- -

fetch-retries

- -
  • Default: 2
  • Type: Number
- -

The "retries" config for the retry module to use when fetching -packages from the registry.

- -

fetch-retry-factor

- -
  • Default: 10
  • Type: Number
- -

The "factor" config for the retry module to use when fetching -packages.

- -

fetch-retry-mintimeout

- -
  • Default: 10000 (10 seconds)
  • Type: Number
- -

The "minTimeout" config for the retry module to use when fetching -packages.

- -

fetch-retry-maxtimeout

- -
  • Default: 60000 (1 minute)
  • Type: Number
- -

The "maxTimeout" config for the retry module to use when fetching -packages.

- -

git

- -
  • Default: "git"
  • Type: String
- -

The command to use for git commands. If git is installed on the -computer, but is not in the PATH, then set this to the full path to -the git binary.

- -

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 -folders(1) for more on the differences in behavior.

- -
  • packages are installed into the {prefix}/lib/node_modules folder, instead of the -current working directory.
  • bin files are linked to {prefix}/bin
  • man pages are linked to {prefix}/share/man
- -

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.

- -

user-agent

- -
  • Default: node/{process.version} {process.platform} {process.arch}
  • Type: String
- -

Sets a User-Agent to the request header

- -

ignore

- -
  • Default: ""
  • Type: string
- -

A white-space separated list of glob patterns of files to always exclude -from packages when building tarballs.

- -

init-module

- -
  • Default: ~/.npm-init.js
  • Type: path
- -

A module that will be loaded by the npm init command. See the -documentation for the -init-package-json module -for more information, or init(1).

- -

init.version

- -
  • Default: "0.0.0"
  • Type: semver
- -

The value npm init should use by default for the package version.

- -

init.author.name

- -
  • Default: ""
  • 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.

- -

json

- -
  • Default: false
  • Type: Boolean
- -

Whether or not to output JSON data, rather than the normal output.

- -

This feature is currently experimental, and the output data structures -for many commands is either not implemented in JSON yet, or subject to -change. Only the output from npm ls --json is currently valid.

- - - -
  • 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.
- -

loglevel

- -
  • Default: "http"
  • Type: String
  • Values: "silent", "win", "error", "warn", "http", "info", "verbose", "silly"
- -

What level of logs to report. On failure, all logs are written to -npm-debug.log in the current working directory.

- -

Any logs of a higher level than the setting are shown. -The default is "http", which shows http, warn, and error output.

- -

logstream

- -
  • Default: process.stderr
  • Type: Stream
- -

This is the stream that is passed to the -npmlog module at run time.

- -

It cannot be set from the command line, but if you are using npm -programmatically, you may wish to send logs to somewhere other than -stderr.

- -

If the color config is set to true, then this stream will receive -colored output if it is a TTY.

- -

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.

- -

optional

- -
  • Default: true
  • Type: Boolean
- -

Attempt to install packages in the optionalDependencies hash. Note -that if these packages fail to install, the overall installation -process is not aborted.

- -

parseable

- -
  • Default: false
  • Type: Boolean
- -

Output parseable results from commands that write to -standard output.

- -

prefix

- - - -

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.
- -

proprietary-attribs

- -
  • Default: true
  • Type: Boolean
- -

Whether or not to include proprietary extended attributes in the -tarballs created by npm.

- -

Unless you are expecting to unpack package tarballs with something other -than npm -- particularly a very outdated tar implementation -- leave -this as true.

- -

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.

- -

When used with the npm rm command, it removes it from the dependencies -hash.

- -

Only works if there is already a package.json file present.

- -

save-bundle

- -
  • Default: false
  • Type: Boolean
- -

If a package would be saved at install time by the use of --save, ---save-dev, or --save-optional, then also put it in the -bundleDependencies list.

- -

When used with the npm rm command, it removes it from the -bundledDependencies list.

- -

save-dev

- -
  • Default: false
  • Type: Boolean
- -

Save installed packages to a package.json file as devDependencies.

- -

When used with the npm rm command, it removes it from the devDependencies -hash.

- -

Only works if there is already a package.json file present.

- -

save-optional

- -
  • Default: false
  • Type: Boolean
- -

Save installed packages to a package.json file as optionalDependencies.

- -

When used with the npm rm command, it removes it from the devDependencies -hash.

- -

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.

- -

searchsort

- -
  • Default: "name"
  • Type: String
  • Values: "name", "-name", "date", "-date", "description", -"-description", "keywords", "-keywords"
- -

Indication of which field to sort search results by. Prefix with a - -character to indicate reverse sort.

- -

shell

- -
  • Default: SHELL environment variable, or "bash" on Posix, or "cmd" on -Windows
  • Type: path
- -

The shell to run for the npm explore command.

- -

shrinkwrap

- -
  • Default: true
  • Type: Boolean
- -

If set to false, then ignore npm-shrinkwrap.json files when -installing.

- -

sign-git-tag

- -
  • Default: false
  • Type: Boolean
- -

If set to true, then the npm version command will tag the version -using -s to add a signature.

- -

Note that git requires you to have set up GPG keys in your git configs -for this to work properly.

- -

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 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.

- -

versions

- -
  • Default: false
  • Type: boolean
- -

If true, output the npm version as well as node's process.versions -hash, 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

- - -
- - - diff --git a/deps/npm/html/doc/dedupe.html b/deps/npm/html/doc/dedupe.html deleted file mode 100644 index b4701eeba..000000000 --- a/deps/npm/html/doc/dedupe.html +++ /dev/null @@ -1,92 +0,0 @@ - - - dedupe - - - - -
-

dedupe

Reduce duplication

- -

SYNOPSIS

- -
npm dedupe [package names...]
- -

DESCRIPTION

- -

Searches the local package tree and attempts to simplify the overall -structure by moving dependencies further up the tree, where they can -be more effectively shared by multiple dependent packages.

- -

For example, consider this dependency graph:

- -
a
-+-- b <-- depends on c@1.0.x
-|   `-- c@1.0.3
-`-- d <-- depends on c@~1.0.9
-    `-- c@1.0.10
- -

In this case, dedupe(1) will transform the tree to:

- -
a
-+-- b
-+-- d
-`-- c@1.0.10
- -

Because of the hierarchical nature of node's module lookup, b and d -will both get their dependency met by the single c package at the root -level of the tree.

- -

If a suitable version exists at the target location in the tree -already, then it will be left untouched, but the other duplicates will -be deleted.

- -

If no suitable version can be found, then a warning is printed, and -nothing is done.

- -

If any arguments are supplied, then they are filters, and only the -named packages will be touched.

- -

Note that this operation transforms the dependency tree, and may -result in packages getting updated versions, perhaps from the npm -registry.

- -

This feature is experimental, and may change in future versions.

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/deprecate.html b/deps/npm/html/doc/deprecate.html deleted file mode 100644 index c08556b21..000000000 --- a/deps/npm/html/doc/deprecate.html +++ /dev/null @@ -1,66 +0,0 @@ - - - deprecate - - - - -
-

deprecate

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.

- -

To un-deprecate a package, specify an empty string ("") for the message argument.

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/developers.html b/deps/npm/html/doc/developers.html deleted file mode 100644 index 237b47066..000000000 --- a/deps/npm/html/doc/developers.html +++ /dev/null @@ -1,209 +0,0 @@ - - - developers - - - - -
-

developers

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)
  • 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.

- -

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 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 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 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.

- -

By default, the following paths and files are ignored, so there's no -need to add them to .npmignore explicitly:

- -
  • .*.swp
  • ._*
  • .DS_Store
  • .git
  • .hg
  • .lock-wscript
  • .svn
  • .wafpickle-*
  • CVS
  • npm-debug.log
- -

Additionally, everything in node_modules is ignored, except for -bundled dependencies. npm automatically handles this for you, so don't -bother adding node_modules to .npmignore.

- -

The following paths and files are never ignored, so adding them to -.npmignore is pointless:

- - - - - -

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 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 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 -.npmignore file to list out the globs to 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

- - -
- - - diff --git a/deps/npm/html/doc/disputes.html b/deps/npm/html/doc/disputes.html deleted file mode 100644 index 4248d1113..000000000 --- a/deps/npm/html/doc/disputes.html +++ /dev/null @@ -1,126 +0,0 @@ - - - disputes - - - - -
-

disputes

Handling Module Name Disputes

- -

SYNOPSIS

- -
  1. Get the author email with npm owner ls <pkgname>
  2. Email the author, CC i@izs.me.
  3. After a few weeks, if there's no resolution, we'll sort it out.
- -

Don't squat on package names. Publish code or move out of the way.

- -

DESCRIPTION

- -

There sometimes arise cases where a user publishes a module, and then -later, some other user wants to use that name. Here are some common -ways that happens (each of these is based on actual events.)

- -
  1. Joe writes a JavaScript module foo, which is not node-specific. -Joe doesn't use node at all. Bob wants to use foo in node, so he -wraps it in an npm module. Some time later, Joe starts using node, -and wants to take over management of his program.
  2. Bob writes an npm module foo, and publishes it. Perhaps much -later, Joe finds a bug in foo, and fixes it. He sends a pull -request to Bob, but Bob doesn't have the time to deal with it, -because he has a new job and a new baby and is focused on his new -erlang project, and kind of not involved with node any more. Joe -would like to publish a new foo, but can't, because the name is -taken.
  3. Bob writes a 10-line flow-control library, and calls it foo, and -publishes it to the npm registry. Being a simple little thing, it -never really has to be updated. Joe works for Foo Inc, the makers -of the critically acclaimed and widely-marketed foo JavaScript -toolkit framework. They publish it to npm as foojs, but people are -routinely confused when npm install foo is some different thing.
  4. Bob writes a parser for the widely-known foo file format, because -he needs it for work. Then, he gets a new job, and never updates the -prototype. Later on, Joe writes a much more complete foo parser, -but can't publish, because Bob's foo is in the way.
- -

The validity of Joe's claim in each situation can be debated. However, -Joe's appropriate course of action in each case is the same.

- -
  1. npm owner ls foo. This will tell Joe the email address of the -owner (Bob).
  2. Joe emails Bob, explaining the situation as respectfully as possible, -and what he would like to do with the module name. He adds -isaacs i@izs.me to the CC list of the email. Mention in the email -that Bob can run npm owner add joe foo to add Joe as an owner of -the foo package.
  3. After a reasonable amount of time, if Bob has not responded, or if -Bob and Joe can't come to any sort of resolution, email isaacs -i@izs.me and we'll sort it out. ("Reasonable" is usually about 4 -weeks, but extra time is allowed around common holidays.)
- -

REASONING

- -

In almost every case so far, the parties involved have been able to reach -an amicable resolution without any major intervention. Most people -really do want to be reasonable, and are probably not even aware that -they're in your way.

- -

Module ecosystems are most vibrant and powerful when they are as -self-directed as possible. If an admin one day deletes something you -had worked on, then that is going to make most people quite upset, -regardless of the justification. When humans solve their problems by -talking to other humans with respect, everyone has the chance to end up -feeling good about the interaction.

- -

EXCEPTIONS

- -

Some things are not allowed, and will be removed without discussion if -they are brought to the attention of the npm registry admins, including -but not limited to:

- -
  1. Malware (that is, a package designed to exploit or harm the machine on -which it is installed).
  2. Violations of copyright or licenses (for example, cloning an -MIT-licensed program, and then removing or changing the copyright and -license statement).
  3. Illegal content.
  4. "Squatting" on a package name that you plan to use, but aren't -actually using. Sorry, I don't care how great the name is, or how -perfect a fit it is for the thing that someday might happen. If -someone wants to use it today, and you're just taking up space with -an empty tarball, you're going to be evicted.
  5. Putting empty packages in the registry. Packages must have SOME -functionality. It can be silly, but it can't be nothing. (See -also: squatting.)
  6. Doing weird things with the registry, like using it as your own -personal application database or otherwise putting non-packagey -things into it.
- -

If you see bad behavior like this, please report it right away.

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/docs.html b/deps/npm/html/doc/docs.html deleted file mode 100644 index cea370e0d..000000000 --- a/deps/npm/html/doc/docs.html +++ /dev/null @@ -1,72 +0,0 @@ - - - docs - - - - -
-

docs

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", Windows: "start", Others: "xdg-open"
  • 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

- - -
- - - diff --git a/deps/npm/html/doc/edit.html b/deps/npm/html/doc/edit.html deleted file mode 100644 index b4ee35da0..000000000 --- a/deps/npm/html/doc/edit.html +++ /dev/null @@ -1,72 +0,0 @@ - - - edit - - - - -
-

edit

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

- - -
- - - diff --git a/deps/npm/html/doc/explore.html b/deps/npm/html/doc/explore.html deleted file mode 100644 index f6ba2539a..000000000 --- a/deps/npm/html/doc/explore.html +++ /dev/null @@ -1,75 +0,0 @@ - - - explore - - - - -
-

explore

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

- - -
- - - diff --git a/deps/npm/html/doc/faq.html b/deps/npm/html/doc/faq.html deleted file mode 100644 index 67ba6748c..000000000 --- a/deps/npm/html/doc/faq.html +++ /dev/null @@ -1,375 +0,0 @@ - - - faq - - - - -
-

faq

Frequently Asked Questions

- -

Where can I find these docs in HTML?

- -

https://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 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 on my computer in a central location?

- -

Install it globally by tacking -g or --global to the command. (This -is especially important for command line utilities that need to add -their bins to the global system PATH.)

- -

I installed something globally, but I can't require() it

- -

Install it locally.

- -

The global install location is a place for command-line utilities -to put their bins in the system PATH. It's not for use with require().

- -

If you require() a module in your code, then that means it's a -dependency, and a part of your program. You need to install it locally -in your program.

- -

Why can't npm just put everything in one place, like other package managers?

- -

Not every change is an improvement, but every improvement is a change. -This would be like asking git to do network IO for every commit. It's -not going to happen, because it's a terrible idea that causes more -problems than it solves.

- -

It is much harder to avoid dependency conflicts without nesting -dependencies. This is fundamental to the way that npm works, and has -proven to be an extremely successful approach. See folders(1) for -more details.

- -

If you want a package to be installed in one place, and have all your -programs reference the same copy of it, then use the npm link command. -That's what it's for. Install it globally, then link it into each -program that uses it.

- -

Whatever, I really want the old style 'everything global' style.

- -

Write your own package manager, then. It's not that hard.

- -

npm will not help you do something that is known to be a bad idea.

- -

Should I check my node_modules folder into git?

- -

Mikeal Rogers answered this question very well:

- -

http://www.mikealrogers.com/posts/nodemodules-in-git.html

- -

tl;dr

- -
  • Check node_modules into git for things you deploy, such as -websites and apps.
  • Do not check node_modules into git for libraries and modules -intended to be reused.
  • Use npm to manage dependencies in your dev environment, but not in -your deployment scripts.
- -

Is it 'npm' or 'NPM' or 'Npm'?

- -

npm should never be capitalized unless it is being displayed in a -location that is customarily all-caps (such as the title of man pages.)

- -

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 https://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.

- -

What is a module?

- -

A module is anything that can be loaded with require() in a Node.js -program. The following things are all examples of things that can be -loaded as modules:

- -
  • A folder with a package.json file containing a main field.
  • A folder with an index.js file in it.
  • A JavaScript file.
- -

Most npm packages are modules, because they are libraries that you -load with require. However, there's no requirement that an npm -package be a module! Some only contain an executable command-line -interface, and don't provide a main field for use in Node programs.

- -

Almost all npm packages (at least, those that are Node programs) -contain many modules within them (because every file they load with -require() is a module).

- -

In the context of a Node program, the module is also the thing that -was loaded from a file. For example, in the following program:

- -
var req = require('request')
- -

we might say that "The variable req refers to the request module".

- -

So, why is it the "node_modules" folder, but "package.json" file? Why not node_packages or module.json?

- -

The package.json file defines the package. (See "What is a -package?" above.)

- -

The node_modules folder is the place Node.js looks for modules. -(See "What is a module?" above.)

- -

For example, if you create a file at node_modules/foo.js and then -had a program that did var f = require('foo.js') then it would load -the module. However, foo.js is not a "package" in this case, -because it does not have a package.json.

- -

Alternatively, if you create a package which does not have an -index.js or a "main" field in the package.json file, then it is -not a module. Even if it's installed in node_modules, it can't be -an argument to require().

- -

"node_modules" is the name of my deity's arch-rival, and a Forbidden Word in my religion. Can I configure npm to use a different folder?

- -

No. This will never happen. This question comes up sometimes, -because it seems silly from the outside that npm couldn't just be -configured to put stuff somewhere else, and then npm could load them -from there. It's an arbitrary spelling choice, right? What's the big -deal?

- -

At the time of this writing, the string 'node_modules' appears 151 -times in 53 separate files in npm and node core (excluding tests and -documentation).

- -

Some of these references are in node's built-in module loader. Since -npm is not involved at all at run-time, node itself would have to -be configured to know where you've decided to stick stuff. Complexity -hurdle #1. Since the Node module system is locked, this cannot be -changed, and is enough to kill this request. But I'll continue, in -deference to your deity's delicate feelings regarding spelling.

- -

Many of the others are in dependencies that npm uses, which are not -necessarily tightly coupled to npm (in the sense that they do not read -npm's configuration files, etc.) Each of these would have to be -configured to take the name of the node_modules folder as a -parameter. Complexity hurdle #2.

- -

Furthermore, npm has the ability to "bundle" dependencies by adding -the dep names to the "bundledDependencies" list in package.json, -which causes the folder to be included in the package tarball. What -if the author of a module bundles its dependencies, and they use a -different spelling for node_modules? npm would have to rename the -folder at publish time, and then be smart enough to unpack it using -your locally configured name. Complexity hurdle #3.

- -

Furthermore, what happens when you change this name? Fine, it's -easy enough the first time, just rename the node_modules folders to -./blergyblerp/ or whatever name you choose. But what about when you -change it again? npm doesn't currently track any state about past -configuration settings, so this would be rather difficult to do -properly. It would have to track every previous value for this -config, and always accept any of them, or else yesterday's install may -be broken tomorrow. Complexity hurdle #5.

- -

Never going to happen. The folder is named node_modules. It is -written indelibly in the Node Way, handed down from the ancient times -of Node 0.3.

- -

How do I install node with npm?

- -

You don't. Try one of these node version managers:

- -

Unix:

- - - -

Windows:

- - - -

How can I use npm for development?

- -

See developers(1) and 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 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.)

- - - -

See link(1)

- -

The package registry website. What is that exactly?

- -

See registry(1).

- -

I forgot my password, and can't publish. How do I reset it?

- -

Go to https://npmjs.org/forgot.

- -

I get ECONNREFUSED a lot. What's up?

- -

Either the registry is down, or node's DNS isn't able to reach out.

- -

To check if the registry is down, open up http://registry.npmjs.org/ -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 i@izs.me or posting -an issue at https://github.com/isaacs/npm/issues. We'll have -someone kick it or something.

- -

Why no namespaces?

- -

Please see this discussion: https://github.com/isaacs/npm/issues/798

- -

tl;dr - It doesn't actually make things better, and can make them worse.

- -

If you want to namespace your own packages, you may: simply use the -- character to separate the names. npm is a mostly anarchic system. -There is not sufficient need to impose namespace rules on everyone.

- -

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?

- -

Post an issue on the github project:

- - - -

Why does npm hate me?

- -

npm is not capable of hatred. It loves everyone, especially you.

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/files/npm-folders.html b/deps/npm/html/doc/files/npm-folders.html new file mode 100644 index 000000000..00dacef55 --- /dev/null +++ b/deps/npm/html/doc/files/npm-folders.html @@ -0,0 +1,239 @@ + + + npm-folders + + + + +
+

npm-folders

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 cded +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 satisfies bar's dependency on blerg@1.x, +it does not install another copy under [B].

+ +

Bar [B] also has dependencies on baz and asdf, so those are installed in +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 package.json(5) for more information.

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/files/npm-global.html b/deps/npm/html/doc/files/npm-global.html new file mode 100644 index 000000000..00dacef55 --- /dev/null +++ b/deps/npm/html/doc/files/npm-global.html @@ -0,0 +1,239 @@ + + + npm-folders + + + + +
+

npm-folders

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 cded +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 satisfies bar's dependency on blerg@1.x, +it does not install another copy under [B].

+ +

Bar [B] also has dependencies on baz and asdf, so those are installed in +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 package.json(5) for more information.

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/files/npm-json.html b/deps/npm/html/doc/files/npm-json.html new file mode 100644 index 000000000..a8e0f6279 --- /dev/null +++ b/deps/npm/html/doc/files/npm-json.html @@ -0,0 +1,580 @@ + + + package.json + + + + +
+

package.json

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(7).

+ +

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.

  • "scripts":{"preinstall": "node-gyp rebuild"}

    If there is a binding.gyp file in the root of your package, npm will +default the preinstall command to compile using node-gyp.

  • "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, 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.

+ +

license

+ +

You should specify a license for your package so that people know how they are +permitted to use it, and any restrictions you're placing on it.

+ +

The simplest way, assuming you're using a common license such as BSD or MIT, is +to just specify the name of the license you're using, like this:

+ +
{ "license" : "BSD" }
+ +

If you have more complex licensing terms, or you want to provide more detail +in your package.json file, you can use the more verbose plural form, like this:

+ +
"licenses" : [
+  { "type" : "MyLicense"
+  , "url" : "http://github.com/owner/project/path/to/license"
+  }
+]
+ +

It's also a good idea to include a license file at the top level in your package.

+ +

people fields: author, contributors

+ +

The "author" is one person. "contributors" is an array of people. A "person" +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 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, +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(7) 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(7) and npm-scripts(7) 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.
  • git... See 'Git URLs as Dependencies' below
+ +

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 <1.3.0"
  • "~1" = ">=1.0.0 <1.1.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.

+ +

Git URLs as Dependencies

+ +

Git urls can be of the form:

+ +
git://github.com/user/project.git#commit-ish
+git+ssh://user@hostname: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.

+ +

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 or when doing +npm install from the root of a package, and can be managed like any other npm +configuration param. See npm-config(7) 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.

+ +

optionalDependencies

+ +

If a dependency can be used, but you would like npm to proceed if it +cannot be found or fails to install, then you may put it in the +optionalDependencies hash. This is a map of package name to version +or url, just like the dependencies hash. The difference is that +failure is tolerated.

+ +

It is still your program's responsibility to handle the lack of the +dependency. For example, something like this:

+ +
try {
+  var foo = require('foo')
+  var fooVersion = require('foo/package.json').version
+} catch (er) {
+  foo = null
+}
+if ( notGoodFooVersion(fooVersion) ) {
+  foo = null
+}
+
+// .. then later in your program ..
+
+if (foo) {
+  foo.doFooThings()
+}
+ +

Entries in optionalDependencies will override entries of the same name in +dependencies, so it's usually best to only put in one place.

+ +

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" } }
+ +

Note that, unless the user has set the engine-strict config flag, this +field is advisory only.

+ +

engineStrict

+ +

If you are sure that your module will definitely not run properly on +versions of Node/npm other than those specified in the engines hash, +then you can set "engineStrict": true in your package.json file. +This will override the user's engine-strict config setting.

+ +

Please do not do this unless you are really very very sure. If your +engines hash is something overly restrictive, you can quite easily and +inadvertently lock yourself into obscurity and prevent your users from +updating to new versions of Node. Consider this choice carefully. If +people abuse it, it will be removed in a future version of npm.

+ +

os

+ +

You can specify which operating systems your +module will run on:

+ +
"os" : [ "darwin", "linux" ]
+ +

You can also blacklist instead of whitelist operating systems, +just prepend the blacklisted os with a '!':

+ +
"os" : [ "!win32" ]
+ +

The host operating system is determined by process.platform

+ +

It is allowed to both blacklist, and whitelist, although there isn't any +good reason to do this.

+ +

cpu

+ +

If your code only runs on certain cpu architectures, +you can specify which ones.

+ +
"cpu" : [ "x64", "ia32" ]
+ +

Like the os option, you can also blacklist architectures:

+ +
"cpu" : [ "!arm", "!mips" ]
+ +

The host architecture is determined by process.arch

+ +

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 specific 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(7) to see the list of config options that can be +overridden.

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/files/npmrc.html b/deps/npm/html/doc/files/npmrc.html new file mode 100644 index 000000000..90cc13410 --- /dev/null +++ b/deps/npm/html/doc/files/npmrc.html @@ -0,0 +1,93 @@ + + + npmrc + + + + +
+

npmrc

The npm config files

+ +

DESCRIPTION

+ +

npm gets its config settings from the command line, environment +variables, and npmrc files.

+ +

The npm config command can be used to update and edit the contents +of the user and global npmrc files.

+ +

For a list of available configuration options, see npm-config(7).

+ +

FILES

+ +

The three relevant files are:

+ +
  • per-user config file (~/.npmrc)
  • global config file ($PREFIX/npmrc)
  • npm builtin config file (/path/to/npm/npmrc)
+ +

All npm config files are an ini-formatted list of key = value +parameters. Environment variables can be replaced using +${VARIABLE_NAME}. For example:

+ +
prefix = ${HOME}/.npm-packages
+ +

Each of these files is loaded, and config options are resolved in +priority order. For example, a setting in the userconfig file would +override the setting in the globalconfig file.

+ +

Per-user config file

+ +

$HOME/.npmrc (or the userconfig param, if set in the environment +or on the command line)

+ +

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. +Environment variables can be replaced as above.

+ +

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.

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/files/package.json.html b/deps/npm/html/doc/files/package.json.html new file mode 100644 index 000000000..a8e0f6279 --- /dev/null +++ b/deps/npm/html/doc/files/package.json.html @@ -0,0 +1,580 @@ + + + package.json + + + + +
+

package.json

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(7).

+ +

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.

  • "scripts":{"preinstall": "node-gyp rebuild"}

    If there is a binding.gyp file in the root of your package, npm will +default the preinstall command to compile using node-gyp.

  • "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, 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.

+ +

license

+ +

You should specify a license for your package so that people know how they are +permitted to use it, and any restrictions you're placing on it.

+ +

The simplest way, assuming you're using a common license such as BSD or MIT, is +to just specify the name of the license you're using, like this:

+ +
{ "license" : "BSD" }
+ +

If you have more complex licensing terms, or you want to provide more detail +in your package.json file, you can use the more verbose plural form, like this:

+ +
"licenses" : [
+  { "type" : "MyLicense"
+  , "url" : "http://github.com/owner/project/path/to/license"
+  }
+]
+ +

It's also a good idea to include a license file at the top level in your package.

+ +

people fields: author, contributors

+ +

The "author" is one person. "contributors" is an array of people. A "person" +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 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, +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(7) 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(7) and npm-scripts(7) 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.
  • git... See 'Git URLs as Dependencies' below
+ +

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 <1.3.0"
  • "~1" = ">=1.0.0 <1.1.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.

+ +

Git URLs as Dependencies

+ +

Git urls can be of the form:

+ +
git://github.com/user/project.git#commit-ish
+git+ssh://user@hostname: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.

+ +

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 or when doing +npm install from the root of a package, and can be managed like any other npm +configuration param. See npm-config(7) 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.

+ +

optionalDependencies

+ +

If a dependency can be used, but you would like npm to proceed if it +cannot be found or fails to install, then you may put it in the +optionalDependencies hash. This is a map of package name to version +or url, just like the dependencies hash. The difference is that +failure is tolerated.

+ +

It is still your program's responsibility to handle the lack of the +dependency. For example, something like this:

+ +
try {
+  var foo = require('foo')
+  var fooVersion = require('foo/package.json').version
+} catch (er) {
+  foo = null
+}
+if ( notGoodFooVersion(fooVersion) ) {
+  foo = null
+}
+
+// .. then later in your program ..
+
+if (foo) {
+  foo.doFooThings()
+}
+ +

Entries in optionalDependencies will override entries of the same name in +dependencies, so it's usually best to only put in one place.

+ +

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" } }
+ +

Note that, unless the user has set the engine-strict config flag, this +field is advisory only.

+ +

engineStrict

+ +

If you are sure that your module will definitely not run properly on +versions of Node/npm other than those specified in the engines hash, +then you can set "engineStrict": true in your package.json file. +This will override the user's engine-strict config setting.

+ +

Please do not do this unless you are really very very sure. If your +engines hash is something overly restrictive, you can quite easily and +inadvertently lock yourself into obscurity and prevent your users from +updating to new versions of Node. Consider this choice carefully. If +people abuse it, it will be removed in a future version of npm.

+ +

os

+ +

You can specify which operating systems your +module will run on:

+ +
"os" : [ "darwin", "linux" ]
+ +

You can also blacklist instead of whitelist operating systems, +just prepend the blacklisted os with a '!':

+ +
"os" : [ "!win32" ]
+ +

The host operating system is determined by process.platform

+ +

It is allowed to both blacklist, and whitelist, although there isn't any +good reason to do this.

+ +

cpu

+ +

If your code only runs on certain cpu architectures, +you can specify which ones.

+ +
"cpu" : [ "x64", "ia32" ]
+ +

Like the os option, you can also blacklist architectures:

+ +
"cpu" : [ "!arm", "!mips" ]
+ +

The host architecture is determined by process.arch

+ +

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 specific 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(7) to see the list of config options that can be +overridden.

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/folders.html b/deps/npm/html/doc/folders.html deleted file mode 100644 index f52c1c43a..000000000 --- a/deps/npm/html/doc/folders.html +++ /dev/null @@ -1,240 +0,0 @@ - - - folders - - - - -
-

folders

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 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 cded -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 satisfies bar's dependency on blerg@1.x, -it does not install another copy under [B].

- -

Bar [B] also has dependencies on baz and asdf, so those are installed in -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 json(1) for more information.

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/global.html b/deps/npm/html/doc/global.html deleted file mode 100644 index 58fe8b266..000000000 --- a/deps/npm/html/doc/global.html +++ /dev/null @@ -1,240 +0,0 @@ - - - global - - - - -
-

folders

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 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 cded -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 json(1) for more information.

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/help-search.html b/deps/npm/html/doc/help-search.html deleted file mode 100644 index c97088e77..000000000 --- a/deps/npm/html/doc/help-search.html +++ /dev/null @@ -1,73 +0,0 @@ - - - help-search - - - - -
-

help-search

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

- - -
- - - diff --git a/deps/npm/html/doc/help.html b/deps/npm/html/doc/help.html deleted file mode 100644 index 9fed2218d..000000000 --- a/deps/npm/html/doc/help.html +++ /dev/null @@ -1,71 +0,0 @@ - - - help - - - - -
-

help

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

- - -
- - - diff --git a/deps/npm/html/doc/index.html b/deps/npm/html/doc/index.html index 1dea4fbb9..d4f2e1115 100644 --- a/deps/npm/html/doc/index.html +++ b/deps/npm/html/doc/index.html @@ -1,406 +1,414 @@ - index + npm-index
-

index

Index of all npm documentation

+

npm-index

Index of all npm documentation

-

README

+

README

-

node package manager

+

node package manager

Command Line Documentation

-

adduser(1)

+

npm(1)

-

Add a registry user account

+

node package manager

-

bin(1)

+

npm-adduser(1)

-

Display npm bin folder

+

Add a registry user account

-

bugs(1)

+

npm-bin(1)

-

Bugs for a package in a web browser maybe

+

Display npm bin folder

-

build(1)

+

npm-bugs(1)

-

Build a package

+

Bugs for a package in a web browser maybe

-

bundle(1)

+

npm-build(1)

-

REMOVED

+

Build a package

-

cache(1)

+

npm-bundle(1)

-

Manipulates packages cache

+

REMOVED

-

changelog(1)

+

npm-cache(1)

-

Changes

+

Manipulates packages cache

-

coding-style(1)

+

npm-completion(1)

-

npm's "funny" coding style

+

Tab Completion for npm

-

completion(1)

+

npm-config(1)

-

Tab Completion for npm

+

Manage the npm configuration files

-

config(1)

+

npm-dedupe(1)

-

Manage the npm configuration file

+

Reduce duplication

-

dedupe(1)

+

npm-deprecate(1)

-

Reduce duplication

+

Deprecate a version of a package

-

deprecate(1)

+

npm-docs(1)

-

Deprecate a version of a package

+

Docs for a package in a web browser maybe

-

developers(1)

+

npm-edit(1)

-

Developer Guide

+

Edit an installed package

-

disputes(1)

+

npm-explore(1)

-

Handling Module Name Disputes

+

Browse an installed package

-

docs(1)

+

npm-help-search(1)

-

Docs for a package in a web browser maybe

+

Search npm help documentation

-

edit(1)

+

npm-help(1)

-

Edit an installed package

+

Get help on npm

-

explore(1)

+

npm-init(1)

-

Browse an installed package

+

Interactively create a package.json file

-

faq(1)

+

npm-install(1)

-

Frequently Asked Questions

+

Install a package

-

folders(1)

+ -

Folder Structures Used by npm

+

Symlink a package folder

-

global(1)

+

npm-ls(1)

-

Folder Structures Used by npm

+

List installed packages

-

help-search(1)

+

npm-outdated(1)

-

Search npm help documentation

+

Check for outdated packages

-

help(1)

+

npm-owner(1)

-

Get help on npm

+

Manage package owners

-

init(1)

+

npm-pack(1)

-

Interactively create a package.json file

+

Create a tarball from a package

-

install(1)

+

npm-prefix(1)

-

Install a package

+

Display prefix

-

json(1)

+

npm-prune(1)

-

Specifics of npm's package.json handling

+

Remove extraneous packages

- +

npm-publish(1)

-

Symlink a package folder

+

Publish a package

-

ls(1)

+

npm-rebuild(1)

-

List installed packages

+

Rebuild a package

-

npm(1)

+

npm-restart(1)

-

node package manager

+

Start a package

-

outdated(1)

+

npm-rm(1)

-

Check for outdated packages

+

Remove a package

-

owner(1)

+

npm-root(1)

-

Manage package owners

+

Display npm root

-

pack(1)

+

npm-run-script(1)

-

Create a tarball from a package

+

Run arbitrary package scripts

-

prefix(1)

+

npm-search(1)

-

Display prefix

+

Search for packages

-

prune(1)

+

npm-shrinkwrap(1)

-

Remove extraneous packages

+

Lock down dependency versions

-

publish(1)

+

npm-star(1)

-

Publish a package

+

Mark your favorite packages

-

rebuild(1)

+

npm-stars(1)

-

Rebuild a package

+

View packages marked as favorites

-

registry(1)

+

npm-start(1)

-

The JavaScript Package Registry

+

Start a package

-

removing-npm(1)

+

npm-stop(1)

-

Cleaning the Slate

+

Stop a package

-

restart(1)

+

npm-submodule(1)

-

Start a package

+

Add a package as a git submodule

-

rm(1)

+

npm-tag(1)

-

Remove a package

+

Tag a published version

-

root(1)

+

npm-test(1)

-

Display npm root

+

Test a package

-

run-script(1)

+

npm-uninstall(1)

-

Run arbitrary package scripts

+

Remove a package

-

scripts(1)

+

npm-unpublish(1)

-

How npm handles the "scripts" field

+

Remove a package from the registry

-

search(1)

+

npm-update(1)

-

Search for packages

+

Update a package

-

semver(1)

+

npm-version(1)

-

The semantic versioner for npm

+

Bump a package version

-

shrinkwrap(1)

+

npm-view(1)

-

Lock down dependency versions

+

View registry info

-

star(1)

+

npm-whoami(1)

-

Mark your favorite packages

+

Display npm username

-

stars(1)

+

API Documentation

-

View packages marked as favorites

+

npm(3)

-

start(1)

+

node package manager

-

Start a package

+

npm-bin(3)

-

stop(1)

+

Display npm bin folder

-

Stop a package

+

npm-bugs(3)

-

submodule(1)

+

Bugs for a package in a web browser maybe

-

Add a package as a git submodule

+

npm-commands(3)

-

tag(1)

+

npm commands

-

Tag a published version

+

npm-config(3)

-

test(1)

+

Manage the npm configuration files

-

Test a package

+

npm-deprecate(3)

-

uninstall(1)

+

Deprecate a version of a package

-

Remove a package

+

npm-docs(3)

-

unpublish(1)

+

Docs for a package in a web browser maybe

-

Remove a package from the registry

+

npm-edit(3)

-

update(1)

+

Edit an installed package

-

Update a package

+

npm-explore(3)

-

version(1)

+

Browse an installed package

-

Bump a package version

+

npm-help-search(3)

-

view(1)

+

Search the help pages

-

View registry info

+

npm-init(3)

-

whoami(1)

+

Interactively create a package.json file

-

Display npm username

+

npm-install(3)

-

API Documentation

+

install a package programmatically

+ + + +

Symlink a package folder

+ +

npm-load(3)

+ +

Load config settings

-

bin(3)

+

npm-ls(3)

-

Display npm bin folder

+

List installed packages

-

bugs(3)

+

npm-outdated(3)

-

Bugs for a package in a web browser maybe

+

Check for outdated packages

-

commands(3)

+

npm-owner(3)

-

npm commands

+

Manage package owners

-

config(3)

+

npm-pack(3)

-

Manage the npm configuration files

+

Create a tarball from a package

-

deprecate(3)

+

npm-prefix(3)

-

Deprecate a version of a package

+

Display prefix

-

docs(3)

+

npm-prune(3)

-

Docs for a package in a web browser maybe

+

Remove extraneous packages

-

edit(3)

+

npm-publish(3)

-

Edit an installed package

+

Publish a package

-

explore(3)

+

npm-rebuild(3)

-

Browse an installed package

+

Rebuild a package

-

help-search(3)

+

npm-restart(3)

-

Search the help pages

+

Start a package

-

init(3)

+

npm-root(3)

-

Interactively create a package.json file

+

Display npm root

-

install(3)

+

npm-run-script(3)

-

install a package programmatically

+

Run arbitrary package scripts

- +

npm-search(3)

-

Symlink a package folder

+

Search for packages

-

load(3)

+

npm-shrinkwrap(3)

-

Load config settings

+

programmatically generate package shrinkwrap file

-

ls(3)

+

npm-start(3)

-

List installed packages

+

Start a package

-

npm(3)

+

npm-stop(3)

-

node package manager

+

Stop a package

-

outdated(3)

+

npm-submodule(3)

-

Check for outdated packages

+

Add a package as a git submodule

-

owner(3)

+

npm-tag(3)

-

Manage package owners

+

Tag a published version

-

pack(3)

+

npm-test(3)

-

Create a tarball from a package

+

Test a package

-

prefix(3)

+

npm-uninstall(3)

-

Display prefix

+

uninstall a package programmatically

-

prune(3)

+

npm-unpublish(3)

-

Remove extraneous packages

+

Remove a package from the registry

-

publish(3)

+

npm-update(3)

-

Publish a package

+

Update a package

-

rebuild(3)

+

npm-version(3)

-

Rebuild a package

+

Bump a package version

-

restart(3)

+

npm-view(3)

-

Start a package

+

View registry info

-

root(3)

+

npm-whoami(3)

-

Display npm root

+

Display npm username

-

run-script(3)

+

Files

-

Run arbitrary package scripts

+

npm-folders(5)

-

search(3)

+

Folder Structures Used by npm

-

Search for packages

+

npmrc(5)

-

shrinkwrap(3)

+

The npm config files

-

programmatically generate package shrinkwrap file

+

package.json(5)

-

start(3)

+

Specifics of npm's package.json handling

-

Start a package

+

Misc

-

stop(3)

+

npm-coding-style(7)

-

Stop a package

+

npm's "funny" coding style

-

submodule(3)

+

npm-config(7)

-

Add a package as a git submodule

+

More than you probably want to know about npm configuration

-

tag(3)

+

npm-developers(7)

-

Tag a published version

+

Developer Guide

-

test(3)

+

npm-disputes(7)

-

Test a package

+

Handling Module Name Disputes

-

uninstall(3)

+

npm-faq(7)

-

uninstall a package programmatically

+

Frequently Asked Questions

-

unpublish(3)

+

npm-index(7)

-

Remove a package from the registry

+

Index of all npm documentation

-

update(3)

+

npm-registry(7)

-

Update a package

+

The JavaScript Package Registry

-

version(3)

+

npm-scripts(7)

-

Bump a package version

+

How npm handles the "scripts" field

-

view(3)

+

removing-npm(7)

-

View registry info

+

Cleaning the Slate

-

whoami(3)

+

semver(7)

-

Display npm username

+

The semantic versioner for npm

- + - diff --git a/deps/npm/html/doc/init.html b/deps/npm/html/doc/init.html deleted file mode 100644 index b0b39a029..000000000 --- a/deps/npm/html/doc/init.html +++ /dev/null @@ -1,64 +0,0 @@ - - - init - - - - -
-

init

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

- - -
- - - diff --git a/deps/npm/html/doc/install.html b/deps/npm/html/doc/install.html deleted file mode 100644 index 846033a96..000000000 --- a/deps/npm/html/doc/install.html +++ /dev/null @@ -1,177 +0,0 @@ - - - install - - - - -
-

install

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> [--save|--save-dev|--save-optional]
-npm install <name>@<tag>
-npm install <name>@<version>
-npm install <name>@<version range>
-npm install <name>@<version range>
- -

DESCRIPTION

- -

This command installs a package, and any packages that it depends on. If the -package has a shrinkwrap file, the installation of dependencies will be driven -by that. See shrinkwrap(1).

- -

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> [--save|--save-dev|--save-optional]:

    Do a <name>@<tag> install, where <tag> is the "tag" config. (See -config(1).)

    In most cases, this will install the latest version -of the module published on npm.

    Example:

    npm install sax

    npm install takes 3 exclusive, optional flags which save or update -the package version in your main package.json:

    • --save: Package will appear in your dependencies.

    • --save-dev: Package will appear in your devDependencies.

    • --save-optional: Package will appear in your optionalDependencies.

      Examples:

      npm install sax --save - npm install node-tap --save-dev - npm install dtrace-provider --save-optional

      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 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 folders(1).

- -

The --link argument will cause npm to link global installs into the -local space in some cases.

- -

The --no-bin-links argument will prevent npm from creating symlinks for -any binaries the package might contain.

- -

The --no-shrinkwrap argument, which will ignore an available -shrinkwrap file and use the package.json instead.

- -

The --nodedir=/path/to/node/source argument will allow npm to find the -node source code so that npm can compile native modules.

- -

See 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 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

- - -
- - - diff --git a/deps/npm/html/doc/json.html b/deps/npm/html/doc/json.html deleted file mode 100644 index 749c5f1fe..000000000 --- a/deps/npm/html/doc/json.html +++ /dev/null @@ -1,581 +0,0 @@ - - - json - - - - -
-

json

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 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.

  • "scripts":{"preinstall": "node-gyp rebuild"}

    If there is a binding.gyp file in the root of your package, npm will -default the preinstall command to compile using node-gyp.

  • "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, 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.

- -

license

- -

You should specify a license for your package so that people know how they are -permitted to use it, and any restrictions you're placing on it.

- -

The simplest way, assuming you're using a common license such as BSD or MIT, is -to just specify the name of the license you're using, like this:

- -
{ "license" : "BSD" }
- -

If you have more complex licensing terms, or you want to provide more detail -in your package.json file, you can use the more verbose plural form, like this:

- -
"licenses" : [
-  { "type" : "MyLicense"
-  , "url" : "http://github.com/owner/project/path/to/license"
-  }
-]
- -

It's also a good idea to include a license file at the top level in your package.

- -

people fields: author, contributors

- -

The "author" is one person. "contributors" is an array of people. A "person" -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 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, -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 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 config(1) and 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.
  • git... See 'Git URLs as Dependencies' below
- -

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 <1.3.0"
  • "~1" = ">=1.0.0 <1.1.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.

- -

Git URLs as Dependencies

- -

Git urls can be of the form:

- -
git://github.com/user/project.git#commit-ish
-git+ssh://user@hostname: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.

- -

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 or when doing -npm install from the root of a package, and can be managed like any other npm -configuration param. See 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.

- -

optionalDependencies

- -

If a dependency can be used, but you would like npm to proceed if it -cannot be found or fails to install, then you may put it in the -optionalDependencies hash. This is a map of package name to version -or url, just like the dependencies hash. The difference is that -failure is tolerated.

- -

It is still your program's responsibility to handle the lack of the -dependency. For example, something like this:

- -
try {
-  var foo = require('foo')
-  var fooVersion = require('foo/package.json').version
-} catch (er) {
-  foo = null
-}
-if ( notGoodFooVersion(fooVersion) ) {
-  foo = null
-}
-
-// .. then later in your program ..
-
-if (foo) {
-  foo.doFooThings()
-}
- -

Entries in optionalDependencies will override entries of the same name in -dependencies, so it's usually best to only put in one place.

- -

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" } }
- -

Note that, unless the user has set the engine-strict config flag, this -field is advisory only.

- -

engineStrict

- -

If you are sure that your module will definitely not run properly on -versions of Node/npm other than those specified in the engines hash, -then you can set "engineStrict": true in your package.json file. -This will override the user's engine-strict config setting.

- -

Please do not do this unless you are really very very sure. If your -engines hash is something overly restrictive, you can quite easily and -inadvertently lock yourself into obscurity and prevent your users from -updating to new versions of Node. Consider this choice carefully. If -people abuse it, it will be removed in a future version of npm.

- -

os

- -

You can specify which operating systems your -module will run on:

- -
"os" : [ "darwin", "linux" ]
- -

You can also blacklist instead of whitelist operating systems, -just prepend the blacklisted os with a '!':

- -
"os" : [ "!win32" ]
- -

The host operating system is determined by process.platform

- -

It is allowed to both blacklist, and whitelist, although there isn't any -good reason to do this.

- -

cpu

- -

If your code only runs on certain cpu architectures, -you can specify which ones.

- -
"cpu" : [ "x64", "ia32" ]
- -

Like the os option, you can also blacklist architectures:

- -
"cpu" : [ "!arm", "!mips" ]
- -

The host architecture is determined by process.arch

- -

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 specific 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 config(1) to see the list of config options that can be -overridden.

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/link.html b/deps/npm/html/doc/link.html deleted file mode 100644 index 7f23dc4bb..000000000 --- a/deps/npm/html/doc/link.html +++ /dev/null @@ -1,96 +0,0 @@ - - - link - - - - -
-

link

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.

- -

Note that package-name is taken from package.json , -not from directory name.

- -

When creating tarballs for npm publish, the linked packages are -"snapshotted" to their current state by resolving the symbolic links.

- -

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

- - -
- - - diff --git a/deps/npm/html/doc/list.html b/deps/npm/html/doc/list.html deleted file mode 100644 index 45f4b7d1a..000000000 --- a/deps/npm/html/doc/list.html +++ /dev/null @@ -1,99 +0,0 @@ - - - list - - - - -
-

ls

List installed packages

- -

SYNOPSIS

- -
npm list [<pkg> ...]
-npm ls [<pkg> ...]
-npm la [<pkg> ...]
-npm ll [<pkg> ...]
- -

DESCRIPTION

- -

This command will print to stdout all the versions of packages that are -installed, as well as their dependencies, in a tree-structure.

- -

Positional arguments are name@version-range identifiers, which will -limit the results to only the paths to the packages named. Note that -nested packages will also show the paths to the specified packages. -For example, running npm ls promzard in npm's source tree will show:

- -
npm@1.1.59 /path/to/npm
-└─┬ init-package-json@0.0.4
-  └── promzard@0.1.5
- -

It will show print out extraneous, missing, and invalid packages.

- -

When run as ll or la, it shows extended information by default.

- -

CONFIGURATION

- -

json

- -
  • Default: false
  • Type: Boolean
- -

Show information in JSON format.

- -

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

- - -
- - - diff --git a/deps/npm/html/doc/ls.html b/deps/npm/html/doc/ls.html deleted file mode 100644 index 7e6443d9a..000000000 --- a/deps/npm/html/doc/ls.html +++ /dev/null @@ -1,103 +0,0 @@ - - - ls - - - - -
-

ls

List installed packages

- -

SYNOPSIS

- -
npm list [<pkg> ...]
-npm ls [<pkg> ...]
-npm la [<pkg> ...]
-npm ll [<pkg> ...]
- -

DESCRIPTION

- -

This command will print to stdout all the versions of packages that are -installed, as well as their dependencies, in a tree-structure.

- -

Positional arguments are name@version-range identifiers, which will -limit the results to only the paths to the packages named. Note that -nested packages will also show the paths to the specified packages. -For example, running npm ls promzard in npm's source tree will show:

- -
npm@1.3.2 /path/to/npm
-└─┬ init-package-json@0.0.4
-  └── promzard@0.1.5
- -

It will print out extraneous, missing, and invalid packages.

- -

If a project specifies git urls for dependencies these are shown -in parentheses after the name@version to make it easier for users to -recognize potential forks of a project.

- -

When run as ll or la, it shows extended information by default.

- -

CONFIGURATION

- -

json

- -
  • Default: false
  • Type: Boolean
- -

Show information in JSON format.

- -

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

- - -
- - - diff --git a/deps/npm/html/doc/misc/index.html b/deps/npm/html/doc/misc/index.html new file mode 100644 index 000000000..4db393c7c --- /dev/null +++ b/deps/npm/html/doc/misc/index.html @@ -0,0 +1,438 @@ + + + index + + + + +
+

npm-index

Index of all npm documentation

+ +

README

+ +

node package manager

+ +

Command Line Documentation

+ +

npm(1)

+ +

node package manager

+ +

npm-adduser(1)

+ +

Add a registry user account

+ +

npm-bin(1)

+ +

Display npm bin folder

+ +

npm-bugs(1)

+ +

Bugs for a package in a web browser maybe

+ +

npm-build(1)

+ +

Build a package

+ +

npm-bundle(1)

+ +

REMOVED

+ +

npm-cache(1)

+ +

Manipulates packages cache

+ +

npm-completion(1)

+ +

Tab Completion for npm

+ +

npm-config(1)

+ +

Manage the npm configuration files

+ +

npm-dedupe(1)

+ +

Reduce duplication

+ +

npm-deprecate(1)

+ +

Deprecate a version of a package

+ +

npm-docs(1)

+ +

Docs for a package in a web browser maybe

+ +

npm-edit(1)

+ +

Edit an installed package

+ +

npm-explore(1)

+ +

Browse an installed package

+ +

npm-help-search(1)

+ +

Search npm help documentation

+ +

npm-help(1)

+ +

Get help on npm

+ +

npm-init(1)

+ +

Interactively create a package.json file

+ +

npm-install(1)

+ +

Install a package

+ + + +

Symlink a package folder

+ +

npm-ls(1)

+ +

List installed packages

+ +

npm-outdated(1)

+ +

Check for outdated packages

+ +

npm-owner(1)

+ +

Manage package owners

+ +

npm-pack(1)

+ +

Create a tarball from a package

+ +

npm-prefix(1)

+ +

Display prefix

+ +

npm-prune(1)

+ +

Remove extraneous packages

+ +

npm-publish(1)

+ +

Publish a package

+ +

npm-rebuild(1)

+ +

Rebuild a package

+ +

npm-restart(1)

+ +

Start a package

+ +

npm-rm(1)

+ +

Remove a package

+ +

npm-root(1)

+ +

Display npm root

+ +

npm-run-script(1)

+ +

Run arbitrary package scripts

+ +

npm-search(1)

+ +

Search for packages

+ +

npm-shrinkwrap(1)

+ +

Lock down dependency versions

+ +

npm-star(1)

+ +

Mark your favorite packages

+ +

npm-stars(1)

+ +

View packages marked as favorites

+ +

npm-start(1)

+ +

Start a package

+ +

npm-stop(1)

+ +

Stop a package

+ +

npm-submodule(1)

+ +

Add a package as a git submodule

+ +

npm-tag(1)

+ +

Tag a published version

+ +

npm-test(1)

+ +

Test a package

+ +

npm-uninstall(1)

+ +

Remove a package

+ +

npm-unpublish(1)

+ +

Remove a package from the registry

+ +

npm-update(1)

+ +

Update a package

+ +

npm-version(1)

+ +

Bump a package version

+ +

npm-view(1)

+ +

View registry info

+ +

npm-whoami(1)

+ +

Display npm username

+ +

API Documentation

+ +

npm(3)

+ +

node package manager

+ +

npm-bin(3)

+ +

Display npm bin folder

+ +

npm-bugs(3)

+ +

Bugs for a package in a web browser maybe

+ +

npm-commands(3)

+ +

npm commands

+ +

npm-config(3)

+ +

Manage the npm configuration files

+ +

npm-deprecate(3)

+ +

Deprecate a version of a package

+ +

npm-docs(3)

+ +

Docs for a package in a web browser maybe

+ +

npm-edit(3)

+ +

Edit an installed package

+ +

npm-explore(3)

+ +

Browse an installed package

+ +

npm-help-search(3)

+ +

Search the help pages

+ +

npm-init(3)

+ +

Interactively create a package.json file

+ +

npm-install(3)

+ +

install a package programmatically

+ + + +

Symlink a package folder

+ +

npm-load(3)

+ +

Load config settings

+ +

npm-ls(3)

+ +

List installed packages

+ +

npm-outdated(3)

+ +

Check for outdated packages

+ +

npm-owner(3)

+ +

Manage package owners

+ +

npm-pack(3)

+ +

Create a tarball from a package

+ +

npm-prefix(3)

+ +

Display prefix

+ +

npm-prune(3)

+ +

Remove extraneous packages

+ +

npm-publish(3)

+ +

Publish a package

+ +

npm-rebuild(3)

+ +

Rebuild a package

+ +

npm-restart(3)

+ +

Start a package

+ +

npm-root(3)

+ +

Display npm root

+ +

npm-run-script(3)

+ +

Run arbitrary package scripts

+ +

npm-search(3)

+ +

Search for packages

+ +

npm-shrinkwrap(3)

+ +

programmatically generate package shrinkwrap file

+ +

npm-start(3)

+ +

Start a package

+ +

npm-stop(3)

+ +

Stop a package

+ +

npm-submodule(3)

+ +

Add a package as a git submodule

+ +

npm-tag(3)

+ +

Tag a published version

+ +

npm-test(3)

+ +

Test a package

+ +

npm-uninstall(3)

+ +

uninstall a package programmatically

+ +

npm-unpublish(3)

+ +

Remove a package from the registry

+ +

npm-update(3)

+ +

Update a package

+ +

npm-version(3)

+ +

Bump a package version

+ +

npm-view(3)

+ +

View registry info

+ +

npm-whoami(3)

+ +

Display npm username

+ +

Files

+ +

npm-folders(5)

+ +

Folder Structures Used by npm

+ +

npmrc(5)

+ +

The npm config files

+ +

package.json(5)

+ +

Specifics of npm's package.json handling

+ +

Misc

+ +

npm-coding-style(7)

+ +

npm's "funny" coding style

+ +

npm-config(7)

+ +

More than you probably want to know about npm configuration

+ +

npm-developers(7)

+ +

Developer Guide

+ +

npm-disputes(7)

+ +

Handling Module Name Disputes

+ +

npm-faq(7)

+ +

Frequently Asked Questions

+ +

npm-registry(7)

+ +

The JavaScript Package Registry

+ +

npm-scripts(7)

+ +

How npm handles the "scripts" field

+ +

removing-npm(7)

+ +

Cleaning the Slate

+ +

semver(7)

+ +

The semantic versioner for npm

+
+ + diff --git a/deps/npm/html/doc/misc/npm-coding-style.html b/deps/npm/html/doc/misc/npm-coding-style.html new file mode 100644 index 000000000..a44f1dead --- /dev/null +++ b/deps/npm/html/doc/misc/npm-coding-style.html @@ -0,0 +1,216 @@ + + + npm-coding-style + + + + +
+

npm-coding-style

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.

+ +

Note: this concerns npm's code not the specific packages at npmjs.org

+ +

Line Length

+ +

Keep lines shorter than 80 characters. It's better for lines to be +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.

+ +

Logging

+ +

Logging is done using the npmlog +utility.

+ +

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. See npm-config(7) 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

+ + +
+ + diff --git a/deps/npm/html/doc/misc/npm-config.html b/deps/npm/html/doc/misc/npm-config.html new file mode 100644 index 000000000..22c6c7809 --- /dev/null +++ b/deps/npm/html/doc/misc/npm-config.html @@ -0,0 +1,751 @@ + + + npm-config + + + + +
+

npm-config

More than you probably want to know about npm configuration

+ +

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.

+ +

npmrc Files

+ +

The three relevant files are:

+ +
  • per-user config file (~/.npmrc)
  • global config file ($PREFIX/npmrc)
  • npm builtin config file (/path/to/npm/npmrc)
+ +

See npmrc(5) for more details.

+ +

Default Configs

+ +

A set of configuration parameters that are internal to npm, and are +defaults if nothing else is specified.

+ +

Shorthands and Other CLI Niceties

+ +

The following shorthands are parsed on the command-line:

+ +
  • -v: --version
  • -h, -?, --help, -H: --usage
  • -s, --silent: --loglevel silent
  • -q, --quiet: --loglevel warn
  • -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
  • -desc: --description
  • -S: --save
  • -D: --save-dev
  • -O: --save-optional
  • -B: --save-bundle
  • -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(7)) 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
+ +

See package.json(5) for more information.

+ +

Config Settings

+ +

always-auth

+ +
  • Default: false
  • Type: Boolean
+ +

Force npm to always require authentication when accessing the registry, +even for GET requests.

+ + + +
  • Default: true
  • Type: Boolean
+ +

Tells npm to create symlinks (or .cmd shims on Windows) for package +executables.

+ +

Set to false to have it not do this. This can be used to work around +the fact that some file systems don't support symlinks, even on +ostensibly Unix systems.

+ +

browser

+ +
  • Default: OS X: "open", Windows: "start", Others: "xdg-open"
  • 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: %APPDATA%\npm-cache, Posix: ~/.npm
  • Type: path
+ +

The location of npm's cache directory. See npm-cache(1)

+ +

cache-lock-stale

+ +
  • Default: 60000 (1 minute)
  • Type: Number
+ +

The number of ms before cache folder lockfiles are considered stale.

+ +

cache-lock-retries

+ +
  • Default: 10
  • Type: Number
+ +

Number of times to retry to acquire a lock on cache folder lockfiles.

+ +

cache-lock-wait

+ +
  • Default: 10000 (10 seconds)
  • Type: Number
+ +

Number of ms to wait for cache lock files to expire.

+ +

cache-max

+ +
  • Default: Infinity
  • Type: Number
+ +

The maximum time (in seconds) to keep items in the registry cache before +re-checking against the registry.

+ +

Note that no purging is done unless the npm cache clean command is +explicitly used, and that only GET requests use the cache.

+ +

cache-min

+ +
  • Default: 10
  • Type: Number
+ +

The minimum time (in seconds) to keep items in the registry cache before +re-checking against the registry.

+ +

Note that no purging is done unless the npm cache clean command is +explicitly used, and that only GET requests use the cache.

+ +

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.

+ +

coverage

+ +
  • Default: false
  • Type: Boolean
+ +

A flag to tell test-harness to run with their coverage options enabled, +if they respond to the npm_config_coverage environment variable.

+ +

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.

+ +

engine-strict

+ +
  • Default: false
  • Type: Boolean
+ +

If set to true, then npm will stubbornly refuse to install (or even +consider installing) any package that claims to not be compatible with +the current Node.js version.

+ +

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.
+ +

fetch-retries

+ +
  • Default: 2
  • Type: Number
+ +

The "retries" config for the retry module to use when fetching +packages from the registry.

+ +

fetch-retry-factor

+ +
  • Default: 10
  • Type: Number
+ +

The "factor" config for the retry module to use when fetching +packages.

+ +

fetch-retry-mintimeout

+ +
  • Default: 10000 (10 seconds)
  • Type: Number
+ +

The "minTimeout" config for the retry module to use when fetching +packages.

+ +

fetch-retry-maxtimeout

+ +
  • Default: 60000 (1 minute)
  • Type: Number
+ +

The "maxTimeout" config for the retry module to use when fetching +packages.

+ +

git

+ +
  • Default: "git"
  • Type: String
+ +

The command to use for git commands. If git is installed on the +computer, but is not in the PATH, then set this to the full path to +the git binary.

+ +

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(7) for more on the differences in behavior.

+ +
  • packages are installed into the {prefix}/lib/node_modules folder, instead of the +current working directory.
  • bin files are linked to {prefix}/bin
  • man pages are linked to {prefix}/share/man
+ +

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.

+ +

user-agent

+ +
  • Default: node/{process.version} {process.platform} {process.arch}
  • Type: String
+ +

Sets a User-Agent to the request header

+ +

ignore

+ +
  • Default: ""
  • Type: string
+ +

A white-space separated list of glob patterns of files to always exclude +from packages when building tarballs.

+ +

init-module

+ +
  • Default: ~/.npm-init.js
  • Type: path
+ +

A module that will be loaded by the npm init command. See the +documentation for the +init-package-json module +for more information, or npm-init(1).

+ +

init.version

+ +
  • Default: "0.0.0"
  • Type: semver
+ +

The value npm init should use by default for the package version.

+ +

init.author.name

+ +
  • Default: ""
  • 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.

+ +

json

+ +
  • Default: false
  • Type: Boolean
+ +

Whether or not to output JSON data, rather than the normal output.

+ +

This feature is currently experimental, and the output data structures +for many commands is either not implemented in JSON yet, or subject to +change. Only the output from npm ls --json is currently valid.

+ + + +
  • 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.
+ +

loglevel

+ +
  • Default: "http"
  • Type: String
  • Values: "silent", "win", "error", "warn", "http", "info", "verbose", "silly"
+ +

What level of logs to report. On failure, all logs are written to +npm-debug.log in the current working directory.

+ +

Any logs of a higher level than the setting are shown. +The default is "http", which shows http, warn, and error output.

+ +

logstream

+ +
  • Default: process.stderr
  • Type: Stream
+ +

This is the stream that is passed to the +npmlog module at run time.

+ +

It cannot be set from the command line, but if you are using npm +programmatically, you may wish to send logs to somewhere other than +stderr.

+ +

If the color config is set to true, then this stream will receive +colored output if it is a TTY.

+ +

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.

+ +

optional

+ +
  • Default: true
  • Type: Boolean
+ +

Attempt to install packages in the optionalDependencies hash. Note +that if these packages fail to install, the overall installation +process is not aborted.

+ +

parseable

+ +
  • Default: false
  • Type: Boolean
+ +

Output parseable results from commands that write to +standard output.

+ +

prefix

+ + + +

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.
+ +

proprietary-attribs

+ +
  • Default: true
  • Type: Boolean
+ +

Whether or not to include proprietary extended attributes in the +tarballs created by npm.

+ +

Unless you are expecting to unpack package tarballs with something other +than npm -- particularly a very outdated tar implementation -- leave +this as true.

+ +

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.

+ +

When used with the npm rm command, it removes it from the dependencies +hash.

+ +

Only works if there is already a package.json file present.

+ +

save-bundle

+ +
  • Default: false
  • Type: Boolean
+ +

If a package would be saved at install time by the use of --save, +--save-dev, or --save-optional, then also put it in the +bundleDependencies list.

+ +

When used with the npm rm command, it removes it from the +bundledDependencies list.

+ +

save-dev

+ +
  • Default: false
  • Type: Boolean
+ +

Save installed packages to a package.json file as devDependencies.

+ +

When used with the npm rm command, it removes it from the devDependencies +hash.

+ +

Only works if there is already a package.json file present.

+ +

save-optional

+ +
  • Default: false
  • Type: Boolean
+ +

Save installed packages to a package.json file as optionalDependencies.

+ +

When used with the npm rm command, it removes it from the devDependencies +hash.

+ +

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.

+ +

searchsort

+ +
  • Default: "name"
  • Type: String
  • Values: "name", "-name", "date", "-date", "description", +"-description", "keywords", "-keywords"
+ +

Indication of which field to sort search results by. Prefix with a - +character to indicate reverse sort.

+ +

shell

+ +
  • Default: SHELL environment variable, or "bash" on Posix, or "cmd" on +Windows
  • Type: path
+ +

The shell to run for the npm explore command.

+ +

shrinkwrap

+ +
  • Default: true
  • Type: Boolean
+ +

If set to false, then ignore npm-shrinkwrap.json files when +installing.

+ +

sign-git-tag

+ +
  • Default: false
  • Type: Boolean
+ +

If set to true, then the npm version command will tag the version +using -s to add a signature.

+ +

Note that git requires you to have set up GPG keys in your git configs +for this to work properly.

+ +

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.

+ +

versions

+ +
  • Default: false
  • Type: boolean
+ +

If true, output the npm version as well as node's process.versions +hash, 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

+ + +
+ + diff --git a/deps/npm/html/doc/misc/npm-developers.html b/deps/npm/html/doc/misc/npm-developers.html new file mode 100644 index 000000000..3160d46bb --- /dev/null +++ b/deps/npm/html/doc/misc/npm-developers.html @@ -0,0 +1,208 @@ + + + npm-developers + + + + +
+

npm-developers

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)
  • 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.

+ +

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 package.json(5) 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(7).

  • 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.

+ +

By default, the following paths and files are ignored, so there's no +need to add them to .npmignore explicitly:

+ +
  • .*.swp
  • ._*
  • .DS_Store
  • .git
  • .hg
  • .lock-wscript
  • .svn
  • .wafpickle-*
  • CVS
  • npm-debug.log
+ +

Additionally, everything in node_modules is ignored, except for +bundled dependencies. npm automatically handles this for you, so don't +bother adding node_modules to .npmignore.

+ +

The following paths and files are never ignored, so adding them to +.npmignore is pointless:

+ + + + + +

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 +.npmignore file to list out the globs to 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

+ + +
+ + diff --git a/deps/npm/html/doc/misc/npm-disputes.html b/deps/npm/html/doc/misc/npm-disputes.html new file mode 100644 index 000000000..a383e7657 --- /dev/null +++ b/deps/npm/html/doc/misc/npm-disputes.html @@ -0,0 +1,125 @@ + + + npm-disputes + + + + +
+

npm-disputes

Handling Module Name Disputes

+ +

SYNOPSIS

+ +
  1. Get the author email with npm owner ls <pkgname>
  2. Email the author, CC i@izs.me.
  3. After a few weeks, if there's no resolution, we'll sort it out.
+ +

Don't squat on package names. Publish code or move out of the way.

+ +

DESCRIPTION

+ +

There sometimes arise cases where a user publishes a module, and then +later, some other user wants to use that name. Here are some common +ways that happens (each of these is based on actual events.)

+ +
  1. Joe writes a JavaScript module foo, which is not node-specific. +Joe doesn't use node at all. Bob wants to use foo in node, so he +wraps it in an npm module. Some time later, Joe starts using node, +and wants to take over management of his program.
  2. Bob writes an npm module foo, and publishes it. Perhaps much +later, Joe finds a bug in foo, and fixes it. He sends a pull +request to Bob, but Bob doesn't have the time to deal with it, +because he has a new job and a new baby and is focused on his new +erlang project, and kind of not involved with node any more. Joe +would like to publish a new foo, but can't, because the name is +taken.
  3. Bob writes a 10-line flow-control library, and calls it foo, and +publishes it to the npm registry. Being a simple little thing, it +never really has to be updated. Joe works for Foo Inc, the makers +of the critically acclaimed and widely-marketed foo JavaScript +toolkit framework. They publish it to npm as foojs, but people are +routinely confused when npm install foo is some different thing.
  4. Bob writes a parser for the widely-known foo file format, because +he needs it for work. Then, he gets a new job, and never updates the +prototype. Later on, Joe writes a much more complete foo parser, +but can't publish, because Bob's foo is in the way.
+ +

The validity of Joe's claim in each situation can be debated. However, +Joe's appropriate course of action in each case is the same.

+ +
  1. npm owner ls foo. This will tell Joe the email address of the +owner (Bob).
  2. Joe emails Bob, explaining the situation as respectfully as possible, +and what he would like to do with the module name. He adds +isaacs i@izs.me to the CC list of the email. Mention in the email +that Bob can run npm owner add joe foo to add Joe as an owner of +the foo package.
  3. After a reasonable amount of time, if Bob has not responded, or if +Bob and Joe can't come to any sort of resolution, email isaacs +i@izs.me and we'll sort it out. ("Reasonable" is usually about 4 +weeks, but extra time is allowed around common holidays.)
+ +

REASONING

+ +

In almost every case so far, the parties involved have been able to reach +an amicable resolution without any major intervention. Most people +really do want to be reasonable, and are probably not even aware that +they're in your way.

+ +

Module ecosystems are most vibrant and powerful when they are as +self-directed as possible. If an admin one day deletes something you +had worked on, then that is going to make most people quite upset, +regardless of the justification. When humans solve their problems by +talking to other humans with respect, everyone has the chance to end up +feeling good about the interaction.

+ +

EXCEPTIONS

+ +

Some things are not allowed, and will be removed without discussion if +they are brought to the attention of the npm registry admins, including +but not limited to:

+ +
  1. Malware (that is, a package designed to exploit or harm the machine on +which it is installed).
  2. Violations of copyright or licenses (for example, cloning an +MIT-licensed program, and then removing or changing the copyright and +license statement).
  3. Illegal content.
  4. "Squatting" on a package name that you plan to use, but aren't +actually using. Sorry, I don't care how great the name is, or how +perfect a fit it is for the thing that someday might happen. If +someone wants to use it today, and you're just taking up space with +an empty tarball, you're going to be evicted.
  5. Putting empty packages in the registry. Packages must have SOME +functionality. It can be silly, but it can't be nothing. (See +also: squatting.)
  6. Doing weird things with the registry, like using it as your own +personal application database or otherwise putting non-packagey +things into it.
+ +

If you see bad behavior like this, please report it right away.

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/misc/npm-faq.html b/deps/npm/html/doc/misc/npm-faq.html new file mode 100644 index 000000000..854c87b9a --- /dev/null +++ b/deps/npm/html/doc/misc/npm-faq.html @@ -0,0 +1,374 @@ + + + npm-faq + + + + +
+

npm-faq

Frequently Asked Questions

+ +

Where can I find these docs in HTML?

+ +

https://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(5)

+ +

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 on my computer in a central location?

+ +

Install it globally by tacking -g or --global to the command. (This +is especially important for command line utilities that need to add +their bins to the global system PATH.)

+ +

I installed something globally, but I can't require() it

+ +

Install it locally.

+ +

The global install location is a place for command-line utilities +to put their bins in the system PATH. It's not for use with require().

+ +

If you require() a module in your code, then that means it's a +dependency, and a part of your program. You need to install it locally +in your program.

+ +

Why can't npm just put everything in one place, like other package managers?

+ +

Not every change is an improvement, but every improvement is a change. +This would be like asking git to do network IO for every commit. It's +not going to happen, because it's a terrible idea that causes more +problems than it solves.

+ +

It is much harder to avoid dependency conflicts without nesting +dependencies. This is fundamental to the way that npm works, and has +proven to be an extremely successful approach. See npm-folders(5) for +more details.

+ +

If you want a package to be installed in one place, and have all your +programs reference the same copy of it, then use the npm link command. +That's what it's for. Install it globally, then link it into each +program that uses it.

+ +

Whatever, I really want the old style 'everything global' style.

+ +

Write your own package manager, then. It's not that hard.

+ +

npm will not help you do something that is known to be a bad idea.

+ +

Should I check my node_modules folder into git?

+ +

Mikeal Rogers answered this question very well:

+ +

http://www.mikealrogers.com/posts/nodemodules-in-git.html

+ +

tl;dr

+ +
  • Check node_modules into git for things you deploy, such as +websites and apps.
  • Do not check node_modules into git for libraries and modules +intended to be reused.
  • Use npm to manage dependencies in your dev environment, but not in +your deployment scripts.
+ +

Is it 'npm' or 'NPM' or 'Npm'?

+ +

npm should never be capitalized unless it is being displayed in a +location that is customarily all-caps (such as the title of man pages.)

+ +

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 https://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.

+ +

What is a module?

+ +

A module is anything that can be loaded with require() in a Node.js +program. The following things are all examples of things that can be +loaded as modules:

+ +
  • A folder with a package.json file containing a main field.
  • A folder with an index.js file in it.
  • A JavaScript file.
+ +

Most npm packages are modules, because they are libraries that you +load with require. However, there's no requirement that an npm +package be a module! Some only contain an executable command-line +interface, and don't provide a main field for use in Node programs.

+ +

Almost all npm packages (at least, those that are Node programs) +contain many modules within them (because every file they load with +require() is a module).

+ +

In the context of a Node program, the module is also the thing that +was loaded from a file. For example, in the following program:

+ +
var req = require('request')
+ +

we might say that "The variable req refers to the request module".

+ +

So, why is it the "node_modules" folder, but "package.json" file? Why not node_packages or module.json?

+ +

The package.json file defines the package. (See "What is a +package?" above.)

+ +

The node_modules folder is the place Node.js looks for modules. +(See "What is a module?" above.)

+ +

For example, if you create a file at node_modules/foo.js and then +had a program that did var f = require('foo.js') then it would load +the module. However, foo.js is not a "package" in this case, +because it does not have a package.json.

+ +

Alternatively, if you create a package which does not have an +index.js or a "main" field in the package.json file, then it is +not a module. Even if it's installed in node_modules, it can't be +an argument to require().

+ +

"node_modules" is the name of my deity's arch-rival, and a Forbidden Word in my religion. Can I configure npm to use a different folder?

+ +

No. This will never happen. This question comes up sometimes, +because it seems silly from the outside that npm couldn't just be +configured to put stuff somewhere else, and then npm could load them +from there. It's an arbitrary spelling choice, right? What's the big +deal?

+ +

At the time of this writing, the string 'node_modules' appears 151 +times in 53 separate files in npm and node core (excluding tests and +documentation).

+ +

Some of these references are in node's built-in module loader. Since +npm is not involved at all at run-time, node itself would have to +be configured to know where you've decided to stick stuff. Complexity +hurdle #1. Since the Node module system is locked, this cannot be +changed, and is enough to kill this request. But I'll continue, in +deference to your deity's delicate feelings regarding spelling.

+ +

Many of the others are in dependencies that npm uses, which are not +necessarily tightly coupled to npm (in the sense that they do not read +npm's configuration files, etc.) Each of these would have to be +configured to take the name of the node_modules folder as a +parameter. Complexity hurdle #2.

+ +

Furthermore, npm has the ability to "bundle" dependencies by adding +the dep names to the "bundledDependencies" list in package.json, +which causes the folder to be included in the package tarball. What +if the author of a module bundles its dependencies, and they use a +different spelling for node_modules? npm would have to rename the +folder at publish time, and then be smart enough to unpack it using +your locally configured name. Complexity hurdle #3.

+ +

Furthermore, what happens when you change this name? Fine, it's +easy enough the first time, just rename the node_modules folders to +./blergyblerp/ or whatever name you choose. But what about when you +change it again? npm doesn't currently track any state about past +configuration settings, so this would be rather difficult to do +properly. It would have to track every previous value for this +config, and always accept any of them, or else yesterday's install may +be broken tomorrow. Complexity hurdle #5.

+ +

Never going to happen. The folder is named node_modules. It is +written indelibly in the Node Way, handed down from the ancient times +of Node 0.3.

+ +

How do I install node with npm?

+ +

You don't. Try one of these node version managers:

+ +

Unix:

+ + + +

Windows:

+ + + +

How can I use npm for development?

+ +

See npm-developers(7) and package.json(5).

+ +

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(7).

+ +

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

+ + + +

See npm-link(1)

+ +

The package registry website. What is that exactly?

+ +

See npm-registry(7).

+ +

I forgot my password, and can't publish. How do I reset it?

+ +

Go to https://npmjs.org/forgot.

+ +

I get ECONNREFUSED a lot. What's up?

+ +

Either the registry is down, or node's DNS isn't able to reach out.

+ +

To check if the registry is down, open up http://registry.npmjs.org/ +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 i@izs.me or posting +an issue at https://github.com/isaacs/npm/issues. We'll have +someone kick it or something.

+ +

Why no namespaces?

+ +

Please see this discussion: https://github.com/isaacs/npm/issues/798

+ +

tl;dr - It doesn't actually make things better, and can make them worse.

+ +

If you want to namespace your own packages, you may: simply use the +- character to separate the names. npm is a mostly anarchic system. +There is not sufficient need to impose namespace rules on everyone.

+ +

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?

+ +

Post an issue on the github project:

+ + + +

Why does npm hate me?

+ +

npm is not capable of hatred. It loves everyone, especially you.

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/misc/npm-index.html b/deps/npm/html/doc/misc/npm-index.html new file mode 100644 index 000000000..fb768c3e0 --- /dev/null +++ b/deps/npm/html/doc/misc/npm-index.html @@ -0,0 +1,442 @@ + + + npm-index + + + + +
+

npm-index

Index of all npm documentation

+ +

README

+ +

node package manager

+ +

Command Line Documentation

+ +

npm(1)

+ +

node package manager

+ +

npm-adduser(1)

+ +

Add a registry user account

+ +

npm-bin(1)

+ +

Display npm bin folder

+ +

npm-bugs(1)

+ +

Bugs for a package in a web browser maybe

+ +

npm-build(1)

+ +

Build a package

+ +

npm-bundle(1)

+ +

REMOVED

+ +

npm-cache(1)

+ +

Manipulates packages cache

+ +

npm-completion(1)

+ +

Tab Completion for npm

+ +

npm-config(1)

+ +

Manage the npm configuration files

+ +

npm-dedupe(1)

+ +

Reduce duplication

+ +

npm-deprecate(1)

+ +

Deprecate a version of a package

+ +

npm-docs(1)

+ +

Docs for a package in a web browser maybe

+ +

npm-edit(1)

+ +

Edit an installed package

+ +

npm-explore(1)

+ +

Browse an installed package

+ +

npm-help-search(1)

+ +

Search npm help documentation

+ +

npm-help(1)

+ +

Get help on npm

+ +

npm-init(1)

+ +

Interactively create a package.json file

+ +

npm-install(1)

+ +

Install a package

+ + + +

Symlink a package folder

+ +

npm-ls(1)

+ +

List installed packages

+ +

npm-outdated(1)

+ +

Check for outdated packages

+ +

npm-owner(1)

+ +

Manage package owners

+ +

npm-pack(1)

+ +

Create a tarball from a package

+ +

npm-prefix(1)

+ +

Display prefix

+ +

npm-prune(1)

+ +

Remove extraneous packages

+ +

npm-publish(1)

+ +

Publish a package

+ +

npm-rebuild(1)

+ +

Rebuild a package

+ +

npm-restart(1)

+ +

Start a package

+ +

npm-rm(1)

+ +

Remove a package

+ +

npm-root(1)

+ +

Display npm root

+ +

npm-run-script(1)

+ +

Run arbitrary package scripts

+ +

npm-search(1)

+ +

Search for packages

+ +

npm-shrinkwrap(1)

+ +

Lock down dependency versions

+ +

npm-star(1)

+ +

Mark your favorite packages

+ +

npm-stars(1)

+ +

View packages marked as favorites

+ +

npm-start(1)

+ +

Start a package

+ +

npm-stop(1)

+ +

Stop a package

+ +

npm-submodule(1)

+ +

Add a package as a git submodule

+ +

npm-tag(1)

+ +

Tag a published version

+ +

npm-test(1)

+ +

Test a package

+ +

npm-uninstall(1)

+ +

Remove a package

+ +

npm-unpublish(1)

+ +

Remove a package from the registry

+ +

npm-update(1)

+ +

Update a package

+ +

npm-version(1)

+ +

Bump a package version

+ +

npm-view(1)

+ +

View registry info

+ +

npm-whoami(1)

+ +

Display npm username

+ +

API Documentation

+ +

npm(3)

+ +

node package manager

+ +

npm-bin(3)

+ +

Display npm bin folder

+ +

npm-bugs(3)

+ +

Bugs for a package in a web browser maybe

+ +

npm-commands(3)

+ +

npm commands

+ +

npm-config(3)

+ +

Manage the npm configuration files

+ +

npm-deprecate(3)

+ +

Deprecate a version of a package

+ +

npm-docs(3)

+ +

Docs for a package in a web browser maybe

+ +

npm-edit(3)

+ +

Edit an installed package

+ +

npm-explore(3)

+ +

Browse an installed package

+ +

npm-help-search(3)

+ +

Search the help pages

+ +

npm-init(3)

+ +

Interactively create a package.json file

+ +

npm-install(3)

+ +

install a package programmatically

+ + + +

Symlink a package folder

+ +

npm-load(3)

+ +

Load config settings

+ +

npm-ls(3)

+ +

List installed packages

+ +

npm-outdated(3)

+ +

Check for outdated packages

+ +

npm-owner(3)

+ +

Manage package owners

+ +

npm-pack(3)

+ +

Create a tarball from a package

+ +

npm-prefix(3)

+ +

Display prefix

+ +

npm-prune(3)

+ +

Remove extraneous packages

+ +

npm-publish(3)

+ +

Publish a package

+ +

npm-rebuild(3)

+ +

Rebuild a package

+ +

npm-restart(3)

+ +

Start a package

+ +

npm-root(3)

+ +

Display npm root

+ +

npm-run-script(3)

+ +

Run arbitrary package scripts

+ +

npm-search(3)

+ +

Search for packages

+ +

npm-shrinkwrap(3)

+ +

programmatically generate package shrinkwrap file

+ +

npm-start(3)

+ +

Start a package

+ +

npm-stop(3)

+ +

Stop a package

+ +

npm-submodule(3)

+ +

Add a package as a git submodule

+ +

npm-tag(3)

+ +

Tag a published version

+ +

npm-test(3)

+ +

Test a package

+ +

npm-uninstall(3)

+ +

uninstall a package programmatically

+ +

npm-unpublish(3)

+ +

Remove a package from the registry

+ +

npm-update(3)

+ +

Update a package

+ +

npm-version(3)

+ +

Bump a package version

+ +

npm-view(3)

+ +

View registry info

+ +

npm-whoami(3)

+ +

Display npm username

+ +

Files

+ +

npm-folders(5)

+ +

Folder Structures Used by npm

+ +

npmrc(5)

+ +

The npm config files

+ +

package.json(5)

+ +

Specifics of npm's package.json handling

+ +

Misc

+ +

npm-coding-style(7)

+ +

npm's "funny" coding style

+ +

npm-config(7)

+ +

More than you probably want to know about npm configuration

+ +

npm-developers(7)

+ +

Developer Guide

+ +

npm-disputes(7)

+ +

Handling Module Name Disputes

+ +

npm-faq(7)

+ +

Frequently Asked Questions

+ +

npm-index(7)

+ +

Index of all npm documentation

+ +

npm-registry(7)

+ +

The JavaScript Package Registry

+ +

npm-scripts(7)

+ +

How npm handles the "scripts" field

+ +

removing-npm(7)

+ +

Cleaning the Slate

+ +

semver(7)

+ +

The semantic versioner for npm

+
+ + diff --git a/deps/npm/html/doc/misc/npm-registry.html b/deps/npm/html/doc/misc/npm-registry.html new file mode 100644 index 000000000..4f6392d5c --- /dev/null +++ b/deps/npm/html/doc/misc/npm-registry.html @@ -0,0 +1,130 @@ + + + npm-registry + + + + +
+

npm-registry

The JavaScript Package Registry

+ +

DESCRIPTION

+ +

To resolve packages by name and version, npm talks to a registry website +that implements the CommonJS Package Registry specification for reading +package info.

+ +

Additionally, npm's package registry implementation supports several +write APIs as well, to allow for publishing packages and managing user +account information.

+ +

The official public npm registry is at http://registry.npmjs.org/. It +is powered by a CouchDB database at +http://isaacs.iriscouch.com/registry. The code for the couchapp is +available at http://github.com/isaacs/npmjs.org. npm user accounts +are CouchDB users, stored in the http://isaacs.iriscouch.com/_users +database.

+ +

The registry URL is supplied by the registry config parameter. See +npm-config(1), npmrc(5), and npm-config(7) for more on managing +npm's configuration.

+ +

Can I run my own private registry?

+ +

Yes!

+ +

The easiest way is to replicate the couch database, and use the same (or +similar) design doc to implement the APIs.

+ +

If you set up continuous replication from the official CouchDB, and then +set your internal CouchDB as the registry config, then you'll be able +to read any published packages, in addition to your private ones, and by +default will only publish internally. If you then want to publish a +package for the whole world to see, you can simply override the +--registry config for that command.

+ +

I don't want my package published in the official registry. It's private.

+ +

Set "private": true in your package.json to prevent it from being +published at all, or +"publishConfig":{"registry":"http://my-internal-registry.local"} +to force it to be published only to your internal registry.

+ +

See package.json(5) for more info on what goes in the package.json file.

+ +

Will you replicate from my registry into the public one?

+ +

No. If you want things to be public, then publish them into the public +registry using npm. What little security there is would be for nought +otherwise.

+ +

Do I have to use couchdb to build a registry that npm can talk to?

+ +

No, but it's way easier.

+ +

I published something elsewhere, and want to tell the npm registry about it.

+ +

That is supported, but not using the npm client. You'll have to get +your hands dirty and do some HTTP. The request looks something like +this:

+ +
PUT /my-foreign-package
+content-type:application/json
+accept:application/json
+authorization:Basic $base_64_encoded
+
+{ "name":"my-foreign-package"
+, "maintainers":["owner","usernames"]
+, "description":"A package that is hosted elsewhere"
+, "keywords":["nih","my cheese smells the best"]
+, "url":"http://my-different-registry.com/blerg/my-local-package"
+}
+ +

(Keywords and description are optional, but recommended. Name, +maintainers, and url are required.)

+ +

Then, when a user tries to install "my-foreign-package", it'll redirect +to your registry. If that doesn't resolve to a valid package entry, +then it'll fail, so please make sure that you understand the spec, and +ask for help on the npm-@googlegroups.com mailing list.

+ +

Is there a website or something to see package docs and such?

+ +

Yes, head over to https://npmjs.org/

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/misc/npm-scripts.html b/deps/npm/html/doc/misc/npm-scripts.html new file mode 100644 index 000000000..804553288 --- /dev/null +++ b/deps/npm/html/doc/misc/npm-scripts.html @@ -0,0 +1,257 @@ + + + npm-scripts + + + + +
+

npm-scripts

How npm handles the "scripts" field

+ +

DESCRIPTION

+ +

npm supports the "scripts" member of the package.json script, for the +following scripts:

+ +
  • prepublish: +Run BEFORE the package is published. (Also run on local npm +install without any arguments.)
  • publish, postpublish: +Run AFTER the package is published.
  • preinstall: +Run BEFORE the package is installed
  • install, postinstall: +Run AFTER the package is installed.
  • preuninstall, uninstall: +Run BEFORE the package is uninstalled.
  • postuninstall: +Run AFTER the package is uninstalled.
  • preupdate: +Run BEFORE the package is updated with the update command.
  • update, postupdate: +Run AFTER the package is updated with the update command.
  • pretest, test, posttest: +Run by the npm test command.
  • prestop, stop, poststop: +Run by the npm stop command.
  • prestart, start, poststart: +Run by the npm start command.
  • prerestart, restart, postrestart: +Run by the npm restart command. Note: npm restart will run the +stop and start scripts if no restart script is provided.
+ +

Additionally, arbitrary scrips can be run by doing +npm run-script <stage> <pkg>.

+ +

NOTE: INSTALL SCRIPTS ARE AN ANTIPATTERN

+ +

tl;dr Don't use install. Use a .gyp file for compilation, and +prepublish for anything else.

+ +

You should almost never have to explicitly set a preinstall or +install script. If you are doing this, please consider if there is +another option.

+ +

The only valid use of install or preinstall scripts is for +compilation which must be done on the target architecture. In early +versions of node, this was often done using the node-waf scripts, or +a standalone Makefile, and early versions of npm required that it be +explicitly set in package.json. This was not portable, and harder to +do properly.

+ +

In the current version of node, the standard way to do this is using a +.gyp file. If you have a file with a .gyp extension in the root +of your package, then npm will run the appropriate node-gyp commands +automatically at install time. This is the only officially supported +method for compiling binary addons, and does not require that you add +anything to your package.json file.

+ +

If you have to do other things before your package is used, in a way +that is not dependent on the operating system or architecture of the +target system, then use a prepublish script instead. This includes +tasks such as:

+ +
  • Compile CoffeeScript source code into JavaScript.
  • Create minified versions of JavaScript source code.
  • Fetching remote resources that your package will use.
+ +

The advantage of doing these things at prepublish time instead of +preinstall or install time is that they can be done once, in a +single place, and thus greatly reduce complexity and variability. +Additionally, this means that:

+ +
  • You can depend on coffee-script as a devDependency, and thus +your users don't need to have it installed.
  • You don't need to include the minifiers in your package, reducing +the size for your users.
  • You don't need to rely on your users having curl or wget or +other system tools on the target machines.
+ +

DEFAULT VALUES

+ +

npm will default some script values based on package contents.

+ +

  • "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.

  • "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.

+ +

USER

+ +

If npm was invoked with root privileges, then it will change the uid +to the user account or uid specified by the user config, which +defaults to nobody. Set the unsafe-perm flag to run scripts with +root privileges.

+ +

ENVIRONMENT

+ +

Package scripts run in an environment where many pieces of information +are made available regarding the setup of npm and the current state of +the process.

+ +

path

+ +

If you depend on modules that define executable scripts, like test +suites, then those executables will be added to the PATH for +executing the scripts. So, if your package.json has this:

+ +
{ "name" : "foo"
+, "dependencies" : { "bar" : "0.1.x" }
+, "scripts": { "start" : "bar ./test" } }
+ +

then you could run npm start to execute the bar script, which is +exported into the node_modules/.bin directory on npm install.

+ +

package.json vars

+ +

The package.json fields are tacked onto the npm_package_ prefix. So, +for instance, if you had {"name":"foo", "version":"1.2.5"} in your +package.json file, then your package scripts would have the +npm_package_name environment variable set to "foo", and the +npm_package_version set to "1.2.5"

+ +

configuration

+ +

Configuration parameters are put in the environment with the +npm_config_ prefix. For instance, you can view the effective root +config by checking the npm_config_root environment variable.

+ +

Special: package.json "config" hash

+ +

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
+ +

current lifecycle event

+ +

Lastly, the npm_lifecycle_event environment variable is set to +whichever stage of the cycle is being executed. So, you could have a +single script used for different parts of the process which switches +based on what's currently happening.

+ +

Objects are flattened following this format, so if you had +{"scripts":{"install":"foo.js"}} in your package.json, then you'd +see this in the script:

+ +
process.env.npm_package_scripts_install === "foo.js"
+ +

EXAMPLES

+ +

For example, if your package.json contains this:

+ +
{ "scripts" :
+  { "install" : "scripts/install.js"
+  , "postinstall" : "scripts/install.js"
+  , "uninstall" : "scripts/uninstall.js"
+  }
+}
+ +

then the scripts/install.js will be called for the install, +post-install, stages of the lifecycle, and the scripts/uninstall.js +would be called when the package is uninstalled. Since +scripts/install.js is running for three different phases, it would +be wise in this case to look at the npm_lifecycle_event environment +variable.

+ +

If you want to run a make command, you can do so. This works just +fine:

+ +
{ "scripts" :
+  { "preinstall" : "./configure"
+  , "install" : "make && make install"
+  , "test" : "make test"
+  }
+}
+ +

EXITING

+ +

Scripts are run by passing the line as a script argument to sh.

+ +

If the script exits with a code other than 0, then this will abort the +process.

+ +

Note that these script files don't have to be nodejs or even +javascript programs. They just have to be some kind of executable +file.

+ +

HOOK SCRIPTS

+ +

If you want to run a specific script at a specific lifecycle event for +ALL packages, then you can use a hook script.

+ +

Place an executable file at node_modules/.hooks/{eventname}, and +it'll get run for all packages when they are going through that point +in the package lifecycle for any packages installed in that root.

+ +

Hook scripts are run exactly the same way as package.json scripts. +That is, they are in a separate child process, with the env described +above.

+ +

BEST PRACTICES

+ +
  • Don't exit with a non-zero error code unless you really mean it. +Except for uninstall scripts, this will cause the npm action to +fail, and potentially be rolled back. If the failure is minor or +only will prevent some optional features, then it's better to just +print a warning and exit successfully.
  • Try not to use scripts to do what npm can do for you. Read through +package.json(5) to see all the things that you can specify and enable +by simply describing your package appropriately. In general, this +will lead to a more robust and consistent state.
  • Inspect the env to determine where to put things. For instance, if +the npm_config_binroot environ is set to /home/user/bin, then +don't try to install executables into /usr/local/bin. The user +probably set it up that way for a reason.
  • Don't prefix your script commands with "sudo". If root permissions +are required for some reason, then it'll fail with that error, and +the user will sudo the npm command in question.
+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/misc/removing-npm.html b/deps/npm/html/doc/misc/removing-npm.html new file mode 100644 index 000000000..952dc7930 --- /dev/null +++ b/deps/npm/html/doc/misc/removing-npm.html @@ -0,0 +1,92 @@ + + + removing-npm + + + + +
+

npm-removal

Cleaning the Slate

+ +

SYNOPSIS

+ +

So sad to see you go.

+ +
sudo npm uninstall npm -g
+ +

Or, if that fails, get the npm source code, and do:

+ +
sudo make uninstall
+ +

More Severe Uninstalling

+ +

Usually, the above instructions are sufficient. That will remove +npm, but leave behind anything you've installed.

+ +

If that doesn't work, or if you require more drastic measures, +continue reading.

+ +

Note that this is only necessary for globally-installed packages. Local +installs are completely contained within a project's node_modules +folder. Delete that folder, and everything is gone (unless a package's +install script is particularly ill-behaved).

+ +

This assumes that you installed node and npm in the default place. If +you configured node with a different --prefix, or installed npm with a +different prefix setting, then adjust the paths accordingly, replacing +/usr/local with your install prefix.

+ +

To remove everything npm-related manually:

+ +
rm -rf /usr/local/{lib/node{,/.npm,_modules},bin,share/man}/npm*
+ +

If you installed things with npm, then your best bet is to uninstall +them with npm first, and then install them again once you have a +proper install. This can help find any symlinks that are lying +around:

+ +
ls -laF /usr/local/{lib/node{,/.npm},bin,share/man} | grep npm
+ +

Prior to version 0.3, npm used shim files for executables and node +modules. To track those down, you can do the following:

+ +
find /usr/local/{lib/node,bin} -exec grep -l npm \{\} \; ;
+ +

(This is also in the README file.)

+ +

SEE ALSO

+ + +
+ + diff --git a/deps/npm/html/doc/misc/semver.html b/deps/npm/html/doc/misc/semver.html new file mode 100644 index 000000000..19db6e16c --- /dev/null +++ b/deps/npm/html/doc/misc/semver.html @@ -0,0 +1,128 @@ + + + semver + + + + +
+

semver

The semantic versioner for npm

+ +

Usage

+ +
$ npm install semver
+
+semver.valid('1.2.3') // '1.2.3'
+semver.valid('a.b.c') // null
+semver.clean('  =v1.2.3   ') // '1.2.3'
+semver.satisfies('1.2.3', '1.x || >=2.5.0 || 5.0.0 - 7.2.3') // true
+semver.gt('1.2.3', '9.8.7') // false
+semver.lt('1.2.3', '9.8.7') // true
+ +

As a command-line utility:

+ +
$ semver -h
+
+Usage: semver <version> [<version> [...]] [-r <range> | -i <inc> | -d <dec>]
+Test if version(s) satisfy the supplied range(s), and sort them.
+
+Multiple versions or ranges may be supplied, unless increment
+or decrement options are specified.  In that case, only a single
+version may be used, and it is incremented by the specified level
+
+Program exits successfully if any valid version satisfies
+all supplied ranges, and prints all satisfying versions.
+
+If no versions are valid, or ranges are not satisfied,
+then exits failure.
+
+Versions are printed in ascending order, so supplying
+multiple versions to the utility will just sort them.
+ +

Versions

+ +

A "version" is described by the v2.0.0 specification found at +http://semver.org/.

+ +

A leading "=" or "v" character is stripped off and ignored.

+ +

Ranges

+ +

The following range styles are supported:

+ +
  • 1.2.3 A specific version. When nothing else will do. Note that +build metadata is still ignored, so 1.2.3+build2012 will satisfy +this range.
  • >1.2.3 Greater than a specific version.
  • <1.2.3 Less than a specific version. If there is no prerelease +tag on the version range, then no prerelease version will be allowed +either, even though these are technically "less than".
  • >=1.2.3 Greater than or equal to. Note that prerelease versions +are NOT equal to their "normal" equivalents, so 1.2.3-beta will +not satisfy this range, but 2.3.0-beta will.
  • <=1.2.3 Less than or equal to. In this case, prerelease versions +ARE allowed, so 1.2.3-beta would satisfy.
  • 1.2.3 - 2.3.4 := >=1.2.3 <=2.3.4
  • ~1.2.3 := >=1.2.3-0 <1.3.0-0 "Reasonably close to 1.2.3". When +using tilde operators, prerelease versions are supported as well, +but a prerelease of the next significant digit will NOT be +satisfactory, so 1.3.0-beta will not satisfy ~1.2.3.
  • ~1.2 := >=1.2.0-0 <1.3.0-0 "Any version starting with 1.2"
  • 1.2.x := >=1.2.0-0 <1.3.0-0 "Any version starting with 1.2"
  • ~1 := >=1.0.0-0 <2.0.0-0 "Any version starting with 1"
  • 1.x := >=1.0.0-0 <2.0.0-0 "Any version starting with 1"
+ +

Ranges can be joined with either a space (which implies "and") or a +|| (which implies "or").

+ +

Functions

+ +

All methods and classes take a final loose boolean argument that, if +true, will be more forgiving about not-quite-valid semver strings. +The resulting output will always be 100% strict, of course.

+ +

Strict-mode Comparators and Ranges will be strict about the SemVer +strings that they parse.

+ +
  • valid(v): Return the parsed version, or null if it's not valid.
  • inc(v, release): Return the version incremented by the release type +(major, minor, patch, or prerelease), or null if it's not valid.
+ +

Comparison

+ +
  • gt(v1, v2): v1 > v2
  • gte(v1, v2): v1 >= v2
  • lt(v1, v2): v1 < v2
  • lte(v1, v2): v1 <= v2
  • eq(v1, v2): v1 == v2 This is true if they're logically equivalent, +even if they're not the exact same string. You already know how to +compare strings.
  • neq(v1, v2): v1 != v2 The opposite of eq.
  • cmp(v1, comparator, v2): Pass in a comparison string, and it'll call +the corresponding function above. "===" and "!==" do simple +string comparison, but are included for completeness. Throws if an +invalid comparison string is provided.
  • compare(v1, v2): Return 0 if v1 == v2, or 1 if v1 is greater, or -1 if +v2 is greater. Sorts in ascending order if passed to Array.sort().
  • rcompare(v1, v2): The reverse of compare. Sorts an array of versions +in descending order when passed to Array.sort().
+ +

Ranges

+ +
  • validRange(range): Return the valid range or null if it's not valid
  • satisfies(version, range): Return true if the version satisfies the +range.
  • maxSatisfying(versions, range): Return the highest version in the list +that satisfies the range, or null if none of them do.
+
+ + diff --git a/deps/npm/html/doc/npm.html b/deps/npm/html/doc/npm.html deleted file mode 100644 index 87a1b8232..000000000 --- a/deps/npm/html/doc/npm.html +++ /dev/null @@ -1,170 +0,0 @@ - - - npm - - - - -
-

npm

node package manager

- -

SYNOPSIS

- -
npm <command> [args]
- -

VERSION

- -

1.3.2

- -

DESCRIPTION

- -

npm is the package manager for the Node JavaScript platform. It puts -modules in place so that node can find them, and manages dependency -conflicts intelligently.

- -

It is extremely configurable to support a wide variety of use cases. -Most commonly, it is used to publish, discover, install, and develop node -programs.

- -

Run npm help to get a list of available commands.

- -

INTRODUCTION

- -

You probably got npm because you want to install stuff.

- -

Use npm install blerg to install the latest version of "blerg". Check out -install(1) for more info. It can do a lot of stuff.

- -

Use the npm search command to show everything that's available. -Use npm ls to show everything you've installed.

- -

DIRECTORIES

- -

See folders(1) to learn about where npm puts stuff.

- -

In particular, npm has two modes of operation:

- -
  • global mode:
    npm installs packages into the install prefix at -prefix/lib/node_modules and bins are installed in prefix/bin.
  • local mode:
    npm installs packages into the current project directory, which -defaults to the current working directory. Packages are installed to -./node_modules, and bins are installed to ./node_modules/.bin.
- -

Local mode is the default. Use --global or -g on any command to -operate in global mode instead.

- -

DEVELOPER USAGE

- -

If you're using npm to develop and publish your code, check out the -following help topics:

- -
  • json: -Make a package.json file. See json(1).
  • link: -For linking your current working code into Node's path, so that you -don't have to reinstall every time you make a change. Use -npm link to do this.
  • install: -It's a good idea to install things if you don't need the symbolic link. -Especially, installing other peoples code from the registry is done via -npm install
  • adduser: -Create an account or log in. Credentials are stored in the -user config file.
  • publish: -Use the npm publish command to upload your code to the registry.
- -

CONFIGURATION

- -

npm is extremely configurable. It reads its configuration options from -5 places.

- -
  • Command line switches:
    Set a config with --key val. All keys take a value, even if they -are booleans (the config parser doesn't know what the options are at -the time of parsing.) If no value is provided, then the option is set -to boolean true.
  • Environment Variables:
    Set any config by prefixing the name in an environment variable with -npm_config_. For example, export npm_config_key=val.
  • User Configs:
    The file at $HOME/.npmrc is an ini-formatted list of configs. If -present, it is parsed. If the userconfig option is set in the cli -or env, then that will be used instead.
  • Global Configs:
    The file found at ../etc/npmrc (from the node executable, by default -this resolves to /usr/local/etc/npmrc) will be parsed if it is found. -If the globalconfig option is set in the cli, env, or user config, -then that file is parsed instead.
  • Defaults:
    npm's default configuration options are defined in -lib/utils/config-defs.js. These must not be changed.
- -

See config(1) for much much more information.

- -

CONTRIBUTIONS

- -

Patches welcome!

- -
  • code: -Read through coding-style(1) if you plan to submit code. -You don't have to agree with it, but you do have to follow it.
  • docs: -If you find an error in the documentation, edit the appropriate markdown -file in the "doc" folder. (Don't worry about generating the man page.)
- -

Contributors are listed in npm's package.json file. You can view them -easily by doing npm view npm contributors.

- -

If you would like to contribute, but don't know what to work on, check -the issues list or ask on the mailing list.

- - - -

BUGS

- -

When you find issues, please report them:

- - - -

Be sure to include all of the output from the npm command that didn't work -as expected. The npm-debug.log file is also helpful to provide.

- -

You can also look for isaacs in #node.js on irc://irc.freenode.net. He -will no doubt tell you to put the output in a gist or email.

- -

HISTORY

- -

See changelog(1)

- -

AUTHOR

- -

Isaac Z. Schlueter :: -isaacs :: -@izs :: -i@izs.me

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/outdated.html b/deps/npm/html/doc/outdated.html deleted file mode 100644 index 265300146..000000000 --- a/deps/npm/html/doc/outdated.html +++ /dev/null @@ -1,56 +0,0 @@ - - - outdated - - - - -
-

outdated

Check for outdated packages

- -

SYNOPSIS

- -
npm outdated [<name> [<name> ...]]
- -

DESCRIPTION

- -

This command will check the registry to see if any (or, specific) installed -packages are currently outdated.

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/owner.html b/deps/npm/html/doc/owner.html deleted file mode 100644 index 3b49e54a1..000000000 --- a/deps/npm/html/doc/owner.html +++ /dev/null @@ -1,69 +0,0 @@ - - - owner - - - - -
-

owner

Manage package owners

- -

SYNOPSIS

- -
npm owner ls <package name>
-npm owner add <user> <package name>
-npm owner rm <user> <package name>
- -

DESCRIPTION

- -

Manage ownership of published packages.

- -
  • ls: -List all the users who have access to modify a package and push new versions. -Handy when you need to know who to bug for help.
  • add: -Add a new user as a maintainer of a package. This user is enabled to modify -metadata, publish new versions, and add other owners.
  • rm: -Remove a user from the package owner list. This immediately revokes their -privileges.
- -

Note that there is only one level of access. Either you can modify a package, -or you can't. Future versions may contain more fine-grained access levels, but -that is not implemented at this time.

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/pack.html b/deps/npm/html/doc/pack.html deleted file mode 100644 index 63e077be0..000000000 --- a/deps/npm/html/doc/pack.html +++ /dev/null @@ -1,64 +0,0 @@ - - - pack - - - - -
-

pack

Create a tarball from a package

- -

SYNOPSIS

- -
npm pack [<pkg> [<pkg> ...]]
- -

DESCRIPTION

- -

For anything that's installable (that is, a package folder, tarball, -tarball url, name@tag, name@version, or name), this command will fetch -it to the cache, and then copy the tarball to the current working -directory as <name>-<version>.tgz, and then write the filenames out to -stdout.

- -

If the same package is specified multiple times, then the file will be -overwritten the second time.

- -

If no arguments are supplied, then npm packs the current package folder.

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/prefix.html b/deps/npm/html/doc/prefix.html deleted file mode 100644 index 30a531c1c..000000000 --- a/deps/npm/html/doc/prefix.html +++ /dev/null @@ -1,55 +0,0 @@ - - - prefix - - - - -
-

prefix

Display prefix

- -

SYNOPSIS

- -
npm prefix
- -

DESCRIPTION

- -

Print the prefix to standard out.

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/prune.html b/deps/npm/html/doc/prune.html deleted file mode 100644 index 9fa4c6ab5..000000000 --- a/deps/npm/html/doc/prune.html +++ /dev/null @@ -1,60 +0,0 @@ - - - prune - - - - -
-

prune

Remove extraneous packages

- -

SYNOPSIS

- -
npm prune [<name> [<name ...]]
- -

DESCRIPTION

- -

This command removes "extraneous" packages. If a package name is -provided, then only packages matching one of the supplied names are -removed.

- -

Extraneous packages are packages that are not listed on the parent -package's dependencies list.

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/publish.html b/deps/npm/html/doc/publish.html deleted file mode 100644 index 2c392def7..000000000 --- a/deps/npm/html/doc/publish.html +++ /dev/null @@ -1,64 +0,0 @@ - - - publish - - - - -
-

publish

Publish a package

- -

SYNOPSIS

- -
npm publish <tarball>
-npm publish <folder>
- -

DESCRIPTION

- -

Publishes a package to the registry so that it can be installed by name.

- -

  • <folder>: -A folder containing a package.json file

  • <tarball>: -A url or file path to a gzipped tar archive containing a single folder -with a package.json file inside.

- -

Fails if the package name and version combination already exists in -the registry. Overwrites when the "--force" flag is set.

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/rebuild.html b/deps/npm/html/doc/rebuild.html deleted file mode 100644 index ddae0c783..000000000 --- a/deps/npm/html/doc/rebuild.html +++ /dev/null @@ -1,60 +0,0 @@ - - - rebuild - - - - -
-

rebuild

Rebuild a package

- -

SYNOPSIS

- -
npm rebuild [<name> [<name> ...]]
- -
  • <name>: -The package to rebuild
- -

DESCRIPTION

- -

This command runs the npm build command on the matched folders. This is useful -when you install a new version of node, and must recompile all your C++ addons with -the new binary.

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/registry.html b/deps/npm/html/doc/registry.html deleted file mode 100644 index aa4b61f43..000000000 --- a/deps/npm/html/doc/registry.html +++ /dev/null @@ -1,130 +0,0 @@ - - - registry - - - - -
-

registry

The JavaScript Package Registry

- -

DESCRIPTION

- -

To resolve packages by name and version, npm talks to a registry website -that implements the CommonJS Package Registry specification for reading -package info.

- -

Additionally, npm's package registry implementation supports several -write APIs as well, to allow for publishing packages and managing user -account information.

- -

The official public npm registry is at http://registry.npmjs.org/. It -is powered by a CouchDB database at -http://isaacs.iriscouch.com/registry. The code for the couchapp is -available at http://github.com/isaacs/npmjs.org. npm user accounts -are CouchDB users, stored in the http://isaacs.iriscouch.com/_users -database.

- -

The registry URL is supplied by the registry config parameter. See -config(1) for more on managing npm's configuration.

- -

Can I run my own private registry?

- -

Yes!

- -

The easiest way is to replicate the couch database, and use the same (or -similar) design doc to implement the APIs.

- -

If you set up continuous replication from the official CouchDB, and then -set your internal CouchDB as the registry config, then you'll be able -to read any published packages, in addition to your private ones, and by -default will only publish internally. If you then want to publish a -package for the whole world to see, you can simply override the ---registry config for that command.

- -

I don't want my package published in the official registry. It's private.

- -

Set "private": true in your package.json to prevent it from being -published at all, or -"publishConfig":{"registry":"http://my-internal-registry.local"} -to force it to be published only to your internal registry.

- -

See json(1) for more info on what goes in the package.json file.

- -

Will you replicate from my registry into the public one?

- -

No. If you want things to be public, then publish them into the public -registry using npm. What little security there is would be for nought -otherwise.

- -

Do I have to use couchdb to build a registry that npm can talk to?

- -

No, but it's way easier.

- -

I published something elsewhere, and want to tell the npm registry about it.

- -

That is supported, but not using the npm client. You'll have to get -your hands dirty and do some HTTP. The request looks something like -this:

- -
PUT /my-foreign-package
-content-type:application/json
-accept:application/json
-authorization:Basic $base_64_encoded
-
-{ "name":"my-foreign-package"
-, "maintainers":["owner","usernames"]
-, "description":"A package that is hosted elsewhere"
-, "keywords":["nih","my cheese smells the best"]
-, "url":"http://my-different-registry.com/blerg/my-local-package"
-}
- -

(Keywords and description are optional, but recommended. Name, -maintainers, and url are required.)

- -

Then, when a user tries to install "my-foreign-package", it'll redirect -to your registry. If that doesn't resolve to a valid package entry, -then it'll fail, so please make sure that you understand the spec, and -ask for help on the npm-@googlegroups.com mailing list.

- -

Is there a website or something to see package docs and such?

- -

Yes, head over to https://npmjs.org/

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/removing-npm.html b/deps/npm/html/doc/removing-npm.html deleted file mode 100644 index 66a028ce9..000000000 --- a/deps/npm/html/doc/removing-npm.html +++ /dev/null @@ -1,93 +0,0 @@ - - - removing-npm - - - - -
-

removal

Cleaning the Slate

- -

SYNOPSIS

- -

So sad to see you go.

- -
sudo npm uninstall npm -g
- -

Or, if that fails, get the npm source code, and do:

- -
sudo make uninstall
- -

More Severe Uninstalling

- -

Usually, the above instructions are sufficient. That will remove -npm, but leave behind anything you've installed.

- -

If that doesn't work, or if you require more drastic measures, -continue reading.

- -

Note that this is only necessary for globally-installed packages. Local -installs are completely contained within a project's node_modules -folder. Delete that folder, and everything is gone (unless a package's -install script is particularly ill-behaved).

- -

This assumes that you installed node and npm in the default place. If -you configured node with a different --prefix, or installed npm with a -different prefix setting, then adjust the paths accordingly, replacing -/usr/local with your install prefix.

- -

To remove everything npm-related manually:

- -
rm -rf /usr/local/{lib/node{,/.npm,_modules},bin,share/man}/npm*
- -

If you installed things with npm, then your best bet is to uninstall -them with npm first, and then install them again once you have a -proper install. This can help find any symlinks that are lying -around:

- -
ls -laF /usr/local/{lib/node{,/.npm},bin,share/man} | grep npm
- -

Prior to version 0.3, npm used shim files for executables and node -modules. To track those down, you can do the following:

- -
find /usr/local/{lib/node,bin} -exec grep -l npm \{\} \; ;
- -

(This is also in the README file.)

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/restart.html b/deps/npm/html/doc/restart.html deleted file mode 100644 index 9387434a4..000000000 --- a/deps/npm/html/doc/restart.html +++ /dev/null @@ -1,59 +0,0 @@ - - - restart - - - - -
-

restart

Start a package

- -

SYNOPSIS

- -
npm restart <name>
- -

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.

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/rm.html b/deps/npm/html/doc/rm.html deleted file mode 100644 index bfbb35dca..000000000 --- a/deps/npm/html/doc/rm.html +++ /dev/null @@ -1,57 +0,0 @@ - - - rm - - - - -
-

rm

Remove a package

- -

SYNOPSIS

- -
npm rm <name>
-npm uninstall <name>
- -

DESCRIPTION

- -

This uninstalls a package, completely removing everything npm installed -on its behalf.

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/root.html b/deps/npm/html/doc/root.html deleted file mode 100644 index a3aeb3fb7..000000000 --- a/deps/npm/html/doc/root.html +++ /dev/null @@ -1,55 +0,0 @@ - - - root - - - - -
-

root

Display npm root

- -

SYNOPSIS

- -
npm root
- -

DESCRIPTION

- -

Print the effective node_modules folder to standard out.

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/run-script.html b/deps/npm/html/doc/run-script.html deleted file mode 100644 index 33c8c2fa5..000000000 --- a/deps/npm/html/doc/run-script.html +++ /dev/null @@ -1,58 +0,0 @@ - - - run-script - - - - -
-

run-script

Run arbitrary package scripts

- -

SYNOPSIS

- -
npm run-script <script> <name>
- -

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.

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/scripts.html b/deps/npm/html/doc/scripts.html deleted file mode 100644 index f9ced25b1..000000000 --- a/deps/npm/html/doc/scripts.html +++ /dev/null @@ -1,253 +0,0 @@ - - - scripts - - - - -
-

scripts

How npm handles the "scripts" field

- -

DESCRIPTION

- -

npm supports the "scripts" member of the package.json script, for the -following scripts:

- -
  • prepublish: -Run BEFORE the package is published. (Also run on local npm -install without any arguments.)
  • publish, postpublish: -Run AFTER the package is published.
  • preinstall: -Run BEFORE the package is installed
  • install, postinstall: -Run AFTER the package is installed.
  • preuninstall, uninstall: -Run BEFORE the package is uninstalled.
  • postuninstall: -Run AFTER the package is uninstalled.
  • preupdate: -Run BEFORE the package is updated with the update command.
  • update, postupdate: -Run AFTER the package is updated with the update command.
  • pretest, test, posttest: -Run by the npm test command.
  • prestop, stop, poststop: -Run by the npm stop command.
  • prestart, start, poststart: -Run by the npm start command.
  • prerestart, restart, postrestart: -Run by the npm restart command. Note: npm restart will run the -stop and start scripts if no restart script is provided.
- -

Additionally, arbitrary scrips can be run by doing -npm run-script <stage> <pkg>.

- -

NOTE: INSTALL SCRIPTS ARE AN ANTIPATTERN

- -

tl;dr Don't use install. Use a .gyp file for compilation, and -prepublish for anything else.

- -

You should almost never have to explicitly set a preinstall or -install script. If you are doing this, please consider if there is -another option.

- -

The only valid use of install or preinstall scripts is for -compilation which must be done on the target architecture. In early -versions of node, this was often done using the node-waf scripts, or -a standalone Makefile, and early versions of npm required that it be -explicitly set in package.json. This was not portable, and harder to -do properly.

- -

In the current version of node, the standard way to do this is using a -.gyp file. If you have a file with a .gyp extension in the root -of your package, then npm will run the appropriate node-gyp commands -automatically at install time. This is the only officially supported -method for compiling binary addons, and does not require that you add -anything to your package.json file.

- -

If you have to do other things before your package is used, in a way -that is not dependent on the operating system or architecture of the -target system, then use a prepublish script instead. This includes -tasks such as:

- -
  • Compile CoffeeScript source code into JavaScript.
  • Create minified versions of JavaScript source code.
  • Fetching remote resources that your package will use.
- -

The advantage of doing these things at prepublish time instead of -preinstall or install time is that they can be done once, in a -single place, and thus greatly reduce complexity and variability. -Additionally, this means that:

- -
  • You can depend on coffee-script as a devDependency, and thus -your users don't need to have it installed.
  • You don't need to include the minifiers in your package, reducing -the size for your users.
  • You don't need to rely on your users having curl or wget or -other system tools on the target machines.
- -

DEFAULT VALUES

- -

npm will default some script values based on package contents.

- -

  • "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.

  • "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.

- -

USER

- -

If npm was invoked with root privileges, then it will change the uid to -the user account or uid specified by the user config, which defaults -to nobody. Set the unsafe-perm flag to run scripts with root -privileges.

- -

ENVIRONMENT

- -

Package scripts run in an environment where many pieces of information are -made available regarding the setup of npm and the current state of the -process.

- -

path

- -

If you depend on modules that define executable scripts, like test suites, -then those executables will be added to the PATH for executing the scripts. -So, if your package.json has this:

- -
{ "name" : "foo"
-, "dependencies" : { "bar" : "0.1.x" }
-, "scripts": { "start" : "bar ./test" } }
- -

then you could run npm start to execute the bar script, which is exported -into the node_modules/.bin directory on npm install.

- -

package.json vars

- -

The package.json fields are tacked onto the npm_package_ prefix. So, for -instance, if you had {"name":"foo", "version":"1.2.5"} in your package.json -file, then your package scripts would have the npm_package_name environment -variable set to "foo", and the npm_package_version set to "1.2.5"

- -

configuration

- -

Configuration parameters are put in the environment with the npm_config_ -prefix. For instance, you can view the effective root config by checking the -npm_config_root environment variable.

- -

Special: package.json "config" hash

- -

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

current lifecycle event

- -

Lastly, the npm_lifecycle_event environment variable is set to whichever -stage of the cycle is being executed. So, you could have a single script used -for different parts of the process which switches based on what's currently -happening.

- -

Objects are flattened following this format, so if you had -{"scripts":{"install":"foo.js"}} in your package.json, then you'd see this -in the script:

- -
process.env.npm_package_scripts_install === "foo.js"
- -

EXAMPLES

- -

For example, if your package.json contains this:

- -
{ "scripts" :
-  { "install" : "scripts/install.js"
-  , "postinstall" : "scripts/install.js"
-  , "uninstall" : "scripts/uninstall.js"
-  }
-}
- -

then the scripts/install.js will be called for the install, post-install, -stages of the lifecycle, and the scripts/uninstall.js would be -called when the package is uninstalled. Since scripts/install.js is running -for three different phases, it would be wise in this case to look at the -npm_lifecycle_event environment variable.

- -

If you want to run a make command, you can do so. This works just fine:

- -
{ "scripts" :
-  { "preinstall" : "./configure"
-  , "install" : "make && make install"
-  , "test" : "make test"
-  }
-}
- -

EXITING

- -

Scripts are run by passing the line as a script argument to sh.

- -

If the script exits with a code other than 0, then this will abort the -process.

- -

Note that these script files don't have to be nodejs or even javascript -programs. They just have to be some kind of executable file.

- -

HOOK SCRIPTS

- -

If you want to run a specific script at a specific lifecycle event for ALL -packages, then you can use a hook script.

- -

Place an executable file at node_modules/.hooks/{eventname}, and it'll get -run for all packages when they are going through that point in the package -lifecycle for any packages installed in that root.

- -

Hook scripts are run exactly the same way as package.json scripts. That is, -they are in a separate child process, with the env described above.

- -

BEST PRACTICES

- -
  • Don't exit with a non-zero error code unless you really mean it. -Except for uninstall scripts, this will cause the npm action -to fail, and potentially be rolled back. If the failure is minor or -only will prevent some optional features, then it's better to just -print a warning and exit successfully.
  • Try not to use scripts to do what npm can do for you. Read through -json(1) to see all the things that you can specify and enable -by simply describing your package appropriately. In general, this will -lead to a more robust and consistent state.
  • Inspect the env to determine where to put things. For instance, if -the npm_config_binroot environ is set to /home/user/bin, then don't -try to install executables into /usr/local/bin. The user probably -set it up that way for a reason.
  • Don't prefix your script commands with "sudo". If root permissions are -required for some reason, then it'll fail with that error, and the user -will sudo the npm command in question.
- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/search.html b/deps/npm/html/doc/search.html deleted file mode 100644 index 4f0a55ea0..000000000 --- a/deps/npm/html/doc/search.html +++ /dev/null @@ -1,59 +0,0 @@ - - - search - - - - -
-

search

Search for packages

- -

SYNOPSIS

- -
npm search [search terms ...]
- -

DESCRIPTION

- -

Search the registry for packages matching the search terms.

- -

If a term starts with /, then it's interpreted as a regular expression. -A trailing / will be ignored in this case. (Note that many regular -expression characters must be escaped or quoted in most shells.)

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/semver.html b/deps/npm/html/doc/semver.html deleted file mode 100644 index 64b877880..000000000 --- a/deps/npm/html/doc/semver.html +++ /dev/null @@ -1,139 +0,0 @@ - - - semver - - - - -
-

semver

The semantic versioner for npm

- -

SYNOPSIS

- -

The npm semantic versioning utility.

- -

DESCRIPTION

- -

As a node module:

- -
$ npm install semver
-
-semver.valid('1.2.3') // '1.2.3'
-semver.valid('a.b.c') // null
-semver.clean('  =v1.2.3   ') // '1.2.3'
-semver.satisfies('1.2.3', '1.x || >=2.5.0 || 5.0.0 - 7.2.3') // true
-semver.gt('1.2.3', '9.8.7') // false
-semver.lt('1.2.3', '9.8.7') // true
- -

As a command-line utility:

- -
$ npm install semver -g
-$ semver -h
-
-Usage: semver -v <version> [-r <range>]
-Test if version(s) satisfy the supplied range(s),
-and sort them.
-
-Multiple versions or ranges may be supplied.
-
-Program exits successfully if any valid version satisfies
-all supplied ranges, and prints all satisfying versions.
-
-If no versions are valid, or ranges are not satisfied,
-then exits failure.
-
-Versions are printed in ascending order, so supplying
-multiple versions to the utility will just sort them.
- -

Versions

- -

A version is the following things, in this order:

- -
  • a number (Major)
  • a period
  • a number (minor)
  • a period
  • a number (patch)
  • OPTIONAL: a hyphen, followed by a number (build)
  • OPTIONAL: a collection of pretty much any non-whitespace characters -(tag)
- -

A leading "=" or "v" character is stripped off and ignored.

- -

Comparisons

- -

The ordering of versions is done using the following algorithm, given -two versions and asked to find the greater of the two:

- -
  • If the majors are numerically different, then take the one -with a bigger major number. 2.3.4 > 1.3.4
  • If the minors are numerically different, then take the one -with the bigger minor number. 2.3.4 > 2.2.4
  • If the patches are numerically different, then take the one with the -bigger patch number. 2.3.4 > 2.3.3
  • If only one of them has a build number, then take the one with the -build number. 2.3.4-0 > 2.3.4
  • If they both have build numbers, and the build numbers are numerically -different, then take the one with the bigger build number. -2.3.4-10 > 2.3.4-9
  • If only one of them has a tag, then take the one without the tag. -2.3.4 > 2.3.4-beta
  • If they both have tags, then take the one with the lexicographically -larger tag. 2.3.4-beta > 2.3.4-alpha
  • At this point, they're equal.
- -

Ranges

- -

The following range styles are supported:

- -
  • >1.2.3 Greater than a specific version.
  • <1.2.3 Less than
  • 1.2.3 - 2.3.4 := >=1.2.3 <=2.3.4
  • ~1.2.3 := >=1.2.3 <1.3.0
  • ~1.2 := >=1.2.0 <1.3.0
  • ~1 := >=1.0.0 <2.0.0
  • 1.2.x := >=1.2.0 <1.3.0
  • 1.x := >=1.0.0 <2.0.0
- -

Ranges can be joined with either a space (which implies "and") or a -|| (which implies "or").

- -

Functions

- -
  • valid(v): Return the parsed version, or null if it's not valid.
  • inc(v, release): Return the version incremented by the release type -(major, minor, patch, or build), or null if it's not valid.
- -

Comparison

- -
  • gt(v1, v2): v1 > v2
  • gte(v1, v2): v1 >= v2
  • lt(v1, v2): v1 < v2
  • lte(v1, v2): v1 <= v2
  • eq(v1, v2): v1 == v2 This is true if they're logically equivalent, -even if they're not the exact same string. You already know how to -compare strings.
  • neq(v1, v2): v1 != v2 The opposite of eq.
  • cmp(v1, comparator, v2): Pass in a comparison string, and it'll call -the corresponding function above. "===" and "!==" do simple -string comparison, but are included for completeness. Throws if an -invalid comparison string is provided.
  • compare(v1, v2): Return 0 if v1 == v2, or 1 if v1 is greater, or -1 if -v2 is greater. Sorts in ascending order if passed to Array.sort().
  • rcompare(v1, v2): The reverse of compare. Sorts an array of versions -in descending order when passed to Array.sort().
- -

Ranges

- -
  • validRange(range): Return the valid range or null if it's not valid
  • satisfies(version, range): Return true if the version satisfies the -range.
  • maxSatisfying(versions, range): Return the highest version in the list -that satisfies the range, or null if none of them do.
- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/shrinkwrap.html b/deps/npm/html/doc/shrinkwrap.html deleted file mode 100644 index aacd3bc50..000000000 --- a/deps/npm/html/doc/shrinkwrap.html +++ /dev/null @@ -1,218 +0,0 @@ - - - shrinkwrap - - - - -
-

shrinkwrap

Lock down dependency versions

- -

SYNOPSIS

- -
npm shrinkwrap
- -

DESCRIPTION

- -

This command locks down the versions of a package's dependencies so -that you can control exactly which versions of each dependency will be -used when your package is installed. The "package.json" file is still -required if you want to use "npm install".

- -

By default, "npm install" recursively installs the target's -dependencies (as specified in package.json), choosing the latest -available version that satisfies the dependency's semver pattern. In -some situations, particularly when shipping software where each change -is tightly managed, it's desirable to fully specify each version of -each dependency recursively so that subsequent builds and deploys do -not inadvertently pick up newer versions of a dependency that satisfy -the semver pattern. Specifying specific semver patterns in each -dependency's package.json would facilitate this, but that's not always -possible or desirable, as when another author owns the npm package. -It's also possible to check dependencies directly into source control, -but that may be undesirable for other reasons.

- -

As an example, consider package A:

- -
{
-  "name": "A",
-  "version": "0.1.0",
-  "dependencies": {
-    "B": "<0.1.0"
-  }
-}
- -

package B:

- -
{
-  "name": "B",
-  "version": "0.0.1",
-  "dependencies": {
-    "C": "<0.1.0"
-  }
-}
- -

and package C:

- -
{
-  "name": "C,
-  "version": "0.0.1"
-}
- -

If these are the only versions of A, B, and C available in the -registry, then a normal "npm install A" will install:

- -
A@0.1.0
-`-- B@0.0.1
-    `-- C@0.0.1
- -

However, if B@0.0.2 is published, then a fresh "npm install A" will -install:

- -
A@0.1.0
-`-- B@0.0.2
-    `-- C@0.0.1
- -

assuming the new version did not modify B's dependencies. Of course, -the new version of B could include a new version of C and any number -of new dependencies. If such changes are undesirable, the author of A -could specify a dependency on B@0.0.1. However, if A's author and B's -author are not the same person, there's no way for A's author to say -that he or she does not want to pull in newly published versions of C -when B hasn't changed at all.

- -

In this case, A's author can run

- -
npm shrinkwrap
- -

This generates npm-shrinkwrap.json, which will look something like this:

- -
{
-  "name": "A",
-  "version": "0.1.0",
-  "dependencies": {
-    "B": {
-      "version": "0.0.1",
-      "dependencies": {
-        "C": {
-          "version": "0.1.0"
-        }
-      }
-    }
-  }
-}
- -

The shrinkwrap command has locked down the dependencies based on -what's currently installed in node_modules. When "npm install" -installs a package with a npm-shrinkwrap.json file in the package -root, the shrinkwrap file (rather than package.json files) completely -drives the installation of that package and all of its dependencies -(recursively). So now the author publishes A@0.1.0, and subsequent -installs of this package will use B@0.0.1 and C@0.1.0, regardless the -dependencies and versions listed in A's, B's, and C's package.json -files.

- -

Using shrinkwrapped packages

- -

Using a shrinkwrapped package is no different than using any other -package: you can "npm install" it by hand, or add a dependency to your -package.json file and "npm install" it.

- -

Building shrinkwrapped packages

- -

To shrinkwrap an existing package:

- -
  1. Run "npm install" in the package root to install the current -versions of all dependencies.
  2. Validate that the package works as expected with these versions.
  3. Run "npm shrinkwrap", add npm-shrinkwrap.json to git, and publish -your package.
- -

To add or update a dependency in a shrinkwrapped package:

- -
  1. Run "npm install" in the package root to install the current -versions of all dependencies.
  2. Add or update dependencies. "npm install" each new or updated -package individually and then update package.json. Note that they -must be explicitly named in order to be installed: running npm -install with no arguments will merely reproduce the existing -shrinkwrap.
  3. Validate that the package works as expected with the new -dependencies.
  4. Run "npm shrinkwrap", commit the new npm-shrinkwrap.json, and -publish your package.
- -

You can use outdated(1) to view dependencies with newer versions -available.

- -

Other Notes

- -

A shrinkwrap file must be consistent with the package's package.json -file. "npm shrinkwrap" will fail if required dependencies are not -already installed, since that would result in a shrinkwrap that -wouldn't actually work. Similarly, the command will fail if there are -extraneous packages (not referenced by package.json), since that would -indicate that package.json is not correct.

- -

Since "npm shrinkwrap" is intended to lock down your dependencies for -production use, devDependencies will not be included unless you -explicitly set the --dev flag when you run npm shrinkwrap. If -installed devDependencies are excluded, then npm will print a -warning. If you want them to be installed with your module by -default, please consider adding them to dependencies instead.

- -

If shrinkwrapped package A depends on shrinkwrapped package B, B's -shrinkwrap will not be used as part of the installation of A. However, -because A's shrinkwrap is constructed from a valid installation of B -and recursively specifies all dependencies, the contents of B's -shrinkwrap will implicitly be included in A's shrinkwrap.

- -

Caveats

- -

Shrinkwrap files only lock down package versions, not actual package -contents. While discouraged, a package author can republish an -existing version of a package, causing shrinkwrapped packages using -that version to pick up different code than they were before. If you -want to avoid any risk that a byzantine author replaces a package -you're using with code that breaks your application, you could modify -the shrinkwrap file to use git URL references rather than version -numbers so that npm always fetches all packages from git.

- -

If you wish to lock down the specific bytes included in a package, for -example to have 100% confidence in being able to reproduce a -deployment or build, then you ought to check your dependencies into -source control, or pursue some other mechanism that can verify -contents rather than versions.

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/star.html b/deps/npm/html/doc/star.html deleted file mode 100644 index 223d754e6..000000000 --- a/deps/npm/html/doc/star.html +++ /dev/null @@ -1,61 +0,0 @@ - - - star - - - - -
-

star

Mark your favorite packages

- -

SYNOPSIS

- -
npm star <pkgname> [<pkg>, ...]
-npm unstar <pkgname> [<pkg>, ...]
- -

DESCRIPTION

- -

"Starring" a package means that you have some interest in it. It's -a vaguely positive way to show that you care.

- -

"Unstarring" is the same thing, but in reverse.

- -

It's a boolean thing. Starring repeatedly has no additional effect.

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/stars.html b/deps/npm/html/doc/stars.html deleted file mode 100644 index 98fb54ff6..000000000 --- a/deps/npm/html/doc/stars.html +++ /dev/null @@ -1,60 +0,0 @@ - - - stars - - - - -
-

stars

View packages marked as favorites

- -

SYNOPSIS

- -
npm stars
-npm stars [username]
- -

DESCRIPTION

- -

If you have starred a lot of neat things and want to find them again -quickly this command lets you do just that.

- -

You may also want to see your friend's favorite packages, in this case -you will most certainly enjoy this command.

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/start.html b/deps/npm/html/doc/start.html deleted file mode 100644 index 35e260213..000000000 --- a/deps/npm/html/doc/start.html +++ /dev/null @@ -1,55 +0,0 @@ - - - start - - - - -
-

start

Start a package

- -

SYNOPSIS

- -
npm start <name>
- -

DESCRIPTION

- -

This runs a package's "start" script, if one was provided.

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/stop.html b/deps/npm/html/doc/stop.html deleted file mode 100644 index 614be79c8..000000000 --- a/deps/npm/html/doc/stop.html +++ /dev/null @@ -1,55 +0,0 @@ - - - stop - - - - -
-

stop

Stop a package

- -

SYNOPSIS

- -
npm stop <name>
- -

DESCRIPTION

- -

This runs a package's "stop" script, if one was provided.

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/submodule.html b/deps/npm/html/doc/submodule.html deleted file mode 100644 index 79aaf2296..000000000 --- a/deps/npm/html/doc/submodule.html +++ /dev/null @@ -1,68 +0,0 @@ - - - submodule - - - - -
-

submodule

Add a package as a git submodule

- -

SYNOPSIS

- -
npm submodule <pkg>
- -

DESCRIPTION

- -

If the specified package has a git repository url in its package.json -description, then this command will 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

- - -
- - - diff --git a/deps/npm/html/doc/tag.html b/deps/npm/html/doc/tag.html deleted file mode 100644 index deea37a8c..000000000 --- a/deps/npm/html/doc/tag.html +++ /dev/null @@ -1,56 +0,0 @@ - - - tag - - - - -
-

tag

Tag a published version

- -

SYNOPSIS

- -
npm tag <name>@<version> [<tag>]
- -

DESCRIPTION

- -

Tags the specified version of the package with the specified tag, or the ---tag config if not specified.

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/test.html b/deps/npm/html/doc/test.html deleted file mode 100644 index 22df06de1..000000000 --- a/deps/npm/html/doc/test.html +++ /dev/null @@ -1,58 +0,0 @@ - - - test - - - - -
-

test

Test a package

- -

SYNOPSIS

- -
  npm test <name>
- -

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.

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/uninstall.html b/deps/npm/html/doc/uninstall.html deleted file mode 100644 index 1ad40d48e..000000000 --- a/deps/npm/html/doc/uninstall.html +++ /dev/null @@ -1,57 +0,0 @@ - - - uninstall - - - - -
-

rm

Remove a package

- -

SYNOPSIS

- -
npm rm <name>
-npm uninstall <name>
- -

DESCRIPTION

- -

This uninstalls a package, completely removing everything npm installed -on its behalf.

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/unpublish.html b/deps/npm/html/doc/unpublish.html deleted file mode 100644 index 4500831f5..000000000 --- a/deps/npm/html/doc/unpublish.html +++ /dev/null @@ -1,69 +0,0 @@ - - - unpublish - - - - -
-

unpublish

Remove a package from the registry

- -

SYNOPSIS

- -
npm unpublish <name>[@<version>]
- -

WARNING

- -

It is generally considered bad behavior to remove versions of a library -that others are depending on!

- -

Consider using the deprecate command -instead, if your intent is to encourage users to upgrade.

- -

There is plenty of room on the registry.

- -

DESCRIPTION

- -

This removes a package version from the registry, deleting its -entry and removing the tarball.

- -

If no version is specified, or if all versions are removed then -the root package entry is removed from the registry entirely.

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/update.html b/deps/npm/html/doc/update.html deleted file mode 100644 index 46aec3f74..000000000 --- a/deps/npm/html/doc/update.html +++ /dev/null @@ -1,61 +0,0 @@ - - - update - - - - -
-

update

Update a package

- -

SYNOPSIS

- -
npm update [-g] [<name> [<name> ...]]
- -

DESCRIPTION

- -

This command will update all the packages listed to the latest version -(specified by the tag config).

- -

It will also install missing packages.

- -

If the -g flag is specified, this command will update globally installed packages. -If no package name is specified, all packages in the specified location (global or local) will be updated.

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/version.html b/deps/npm/html/doc/version.html deleted file mode 100644 index 5181ec210..000000000 --- a/deps/npm/html/doc/version.html +++ /dev/null @@ -1,84 +0,0 @@ - - - version - - - - -
-

version

Bump a package version

- -

SYNOPSIS

- -
npm version [<newversion> | major | minor | patch | build]
- -

DESCRIPTION

- -

Run this in a package directory to bump the version and write the new -data back to the package.json file.

- -

The newversion argument should be a valid semver string, or a valid -second argument to semver.inc (one of "build", "patch", "minor", or -"major"). In the second case, the existing version will be incremented -by 1 in the specified field.

- -

If run in a git repo, it will also create a version commit and tag, and -fail if the repo is not clean.

- -

If supplied with --message (shorthand: -m) config option, npm will -use it as a commit message when creating a version commit. If the -message config contains %s then that will be replaced with the -resulting version number. For example:

- -
npm version patch -m "Upgrade to %s for reasons"
- -

If the sign-git-tag config is set, then the tag will be signed using -the -s flag to git. Note that you must have a default GPG key set up -in your git config for this to work properly. For example:

- -
$ npm config set sign-git-tag true
-$ npm version patch
-
-You need a passphrase to unlock the secret key for
-user: "isaacs (http://blog.izs.me/) <i@izs.me>"
-2048-bit RSA key, ID 6C481CF6, created 2010-08-31
-
-Enter passphrase:
- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/view.html b/deps/npm/html/doc/view.html deleted file mode 100644 index 45a2ce257..000000000 --- a/deps/npm/html/doc/view.html +++ /dev/null @@ -1,125 +0,0 @@ - - - view - - - - -
-

view

View registry info

- -

SYNOPSIS

- -
npm view <name>[@<version>] [<field>[.<subfield>]...]
- -

DESCRIPTION

- -

This command shows data about a package and prints it to the stream -referenced by the outfd config, which defaults to stdout.

- -

To show the package registry entry for the connect package, you can do -this:

- -
npm view connect
- -

The default version is "latest" if unspecified.

- -

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 view ronn@0.3.5 dependencies
- -

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 view npm repository.url
- -

This makes it easy to view information about a dependency with a bit of -shell scripting. For example, to view all the data about the version of -opts that ronn depends on, you can do this:

- -
npm view opts@$(npm view ronn dependencies.opts)
- -

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 view express contributors.email
- -

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 view express contributors[0].email
- -

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 view express contributors.name contributors.email
- -

"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 json(1) for more on this.)

- -
npm view npm contributors
- -

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 view yui3@'>0.5.4' dependencies.jsdom
- -

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 field is an object, it will be output as a JavaScript object literal.

- -

If the --json flag is given, the outputted fields will be JSON.

- -

If the version range matches multiple versions, than each printed value -will be prefixed with the version it applies to.

- -

If multiple fields are requested, than each of them are prefixed with -the field name.

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/doc/whoami.html b/deps/npm/html/doc/whoami.html deleted file mode 100644 index 873af3721..000000000 --- a/deps/npm/html/doc/whoami.html +++ /dev/null @@ -1,55 +0,0 @@ - - - whoami - - - - -
-

whoami

Display npm username

- -

SYNOPSIS

- -
npm whoami
- -

DESCRIPTION

- -

Print the username config to standard output.

- -

SEE ALSO

- - -
- - - diff --git a/deps/npm/html/docfoot-script.html b/deps/npm/html/docfoot-script.html new file mode 100644 index 000000000..c0fea672a --- /dev/null +++ b/deps/npm/html/docfoot-script.html @@ -0,0 +1,31 @@ + diff --git a/deps/npm/html/docfoot.html b/deps/npm/html/docfoot.html index 3e35341cc..237b89718 100644 --- a/deps/npm/html/docfoot.html +++ b/deps/npm/html/docfoot.html @@ -1,34 +1,2 @@ - - diff --git a/deps/npm/html/dochead.html b/deps/npm/html/dochead.html index 1526e1b7b..01f4d2f05 100644 --- a/deps/npm/html/dochead.html +++ b/deps/npm/html/dochead.html @@ -2,7 +2,7 @@ @NAME@ - +
diff --git a/deps/npm/lib/build.js b/deps/npm/lib/build.js index fdbae722c..176022559 100644 --- a/deps/npm/lib/build.js +++ b/deps/npm/lib/build.js @@ -202,17 +202,12 @@ function linkMans (pkg, folder, parent, gtop, cb) { var manRoot = path.resolve(npm.config.get("prefix"), "share", "man") asyncMap(pkg.man, function (man, cb) { if (typeof man !== "string") return cb() - var parseMan = man.match(/(.*)\.([0-9]+)(\.gz)?$/) + var parseMan = man.match(/(.*\.([0-9]+)(\.gz)?)$/) , stem = parseMan[1] , sxn = parseMan[2] , gz = parseMan[3] || "" , bn = path.basename(stem) - , manDest = path.join( manRoot - , "man"+sxn - , (bn.indexOf(pkg.name) === 0 ? bn - : pkg.name + "-" + bn) - + "." + sxn + gz - ) + , manDest = path.join(manRoot, "man" + sxn, bn) linkIfExists(man, manDest, gtop && folder, cb) }, cb) diff --git a/deps/npm/lib/cache.js b/deps/npm/lib/cache.js index 3501b69b9..313a4f0c6 100644 --- a/deps/npm/lib/cache.js +++ b/deps/npm/lib/cache.js @@ -1173,7 +1173,7 @@ function unpack (pkg, ver, unpackTarget, dMode, fMode, uid, gid, cb) { log.error("unpack", "Could not read data for %s", pkg + "@" + ver) return cb(er) } - npm.commands.unbuild([unpackTarget], function (er) { + npm.commands.unbuild([unpackTarget], true, function (er) { if (er) return cb(er) tar.unpack( path.join(npm.cache, pkg, ver, "package.tgz") , unpackTarget diff --git a/deps/npm/lib/help-search.js b/deps/npm/lib/help-search.js index b0b15baca..590fe270b 100644 --- a/deps/npm/lib/help-search.js +++ b/deps/npm/lib/help-search.js @@ -8,6 +8,7 @@ var fs = require("graceful-fs") , apiDocsPath = path.join(__dirname, "..", "doc", "api") , log = require("npmlog") , npm = require("./npm.js") + , glob = require("glob") helpSearch.usage = "npm help-search " @@ -17,177 +18,199 @@ function helpSearch (args, silent, cb) { // see if we're actually searching the api docs. var argv = npm.config.get("argv").cooked - , docsPath = cliDocsPath - , cmd = "help" - if (argv.length && argv[0].indexOf("api") !== -1) { - docsPath = apiDocsPath - cmd = "apihelp" - } - fs.readdir(docsPath, function(er, files) { - if (er) { - log.error("helpSearch", "Could not load documentation") + var docPath = path.resolve(__dirname, "..", "doc") + return glob(docPath + "/*/*.md", function (er, files) { + if (er) return cb(er) - } - - var search = args.join(" ") - , results = [] - asyncMap(files, function (file, cb) { - fs.lstat(path.resolve(docsPath, file), function (er, st) { - if (er) return cb(er) - if (!st.isFile()) return cb(null, []) - - fs.readFile(path.resolve(docsPath, file), "utf8", function (er, data) { - if (er) return cb(er) - - var match = false - for (var a = 0, l = args.length; a < l && !match; a ++) { - match = data.toLowerCase().indexOf(args[a].toLowerCase()) !== -1 - } - if (!match) return cb(null, []) - - var lines = data.split(/\n+/) - , context = [] - - // if a line has a search term, then skip it and the next line. - // if the next line has a search term, then skip all 3 - // otherwise, set the line to null. - for (var i = 0, l = lines.length; i < l; i ++) { - var line = lines[i] - , nextLine = lines[i + 1] - , match = false - if (nextLine) { - for (var a = 0, ll = args.length; a < ll && !match; a ++) { - match = nextLine.toLowerCase() - .indexOf(args[a].toLowerCase()) !== -1 - } - if (match) { - // skip over the next line, and the line after it. - i += 2 - continue - } - } - - match = false - for (var a = 0, ll = args.length; a < ll && !match; a ++) { - match = line.toLowerCase().indexOf(args[a].toLowerCase()) !== -1 - } - if (match) { - // skip over the next line - i ++ - continue - } - - lines[i] = null - } - - // now squish any string of nulls into a single null - lines = lines.reduce(function (l, r) { - if (!(r === null && l[l.length-1] === null)) l.push(r) - return l - }, []) - - if (lines[lines.length - 1] === null) lines.pop() - if (lines[0] === null) lines.shift() - - // now see how many args were found at all. - var found = {} - , totalHits = 0 - lines.forEach(function (line) { - args.forEach(function (arg) { - var hit = (line || "").toLowerCase() - .split(arg.toLowerCase()).length - 1 - if (hit > 0) { - found[arg] = (found[arg] || 0) + hit - totalHits += hit - } - }) - }) - - return cb(null, { file: file, lines: lines, found: Object.keys(found) - , hits: found, totalHits: totalHits }) - }) + readFiles(files, function (er, data) { + if (er) + return cb(er) + searchFiles(args, data, function (er, results) { + if (er) + return cb(er) + formatResults(args, results, cb) }) - }, function (er, results) { - if (er) return cb(er) + }) + }) +} - // if only one result, then just show that help section. - if (results.length === 1) { - return npm.commands.help([results[0].file.replace(/\.md$/, "")], cb) +function readFiles (files, cb) { + var res = {} + asyncMap(files, function (file, cb) { + fs.readFile(file, 'utf8', function (er, data) { + res[file] = data + return cb(er) + }) + }, function (er) { + return cb(er, res) + }) +} + +function searchFiles (args, files, cb) { + var results = [] + Object.keys(files).forEach(function (file) { + var data = files[file] + + // skip if no matches at all + for (var a = 0, l = args.length; a < l && !match; a++) { + var match = data.toLowerCase().indexOf(args[a].toLowerCase()) !== -1 + } + if (!match) + return + + var lines = data.split(/\n+/) + var context = [] + + // if a line has a search term, then skip it and the next line. + // if the next line has a search term, then skip all 3 + // otherwise, set the line to null. then remove the nulls. + for (var i = 0, l = lines.length; i < l; i ++) { + var line = lines[i] + , nextLine = lines[i + 1] + , match = false + if (nextLine) { + for (var a = 0, ll = args.length; a < ll && !match; a ++) { + match = nextLine.toLowerCase() + .indexOf(args[a].toLowerCase()) !== -1 + } + if (match) { + // skip over the next line, and the line after it. + i += 2 + continue + } } - if (results.length === 0) { - console.log("No results for " + args.map(JSON.stringify).join(" ")) - return cb() + match = false + for (var a = 0, ll = args.length; a < ll && !match; a ++) { + match = line.toLowerCase().indexOf(args[a].toLowerCase()) !== -1 + } + if (match) { + // skip over the next line + i ++ + continue } - // sort results by number of results found, then by number of hits - // then by number of matching lines - results = results.sort(function (a, b) { - return a.found.length > b.found.length ? -1 - : a.found.length < b.found.length ? 1 - : a.totalHits > b.totalHits ? -1 - : a.totalHits < b.totalHits ? 1 - : a.lines.length > b.lines.length ? -1 - : a.lines.length < b.lines.length ? 1 - : 0 + lines[i] = null + } + + // now squish any string of nulls into a single null + lines = lines.reduce(function (l, r) { + if (!(r === null && l[l.length-1] === null)) l.push(r) + return l + }, []) + + if (lines[lines.length - 1] === null) lines.pop() + if (lines[0] === null) lines.shift() + + // now see how many args were found at all. + var found = {} + , totalHits = 0 + lines.forEach(function (line) { + args.forEach(function (arg) { + var hit = (line || "").toLowerCase() + .split(arg.toLowerCase()).length - 1 + if (hit > 0) { + found[arg] = (found[arg] || 0) + hit + totalHits += hit + } }) + }) - var out = results.map(function (res, i, results) { - var out = "npm " + cmd + " "+res.file.replace(/\.md$/, "") - , r = Object.keys(res.hits).map(function (k) { - return k + ":" + res.hits[k] - }).sort(function (a, b) { - return a > b ? 1 : -1 - }).join(" ") - - out += ((new Array(Math.max(1, 81 - out.length - r.length))) - .join (" ")) + r - - if (!npm.config.get("long")) return out - - var out = "\n\n" + out - + "\n" + (new Array(81)).join("—") + "\n" - + res.lines.map(function (line, i) { - if (line === null || i > 3) return "" - for (var out = line, a = 0, l = args.length; a < l; a ++) { - var finder = out.toLowerCase().split(args[a].toLowerCase()) - , newOut = [] - , p = 0 - finder.forEach(function (f) { - newOut.push( out.substr(p, f.length) - , "\1" - , out.substr(p + f.length, args[a].length) - , "\2" ) - p += f.length + args[a].length - }) - out = newOut.join("") - } - if (npm.color) { - var color = "\033[31;40m" - , reset = "\033[0m" - } else { - var color = "" - , reset = "" - } - out = out.split("\1").join(color) - .split("\2").join(reset) - return out - }).join("\n").trim() - return out - }).join("\n") - - if (results.length && !npm.config.get("long")) { - out = "Top hits for "+(args.map(JSON.stringify).join(" ")) - + "\n" + (new Array(81)).join("—") + "\n" - + out - + "\n" + (new Array(81)).join("—") + "\n" - + "(run with -l or --long to see more context)" - } + var cmd = "npm help " + if (path.basename(path.dirname(file)) === "api") { + cmd = "npm apihelp " + } + cmd += path.basename(file, ".md").replace(/^npm-/, "") + results.push({ file: file + , cmd: cmd + , lines: lines + , found: Object.keys(found) + , hits: found + , totalHits: totalHits + }) + }) - console.log(out.trim()) - cb(null, results) - }) + // if only one result, then just show that help section. + if (results.length === 1) { + return npm.commands.help([results[0].file.replace(/\.md$/, "")], cb) + } + + if (results.length === 0) { + console.log("No results for " + args.map(JSON.stringify).join(" ")) + return cb() + } + // sort results by number of results found, then by number of hits + // then by number of matching lines + results = results.sort(function (a, b) { + return a.found.length > b.found.length ? -1 + : a.found.length < b.found.length ? 1 + : a.totalHits > b.totalHits ? -1 + : a.totalHits < b.totalHits ? 1 + : a.lines.length > b.lines.length ? -1 + : a.lines.length < b.lines.length ? 1 + : 0 }) + + cb(null, results) +} + +function formatResults (args, results, cb) { + var cols = Math.min(process.stdout.columns || Infinity, 80) + 1 + + var out = results.map(function (res, i, results) { + var out = res.cmd + , r = Object.keys(res.hits).map(function (k) { + return k + ":" + res.hits[k] + }).sort(function (a, b) { + return a > b ? 1 : -1 + }).join(" ") + + out += ((new Array(Math.max(1, cols - out.length - r.length))) + .join (" ")) + r + + if (!npm.config.get("long")) return out + + var out = "\n\n" + out + + "\n" + (new Array(cols)).join("—") + "\n" + + res.lines.map(function (line, i) { + if (line === null || i > 3) return "" + for (var out = line, a = 0, l = args.length; a < l; a ++) { + var finder = out.toLowerCase().split(args[a].toLowerCase()) + , newOut = [] + , p = 0 + finder.forEach(function (f) { + newOut.push( out.substr(p, f.length) + , "\1" + , out.substr(p + f.length, args[a].length) + , "\2" ) + p += f.length + args[a].length + }) + out = newOut.join("") + } + if (npm.color) { + var color = "\033[31;40m" + , reset = "\033[0m" + } else { + var color = "" + , reset = "" + } + out = out.split("\1").join(color) + .split("\2").join(reset) + return out + }).join("\n").trim() + return out + }).join("\n") + + if (results.length && !npm.config.get("long")) { + out = "Top hits for "+(args.map(JSON.stringify).join(" ")) + + "\n" + (new Array(cols)).join("—") + "\n" + + out + + "\n" + (new Array(cols)).join("—") + "\n" + + "(run with -l or --long to see more context)" + } + + console.log(out.trim()) + cb(null, results) } diff --git a/deps/npm/lib/help.js b/deps/npm/lib/help.js index 8faef1c2c..f522763db 100644 --- a/deps/npm/lib/help.js +++ b/deps/npm/lib/help.js @@ -3,9 +3,7 @@ module.exports = help help.completion = function (opts, cb) { if (opts.conf.argv.remain.length > 2) return cb(null, []) - var num = 1 - if (-1 !== opts.conf.argv.remain[1].indexOf("api")) num = 3 - getSections(num, cb) + getSections(cb) } var fs = require("graceful-fs") @@ -14,94 +12,165 @@ var fs = require("graceful-fs") , npm = require("./npm.js") , log = require("npmlog") , opener = require("opener") + , glob = require("glob") function help (args, cb) { - var num = 1 - , argv = npm.config.get("argv").cooked - if (argv.length && -1 !== argv[0].indexOf("api")) { - num = 3 + var argv = npm.config.get("argv").cooked + + var argnum = 0 + if (args.length === 2 && ~~args[0]) { + argnum = ~~args.shift() } + // npm help foo bar baz: search topics if (args.length > 1 && args[0]) { return npm.commands["help-search"](args, num, cb) } var section = npm.deref(args[0]) || args[0] - if (section) { - if ( npm.config.get("usage") - && npm.commands[section] - && npm.commands[section].usage - ) { - npm.config.set("loglevel", "silent") - log.level = "silent" - console.log(npm.commands[section].usage) - return cb() - } - - var sectionPath = path.join( __dirname, "..", "man", "man" + num - , section + "." + num) - , htmlPath = path.resolve( __dirname, "..", "html" - , num === 3 ? "api" : "doc" - , section+".html" ) - return fs.stat - ( sectionPath - , function (e, o) { - if (e) return npm.commands["help-search"](args, cb) - - var manpath = path.join(__dirname, "..", "man") - , env = {} - Object.keys(process.env).forEach(function (i) { - env[i] = process.env[i] - }) - env.MANPATH = manpath - var viewer = npm.config.get("viewer") - - switch (viewer) { - case "woman": - var a = ["-e", "(woman-find-file \"" + sectionPath + "\")"] - var conf = { env: env, customFds: [ 0, 1, 2] } - var woman = spawn("emacsclient", a, conf) - woman.on("close", cb) - break - - case "browser": - opener(htmlPath, { command: npm.config.get("browser") }, cb) - break - - default: - var conf = { env: env, customFds: [ 0, 1, 2] } - var man = spawn("man", [num, section], conf) - man.on("close", cb) - } - } - ) - } else getSections(function (er, sections) { - if (er) return cb(er) + // npm help : show basic usage + if (!section) + return npmUsage(cb) + + // npm -h: show command usage + if ( npm.config.get("usage") + && npm.commands[section] + && npm.commands[section].usage + ) { npm.config.set("loglevel", "silent") log.level = "silent" - console.log - ( ["\nUsage: npm " - , "" - , "where is one of:" - , npm.config.get("long") ? usages() - : " " + wrap(Object.keys(npm.commands)) - , "" - , "npm -h quick help on " - , "npm -l display full usage info" - , "npm faq commonly asked questions" - , "npm help search for help on " - , "npm help npm involved overview" - , "" - , "Specify configs in the ini-formatted file:" - , " " + npm.config.get("userconfig") - , "or on the command line via: npm --key value" - , "Config info can be viewed via: npm help config" - , "" - , "npm@" + npm.version + " " + path.dirname(__dirname) - ].join("\n")) - cb(er) + console.log(npm.commands[section].usage) + return cb() + } + + // npm apihelp
: Prefer section 3 over section 1 + var apihelp = argv.length && -1 !== argv[0].indexOf("api") + var pref = apihelp ? [3, 1, 5, 7] : [1, 3, 5, 7] + if (argnum) + pref = [ argnum ].concat(pref.filter(function (n) { + return n !== argnum + })) + + // npm help
: Try to find the path + var manroot = path.resolve(__dirname, "..", "man") + var htmlroot = path.resolve(__dirname, "..", "html", "doc") + + // legacy + if (section === "global") + section = "folders" + else if (section === "json") + section = "package.json" + + // find either /section.n or /npm-section.n + var f = "+(npm-" + section + "|" + section + ").[0-9]" + return glob(manroot + "/*/" + f, function (er, mans) { + if (er) + return cb(er) + + if (!mans.length) + return npm.commands["help-search"](args, cb) + + viewMan(pickMan(mans, pref), cb) + }) +} + +function pickMan (mans, pref_) { + var nre = /([0-9]+)$/ + var pref = {} + pref_.forEach(function (sect, i) { + pref[sect] = i + }) + mans = mans.sort(function (a, b) { + var an = a.match(nre)[1] + var bn = b.match(nre)[1] + return an === bn ? (a > b ? -1 : 1) + : pref[an] < pref[bn] ? -1 + : 1 + }) + return mans[0] +} + +function viewMan (man, cb) { + var nre = /([0-9]+)$/ + var num = man.match(nre)[1] + var section = path.basename(man, "." + num) + + // at this point, we know that the specified man page exists + var manpath = path.join(__dirname, "..", "man") + , env = {} + Object.keys(process.env).forEach(function (i) { + env[i] = process.env[i] }) + env.MANPATH = manpath + var viewer = npm.config.get("viewer") + + switch (viewer) { + case "woman": + var a = ["-e", "(woman-find-file \"" + man + "\")"] + var conf = { env: env, customFds: [ 0, 1, 2] } + var woman = spawn("emacsclient", a, conf) + woman.on("close", cb) + break + + case "browser": + opener(htmlMan(man), { command: npm.config.get("browser") }, cb) + break + + default: + var conf = { env: env, customFds: [ 0, 1, 2] } + var man = spawn("man", [num, section], conf) + man.on("close", cb) + break + } +} + +function htmlMan (man) { + var sect = +man.match(/([0-9]+)$/)[1] + var f = path.basename(man).replace(/([0-9]+)$/, "html") + switch (sect) { + case 1: + sect = "cli" + break + case 3: + sect = "api" + break + case 5: + sect = "files" + break + case 7: + sect = "misc" + break + default: + throw new Error("invalid man section: " + sect) + } + return path.resolve(__dirname, "..", "html", "doc", sect, f) +} + +function npmUsage (cb) { + npm.config.set("loglevel", "silent") + log.level = "silent" + console.log + ( ["\nUsage: npm " + , "" + , "where is one of:" + , npm.config.get("long") ? usages() + : " " + wrap(Object.keys(npm.commands)) + , "" + , "npm -h quick help on " + , "npm -l display full usage info" + , "npm faq commonly asked questions" + , "npm help search for help on " + , "npm help npm involved overview" + , "" + , "Specify configs in the ini-formatted file:" + , " " + npm.config.get("userconfig") + , "or on the command line via: npm --key value" + , "Config info can be viewed via: npm help config" + , "" + , "npm@" + npm.version + " " + path.dirname(__dirname) + ].join("\n")) + cb() } function usages () { @@ -127,9 +196,17 @@ function usages () { function wrap (arr) { var out = [''] , l = 0 + , line + + line = process.stdout.columns + if (!line) + line = 60 + else + line = Math.min(60, Math.max(line - 16, 24)) + arr.sort(function (a,b) { return a \fR\|\. (This is helpful -for testing, or running stuff without actually installing npm itself\.) -. -.SH "Fancy Windows Install" -You can download a zip file from \fIhttps://npmjs\.org/dist/\fR, and unpack it -in the same folder where node\.exe lives\. -. -.P -If that\'s not fancy enough for you, then you can fetch the code with -git, and mess with it directly\. -. -.SH "Installing on Cygwin" -No\. -. -.SH "Permissions when Using npm to Install Other Stuff" -\fBtl;dr\fR -. -.IP "\(bu" 4 -Use \fBsudo\fR for greater safety\. Or don\'t, if you prefer not to\. -. -.IP "\(bu" 4 -npm will downgrade permissions if it\'s root before running any build -scripts that package authors specified\. -. -.IP "" 0 -. -.SS "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 \fBnobody\fR user prior -to running any package build or test commands\. -. -.P -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\. -. -.P -If you would like to ensure that npm \fBalways\fR runs scripts as the -"nobody" user, and have it fail if it cannot downgrade permissions, then -set the following configuration param: -. -.IP "" 4 -. -.nf -npm config set unsafe\-perm false -. -.fi -. -.IP "" 0 -. -.P -This will prevent running in unsafe mode, even as non\-root users\. -. -.SH "Uninstalling" -So sad to see you go\. -. -.IP "" 4 -. -.nf -sudo npm uninstall npm \-g -. -.fi -. -.IP "" 0 -. -.P -Or, if that fails, -. -.IP "" 4 -. -.nf -sudo make uninstall -. -.fi -. -.IP "" 0 -. -.SH "More Severe Uninstalling" -Usually, the above instructions are sufficient\. That will remove -npm, but leave behind anything you\'ve installed\. -. -.P -If you would like to remove all the packages that you have installed, -then you can use the \fBnpm ls\fR command to find them, and then \fBnpm rm\fR to -remove them\. -. -.P -To remove cruft left behind by npm 0\.x, you can use the included \fBclean\-old\.sh\fR script file\. You can run it conveniently like this: -. -.IP "" 4 -. -.nf -npm explore npm \-g \-\- sh scripts/clean\-old\.sh -. -.fi -. -.IP "" 0 -. -.P -npm uses two configuration files, one for per\-user configs, and another -for global (every\-user) configs\. You can view them by doing: -. -.IP "" 4 -. -.nf -npm config get userconfig # defaults to ~/\.npmrc -npm config get globalconfig # defaults to /usr/local/etc/npmrc -. -.fi -. -.IP "" 0 -. -.P -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\. -. -.SH "Using npm Programmatically" -If you would like to use npm programmatically, you can do that\. -It\'s not very well documented, but it \fIis\fR rather simple\. -. -.P -Most of the time, unless you actually want to do all the things that -npm does, you should try using one of npm\'s dependencies rather than -using npm itself, if possible\. -. -.P -Eventually, npm will be just a thin cli wrapper around the modules -that it depends on, but for now, there are some things that you must -use npm itself to do\. -. -.IP "" 4 -. -.nf -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) { \.\.\.\. }) -}) -. -.fi -. -.IP "" 0 -. -.P -The \fBload\fR function takes an object hash of the command\-line configs\. -The various \fBnpm\.commands\.\fR functions take an \fBarray\fR of -positional argument \fBstrings\fR\|\. The last argument to any \fBnpm\.commands\.\fR function is a callback\. Some commands take other -optional arguments\. Read the source\. -. -.P -You cannot set configs individually for any single npm function at this -time\. Since \fBnpm\fR is a singleton, any call to \fBnpm\.config\.set\fR will -change the value for \fIall\fR npm commands in that process\. -. -.P -See \fB\|\./bin/npm\-cli\.js\fR for an example of pulling config values off of the -command line arguments using nopt\. You may also want to check out \fBnpm -help config\fR to learn about all the options you can set there\. -. -.SH "More Docs" -Check out the docs \fIhttps://npmjs\.org/doc/\fR, -especially the faq \fIhttps://npmjs\.org/doc/faq\.html\fR\|\. -. -.P -You can use the \fBnpm help\fR command to read any of them\. -. -.P -If you\'re a developer, and you want to use npm to publish your program, -you should read this \fIhttps://npmjs\.org/doc/developers\.html\fR -. -.SH "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\. -. -.P -"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\. -. -.P -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\. -. -.P -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 \fIi@izs\.me\fR\|\. -. -.SS "In plain english" -This is mine; not my employer\'s, not Node\'s, not Joyent\'s, not Ryan -Dahl\'s\. -. -.P -If you publish something, it\'s yours, and you are solely accountable -for it\. Not me, not Node, not Joyent, not Ryan Dahl\. -. -.P -If other people publish something, it\'s theirs\. Not mine, not Node\'s, -not Joyent\'s, not Ryan Dahl\'s\. -. -.P -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\. -. -.P -If this concerns you, inspect the source before using packages\. -. -.SH "BUGS" -When you find issues, please report them: -. -.IP "\(bu" 4 -web: \fIhttps://github\.com/isaacs/npm/issues\fR -. -.IP "\(bu" 4 -email: \fInpm\-@googlegroups\.com\fR -. -.IP "" 0 -. -.P -Be sure to include \fIall\fR of the output from the npm command that didn\'t work -as expected\. The \fBnpm\-debug\.log\fR file is also helpful to provide\. -. -.P -You can also look for isaacs in #node\.js on irc://irc\.freenode\.net\. He -will no doubt tell you to put the output in a gist or email\. -. -.SH "SEE ALSO" -. -.IP "\(bu" 4 -npm help npm -. -.IP "\(bu" 4 -npm help faq -. -.IP "\(bu" 4 -npm help help -. -.IP "\(bu" 4 -npm help index -. -.IP "" 0 - diff --git a/deps/npm/man/man1/adduser.1 b/deps/npm/man/man1/adduser.1 deleted file mode 100644 index 788d1031b..000000000 --- a/deps/npm/man/man1/adduser.1 +++ /dev/null @@ -1,57 +0,0 @@ -.\" Generated with Ronnjs 0.3.8 -.\" http://github.com/kapouer/ronnjs/ -. -.TH "NPM\-ADDUSER" "1" "July 2013" "" "" -. -.SH "NAME" -\fBnpm-adduser\fR \-\- Add a registry user account -. -.SH "SYNOPSIS" -. -.nf -npm adduser -. -.fi -. -.SH "DESCRIPTION" -Create or verify a user named \fB\fR in the npm registry, and -save the credentials to the \fB\|\.npmrc\fR file\. -. -.P -The username, password, and email are read in from prompts\. -. -.P -You may use this command to change your email address, but not username -or password\. -. -.P -To reset your password, go to \fIhttp://admin\.npmjs\.org/\fR -. -.P -You may use this command multiple times with the same user account to -authorize on a new machine\. -. -.SH "CONFIGURATION" -. -.SS "registry" -Default: http://registry\.npmjs\.org/ -. -.P -The base URL of the npm package registry\. -. -.SH "SEE ALSO" -. -.IP "\(bu" 4 -npm help registry -. -.IP "\(bu" 4 -npm help config -. -.IP "\(bu" 4 -npm help owner -. -.IP "\(bu" 4 -npm help whoami -. -.IP "" 0 - diff --git a/deps/npm/man/man1/author.1 b/deps/npm/man/man1/author.1 deleted file mode 100644 index 6373c3ee4..000000000 --- a/deps/npm/man/man1/author.1 +++ /dev/null @@ -1,55 +0,0 @@ -.\" Generated with Ronnjs/v0.1 -.\" http://github.com/kapouer/ronnjs/ -. -.TH "NPM\-OWNER" "1" "November 2011" "" "" -. -.SH "NAME" -\fBnpm-owner\fR \-\- Manage package owners -. -.SH "SYNOPSIS" -. -.nf -npm owner ls -npm owner add -npm owner rm -. -.fi -. -.SH "DESCRIPTION" -Manage ownership of published packages\. -. -.IP "\(bu" 4 -ls: -List all the users who have access to modify a package and push new versions\. -Handy when you need to know who to bug for help\. -. -.IP "\(bu" 4 -add: -Add a new user as a maintainer of a package\. This user is enabled to modify -metadata, publish new versions, and add other owners\. -. -.IP "\(bu" 4 -rm: -Remove a user from the package owner list\. This immediately revokes their -privileges\. -. -.IP "" 0 -. -.P -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\. -. -.SH "SEE ALSO" -. -.IP "\(bu" 4 -npm help publish -. -.IP "\(bu" 4 -npm help registry -. -.IP "\(bu" 4 -npm help adduser -. -.IP "" 0 - diff --git a/deps/npm/man/man1/bin.1 b/deps/npm/man/man1/bin.1 deleted file mode 100644 index 53aba3715..000000000 --- a/deps/npm/man/man1/bin.1 +++ /dev/null @@ -1,34 +0,0 @@ -.\" Generated with Ronnjs 0.3.8 -.\" http://github.com/kapouer/ronnjs/ -. -.TH "NPM\-BIN" "1" "July 2013" "" "" -. -.SH "NAME" -\fBnpm-bin\fR \-\- Display npm bin folder -. -.SH "SYNOPSIS" -. -.nf -npm bin -. -.fi -. -.SH "DESCRIPTION" -Print the folder where npm will install executables\. -. -.SH "SEE ALSO" -. -.IP "\(bu" 4 -npm help prefix -. -.IP "\(bu" 4 -npm help root -. -.IP "\(bu" 4 -npm help folders -. -.IP "\(bu" 4 -npm help config -. -.IP "" 0 - diff --git a/deps/npm/man/man1/bugs.1 b/deps/npm/man/man1/bugs.1 deleted file mode 100644 index 56898405c..000000000 --- a/deps/npm/man/man1/bugs.1 +++ /dev/null @@ -1,70 +0,0 @@ -.\" Generated with Ronnjs 0.3.8 -.\" http://github.com/kapouer/ronnjs/ -. -.TH "NPM\-BUGS" "1" "July 2013" "" "" -. -.SH "NAME" -\fBnpm-bugs\fR \-\- Bugs for a package in a web browser maybe -. -.SH "SYNOPSIS" -. -.nf -npm bugs -. -.fi -. -.SH "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 \fB\-\-browser\fR -config param\. -. -.SH "CONFIGURATION" -. -.SS "browser" -. -.IP "\(bu" 4 -Default: OS X: \fB"open"\fR, Windows: \fB"start"\fR, Others: \fB"xdg\-open"\fR -. -.IP "\(bu" 4 -Type: String -. -.IP "" 0 -. -.P -The browser that is called by the \fBnpm bugs\fR command to open websites\. -. -.SS "registry" -. -.IP "\(bu" 4 -Default: https://registry\.npmjs\.org/ -. -.IP "\(bu" 4 -Type: url -. -.IP "" 0 -. -.P -The base URL of the npm package registry\. -. -.SH "SEE ALSO" -. -.IP "\(bu" 4 -npm help docs -. -.IP "\(bu" 4 -npm help view -. -.IP "\(bu" 4 -npm help publish -. -.IP "\(bu" 4 -npm help registry -. -.IP "\(bu" 4 -npm help config -. -.IP "\(bu" 4 -npm help json -. -.IP "" 0 - diff --git a/deps/npm/man/man1/build.1 b/deps/npm/man/man1/build.1 deleted file mode 100644 index 034850dcd..000000000 --- a/deps/npm/man/man1/build.1 +++ /dev/null @@ -1,43 +0,0 @@ -.\" Generated with Ronnjs 0.3.8 -.\" http://github.com/kapouer/ronnjs/ -. -.TH "NPM\-BUILD" "1" "July 2013" "" "" -. -.SH "NAME" -\fBnpm-build\fR \-\- Build a package -. -.SH "SYNOPSIS" -. -.nf -npm build -. -.fi -. -.IP "\(bu" 4 -\fB\fR: -A folder containing a \fBpackage\.json\fR file in its root\. -. -.IP "" 0 -. -.SH "DESCRIPTION" -This is the plumbing command called by \fBnpm link\fR and \fBnpm install\fR\|\. -. -.P -It should generally not be called directly\. -. -.SH "SEE ALSO" -. -.IP "\(bu" 4 -npm help install -. -.IP "\(bu" 4 -npm help link -. -.IP "\(bu" 4 -npm help scripts -. -.IP "\(bu" 4 -npm help json -. -.IP "" 0 - diff --git a/deps/npm/man/man1/bundle.1 b/deps/npm/man/man1/bundle.1 deleted file mode 100644 index 880d23f9d..000000000 --- a/deps/npm/man/man1/bundle.1 +++ /dev/null @@ -1,23 +0,0 @@ -.\" Generated with Ronnjs 0.3.8 -.\" http://github.com/kapouer/ronnjs/ -. -.TH "NPM\-BUNDLE" "1" "July 2013" "" "" -. -.SH "NAME" -\fBnpm-bundle\fR \-\- REMOVED -. -.SH "DESCRIPTION" -The \fBnpm bundle\fR 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\. -. -.P -Just use \fBnpm install\fR now to do what \fBnpm bundle\fR used to do\. -. -.SH "SEE ALSO" -. -.IP "\(bu" 4 -npm help install -. -.IP "" 0 - diff --git a/deps/npm/man/man1/cache.1 b/deps/npm/man/man1/cache.1 deleted file mode 100644 index 82ceb4a11..000000000 --- a/deps/npm/man/man1/cache.1 +++ /dev/null @@ -1,97 +0,0 @@ -.\" Generated with Ronnjs 0.3.8 -.\" http://github.com/kapouer/ronnjs/ -. -.TH "NPM\-CACHE" "1" "July 2013" "" "" -. -.SH "NAME" -\fBnpm-cache\fR \-\- Manipulates packages cache -. -.SH "SYNOPSIS" -. -.nf -npm cache add -npm cache add -npm cache add -npm cache add @ -npm cache ls [] -npm cache clean [] -. -.fi -. -.SH "DESCRIPTION" -Used to add, list, or clear the npm cache folder\. -. -.IP "\(bu" 4 -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\. -. -.IP "\(bu" 4 -ls: -Show the data in the cache\. Argument is a path to show in the cache -folder\. Works a bit like the \fBfind\fR program, but limited by the \fBdepth\fR config\. -. -.IP "\(bu" 4 -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\. -. -.IP "" 0 -. -.SH "DETAILS" -npm stores cache data in \fB$HOME/\.npm\fR\|\. For each package that is added -to the cache, three pieces of information are stored in \fB{cache}/{name}/{version}\fR: -. -.IP "\(bu" 4 -\|\.\.\./package/: -A folder containing the package contents as they appear in the tarball\. -. -.IP "\(bu" 4 -\|\.\.\./package\.json: -The package\.json file, as npm sees it, with overlays applied and a _id attribute\. -. -.IP "\(bu" 4 -\|\.\.\./package\.tgz: -The tarball for that version\. -. -.IP "" 0 -. -.P -Additionally, whenever a registry request is made, a \fB\|\.cache\.json\fR file -is placed at the corresponding URI, to store the ETag and the requested -data\. -. -.P -Commands that make non\-essential registry requests (such as \fBsearch\fR and \fBview\fR, or the completion scripts) generally specify a minimum timeout\. -If the \fB\|\.cache\.json\fR file is younger than the specified timeout, then -they do not make an HTTP request to the registry\. -. -.SH "CONFIGURATION" -. -.SS "cache" -Default: \fB$HOME/\.npm\fR on Posix, or \fB$HOME/npm\-cache\fR on Windows\. -. -.P -The root cache folder\. -. -.SH "SEE ALSO" -. -.IP "\(bu" 4 -npm help folders -. -.IP "\(bu" 4 -npm help config -. -.IP "\(bu" 4 -npm help install -. -.IP "\(bu" 4 -npm help publish -. -.IP "\(bu" 4 -npm help pack -. -.IP "" 0 - diff --git a/deps/npm/man/man1/changelog.1 b/deps/npm/man/man1/changelog.1 deleted file mode 100644 index 5c623301d..000000000 --- a/deps/npm/man/man1/changelog.1 +++ /dev/null @@ -1,173 +0,0 @@ -.\" Generated with Ronnjs 0.3.8 -.\" http://github.com/kapouer/ronnjs/ -. -.TH "NPM\-CHANGELOG" "1" "July 2013" "" "" -. -.SH "NAME" -\fBnpm-changelog\fR \-\- Changes -. -.SH "HISTORY" -. -.SS "1\.1\.3, 1\.1\.4" -. -.IP "\(bu" 4 -Update request to support HTTPS\-over\-HTTP proxy tunneling -. -.IP "\(bu" 4 -Throw on undefined envs in config settings -. -.IP "\(bu" 4 -Update which to 1\.0\.5 -. -.IP "\(bu" 4 -Fix windows UNC busyloop in findPrefix -. -.IP "\(bu" 4 -Bundle nested bundleDependencies properly -. -.IP "\(bu" 4 -Alias adduser to add\-user -. -.IP "\(bu" 4 -Doc updates (Christian Howe, Henrik Hodne, Andrew Lunny) -. -.IP "\(bu" 4 -ignore logfd/outfd streams in makeEnv() (Rod Vagg) -. -.IP "\(bu" 4 -shrinkwrap: Behave properly with url\-installed deps -. -.IP "\(bu" 4 -install: Support \-\-save with url install targets -. -.IP "\(bu" 4 -Support installing naked tars or single\-file modules from urls etc\. -. -.IP "\(bu" 4 -init: Don\'t add engines section -. -.IP "\(bu" 4 -Don\'t run make clean on rebuild -. -.IP "\(bu" 4 -Added missing unicode replacement (atomizer) -. -.IP "" 0 -. -.SS "1\.1\.2" -Dave Pacheco (2): - add "npm shrinkwrap" -. -.P -Martin Cooper (1): - Fix #1753 Make a copy of the cached objects we\'ll modify\. -. -.P -Tim Oxley (1): - correctly remove readme from default npm view command\. -. -.P -Tyler Green (1): - fix #2187 set terminal columns to Infinity if 0 -. -.P -isaacs (19): - update minimatch - update request - Experimental: single\-file modules - Fix #2172 Don\'t remove global mans uninstalling local pkgs - Add \-\-versions flag to show the version of node as well - Support \-\-json flag for ls output - update request to 2\.9\.151 -. -.SS "1\.1" -. -.IP "\(bu" 4 -Replace system tar dependency with a JS tar -. -.IP "\(bu" 4 -Continue to refine -. -.IP "" 0 -. -.SS "1\.0" -. -.IP "\(bu" 4 -Greatly simplified folder structure -. -.IP "\(bu" 4 -Install locally (bundle by default) -. -.IP "\(bu" 4 -Drastic rearchitecture -. -.IP "" 0 -. -.SS "0\.3" -. -.IP "\(bu" 4 -More correct permission/uid handling when running as root -. -.IP "\(bu" 4 -Require node 0\.4\.0 -. -.IP "\(bu" 4 -Reduce featureset -. -.IP "\(bu" 4 -Packages without "main" modules don\'t export modules -. -.IP "\(bu" 4 -Remove support for invalid JSON (since node doesn\'t support it) -. -.IP "" 0 -. -.SS "0\.2" -. -.IP "\(bu" 4 -First allegedly "stable" release -. -.IP "\(bu" 4 -Most functionality implemented -. -.IP "\(bu" 4 -Used shim files and \fBname@version\fR symlinks -. -.IP "\(bu" 4 -Feature explosion -. -.IP "\(bu" 4 -Kind of a mess -. -.IP "" 0 -. -.SS "0\.1" -. -.IP "\(bu" 4 -push to beta, and announce -. -.IP "\(bu" 4 -Solaris and Cygwin support -. -.IP "" 0 -. -.SS "0\.0" -. -.IP "\(bu" 4 -Lots of sketches and false starts; abandoned a few times -. -.IP "\(bu" 4 -Core functionality established -. -.IP "" 0 -. -.SH "SEE ALSO" -. -.IP "\(bu" 4 -npm help npm -. -.IP "\(bu" 4 -npm help faq -. -.IP "" 0 - diff --git a/deps/npm/man/man1/coding-style.1 b/deps/npm/man/man1/coding-style.1 deleted file mode 100644 index 79b1cae14..000000000 --- a/deps/npm/man/man1/coding-style.1 +++ /dev/null @@ -1,254 +0,0 @@ -.\" Generated with Ronnjs 0.3.8 -.\" http://github.com/kapouer/ronnjs/ -. -.TH "NPM\-CODING\-STYLE" "1" "July 2013" "" "" -. -.SH "NAME" -\fBnpm-coding-style\fR \-\- npm\'s "funny" coding style -. -.SH "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\. -. -.P -If you want to contribute to npm (which is very encouraged), you should -make your code conform to npm\'s style\. -. -.P -Note: this concerns npm\'s code not the specific packages at npmjs\.org -. -.SH "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\. -. -.SH "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\. -. -.P -Configure your editor appropriately\. -. -.SH "Curly braces" -Curly braces belong on the same line as the thing that necessitates them\. -. -.P -Bad: -. -.IP "" 4 -. -.nf -function () -{ -. -.fi -. -.IP "" 0 -. -.P -Good: -. -.IP "" 4 -. -.nf -function () { -. -.fi -. -.IP "" 0 -. -.P -If a block needs to wrap to the next line, use a curly brace\. Don\'t -use it if it doesn\'t\. -. -.P -Bad: -. -.IP "" 4 -. -.nf -if (foo) { bar() } -while (foo) - bar() -. -.fi -. -.IP "" 0 -. -.P -Good: -. -.IP "" 4 -. -.nf -if (foo) bar() -while (foo) { - bar() -} -. -.fi -. -.IP "" 0 -. -.SH "Semicolons" -Don\'t use them except in four situations: -. -.IP "\(bu" 4 -\fBfor (;;)\fR loops\. They\'re actually required\. -. -.IP "\(bu" 4 -null loops like: \fBwhile (something) ;\fR (But you\'d better have a good -reason for doing that\.) -. -.IP "\(bu" 4 -\fBcase "foo": doSomething(); break\fR -. -.IP "\(bu" 4 -In front of a leading \fB(\fR or \fB[\fR at the start of the line\. -This prevents the expression from being interpreted -as a function call or property access, respectively\. -. -.IP "" 0 -. -.P -Some examples of good semicolon usage: -. -.IP "" 4 -. -.nf -;(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() -} -. -.fi -. -.IP "" 0 -. -.P -Note that starting lines with \fB\-\fR and \fB+\fR also should be prefixed -with a semicolon, but this is much less common\. -. -.SH "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: -. -.IP "" 4 -. -.nf -var magicWords = [ "abracadabra" - , "gesundheit" - , "ventrilo" - ] - , spells = { "fireball" : function () { setOnFire() } - , "water" : function () { putOut() } - } - , a = 1 - , b = "abc" - , etc - , somethingElse -. -.fi -. -.IP "" 0 -. -.SH "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\. -. -.P -Don\'t leave trailing whitespace at the end of lines\. Don\'t indent empty -lines\. Don\'t use more spaces than are helpful\. -. -.SH "Functions" -Use named functions\. They make stack traces a lot easier to read\. -. -.SH "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\. -. -.P -The callback should always be the last argument in the list\. Its first -argument is the Error or null\. -. -.P -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\. -. -.SH "Errors" -Always create a new Error object with your message\. Don\'t just return a -string message to the callback\. Stack traces are handy\. -. -.SH "Logging" -Logging is done using the npmlog \fIhttps://github\.com/isaacs/npmlog\fR -utility\. -. -.P -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\. -. -.P -Use appropriate log levels\. See \fBnpm help config\fR and search for -"loglevel"\. -. -.SH "Case, naming, etc\." -Use \fBlowerCamelCase\fR for multiword identifiers when they refer to objects, -functions, methods, members, or anything not specified in this section\. -. -.P -Use \fBUpperCamelCase\fR for class names (things that you\'d pass to "new")\. -. -.P -Use \fBall\-lower\-hyphen\-css\-case\fR for multiword filenames and config keys\. -. -.P -Use named functions\. They make stack traces easier to follow\. -. -.P -Use \fBCAPS_SNAKE_CASE\fR for constants, things that should never change -and are rarely used\. -. -.P -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\. -. -.SH "null, undefined, false, 0" -Boolean variables and functions should always be either \fBtrue\fR or \fBfalse\fR\|\. Don\'t set it to 0 unless it\'s supposed to be a number\. -. -.P -When something is intentionally missing or removed, set it to \fBnull\fR\|\. -. -.P -Don\'t set things to \fBundefined\fR\|\. Reserve that value to mean "not yet -set to anything\." -. -.P -Boolean objects are verboten\. -. -.SH "SEE ALSO" -. -.IP "\(bu" 4 -npm help developers -. -.IP "\(bu" 4 -npm help faq -. -.IP "\(bu" 4 -npm help npm -. -.IP "" 0 - diff --git a/deps/npm/man/man1/completion.1 b/deps/npm/man/man1/completion.1 deleted file mode 100644 index ea0d0cd8b..000000000 --- a/deps/npm/man/man1/completion.1 +++ /dev/null @@ -1,47 +0,0 @@ -.\" Generated with Ronnjs 0.3.8 -.\" http://github.com/kapouer/ronnjs/ -. -.TH "NPM\-COMPLETION" "1" "July 2013" "" "" -. -.SH "NAME" -\fBnpm-completion\fR \-\- Tab Completion for npm -. -.SH "SYNOPSIS" -. -.nf -\|\. <(npm completion) -. -.fi -. -.SH "DESCRIPTION" -Enables tab\-completion in all npm commands\. -. -.P -The synopsis above -loads the completions into your current shell\. Adding it to -your ~/\.bashrc or ~/\.zshrc will make the completions available -everywhere\. -. -.P -You may of course also pipe the output of npm completion to a file -such as \fB/usr/local/etc/bash_completion\.d/npm\fR if you have a system -that will read that file for you\. -. -.P -When \fBCOMP_CWORD\fR, \fBCOMP_LINE\fR, and \fBCOMP_POINT\fR are defined in the -environment, \fBnpm completion\fR acts in "plumbing mode", and outputs -completions based on the arguments\. -. -.SH "SEE ALSO" -. -.IP "\(bu" 4 -npm help developers -. -.IP "\(bu" 4 -npm help faq -. -.IP "\(bu" 4 -npm help npm -. -.IP "" 0 - diff --git a/deps/npm/man/man1/config.1 b/deps/npm/man/man1/config.1 deleted file mode 100644 index 2e0e7a005..000000000 --- a/deps/npm/man/man1/config.1 +++ /dev/null @@ -1,1523 +0,0 @@ -.\" Generated with Ronnjs 0.3.8 -.\" http://github.com/kapouer/ronnjs/ -. -.TH "NPM\-CONFIG" "1" "July 2013" "" "" -. -.SH "NAME" -\fBnpm-config\fR \-\- Manage the npm configuration file -. -.SH "SYNOPSIS" -. -.nf -npm config set [\-\-global] -npm config get -npm config delete -npm config list -npm config edit -npm get -npm set [\-\-global] -. -.fi -. -.SH "DESCRIPTION" -npm gets its configuration values from 6 sources, in this priority: -. -.SS "Command Line Flags" -Putting \fB\-\-foo bar\fR on the command line sets the \fBfoo\fR configuration parameter to \fB"bar"\fR\|\. A \fB\-\-\fR argument tells the cli -parser to stop reading flags\. A \fB\-\-flag\fR parameter that is at the \fIend\fR of -the command will be given the value of \fBtrue\fR\|\. -. -.SS "Environment Variables" -Any environment variables that start with \fBnpm_config_\fR will be interpreted -as a configuration parameter\. For example, putting \fBnpm_config_foo=bar\fR in -your environment will set the \fBfoo\fR configuration parameter to \fBbar\fR\|\. Any -environment configurations that are not given a value will be given the value -of \fBtrue\fR\|\. Config values are case\-insensitive, so \fBNPM_CONFIG_FOO=bar\fR will -work the same\. -. -.SS "Per\-user config file" -\fB$HOME/\.npmrc\fR (or the \fBuserconfig\fR param, if set above) -. -.P -This file is an ini\-file formatted list of \fBkey = value\fR parameters\. -Environment variables can be replaced using \fB${VARIABLE_NAME}\fR\|\. For example: -. -.IP "" 4 -. -.nf -prefix = ${HOME}/\.npm\-packages -. -.fi -. -.IP "" 0 -. -.SS "Global config file" -\fB$PREFIX/etc/npmrc\fR (or the \fBglobalconfig\fR param, if set above): -This file is an ini\-file formatted list of \fBkey = value\fR parameters\. -Environment variables can be replaced as above\. -. -.SS "Built\-in config file" -\fBpath/to/npm/itself/npmrc\fR -. -.P -This is an unchangeable "builtin" -configuration file that npm keeps consistent across updates\. Set -fields in here using the \fB\|\./configure\fR script that comes with npm\. -This is primarily for distribution maintainers to override default -configs in a standard and consistent manner\. -. -.SS "Default Configs" -A set of configuration parameters that are internal to npm, and are -defaults if nothing else is specified\. -. -.SH "Sub\-commands" -Config supports the following sub\-commands: -. -.SS "set" -. -.nf -npm config set key value -. -.fi -. -.P -Sets the config key to the value\. -. -.P -If value is omitted, then it sets it to "true"\. -. -.SS "get" -. -.nf -npm config get key -. -.fi -. -.P -Echo the config value to stdout\. -. -.SS "list" -. -.nf -npm config list -. -.fi -. -.P -Show all the config settings\. -. -.SS "delete" -. -.nf -npm config delete key -. -.fi -. -.P -Deletes the key from all configuration files\. -. -.SS "edit" -. -.nf -npm config edit -. -.fi -. -.P -Opens the config file in an editor\. Use the \fB\-\-global\fR flag to edit the -global config\. -. -.SH "Shorthands and Other CLI Niceties" -The following shorthands are parsed on the command\-line: -. -.IP "\(bu" 4 -\fB\-v\fR: \fB\-\-version\fR -. -.IP "\(bu" 4 -\fB\-h\fR, \fB\-?\fR, \fB\-\-help\fR, \fB\-H\fR: \fB\-\-usage\fR -. -.IP "\(bu" 4 -\fB\-s\fR, \fB\-\-silent\fR: \fB\-\-loglevel silent\fR -. -.IP "\(bu" 4 -\fB\-q\fR, \fB\-\-quiet\fR: \fB\-\-loglevel warn\fR -. -.IP "\(bu" 4 -\fB\-d\fR: \fB\-\-loglevel info\fR -. -.IP "\(bu" 4 -\fB\-dd\fR, \fB\-\-verbose\fR: \fB\-\-loglevel verbose\fR -. -.IP "\(bu" 4 -\fB\-ddd\fR: \fB\-\-loglevel silly\fR -. -.IP "\(bu" 4 -\fB\-g\fR: \fB\-\-global\fR -. -.IP "\(bu" 4 -\fB\-l\fR: \fB\-\-long\fR -. -.IP "\(bu" 4 -\fB\-m\fR: \fB\-\-message\fR -. -.IP "\(bu" 4 -\fB\-p\fR, \fB\-\-porcelain\fR: \fB\-\-parseable\fR -. -.IP "\(bu" 4 -\fB\-reg\fR: \fB\-\-registry\fR -. -.IP "\(bu" 4 -\fB\-v\fR: \fB\-\-version\fR -. -.IP "\(bu" 4 -\fB\-f\fR: \fB\-\-force\fR -. -.IP "\(bu" 4 -\fB\-desc\fR: \fB\-\-description\fR -. -.IP "\(bu" 4 -\fB\-S\fR: \fB\-\-save\fR -. -.IP "\(bu" 4 -\fB\-D\fR: \fB\-\-save\-dev\fR -. -.IP "\(bu" 4 -\fB\-O\fR: \fB\-\-save\-optional\fR -. -.IP "\(bu" 4 -\fB\-B\fR: \fB\-\-save\-bundle\fR -. -.IP "\(bu" 4 -\fB\-y\fR: \fB\-\-yes\fR -. -.IP "\(bu" 4 -\fB\-n\fR: \fB\-\-yes false\fR -. -.IP "\(bu" 4 -\fBll\fR and \fBla\fR commands: \fBls \-\-long\fR -. -.IP "" 0 -. -.P -If the specified configuration param resolves unambiguously to a known -configuration parameter, then it is expanded to that configuration -parameter\. For example: -. -.IP "" 4 -. -.nf -npm ls \-\-par -# same as: -npm ls \-\-parseable -. -.fi -. -.IP "" 0 -. -.P -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: -. -.IP "" 4 -. -.nf -npm ls \-gpld -# same as: -npm ls \-\-global \-\-parseable \-\-long \-\-loglevel info -. -.fi -. -.IP "" 0 -. -.SH "Per\-Package Config Settings" -When running scripts (see \fBnpm help scripts\fR) -the package\.json "config" keys are overwritten in the environment if -there is a config param of \fB[@]:\fR\|\. For example, if -the package\.json has this: -. -.IP "" 4 -. -.nf -{ "name" : "foo" -, "config" : { "port" : "8080" } -, "scripts" : { "start" : "node server\.js" } } -. -.fi -. -.IP "" 0 -. -.P -and the server\.js is this: -. -.IP "" 4 -. -.nf -http\.createServer(\.\.\.)\.listen(process\.env\.npm_package_config_port) -. -.fi -. -.IP "" 0 -. -.P -then the user could change the behavior by doing: -. -.IP "" 4 -. -.nf -npm config set foo:port 80 -. -.fi -. -.IP "" 0 -. -.SH "Config Settings" -. -.SS "always\-auth" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Force npm to always require authentication when accessing the registry, -even for \fBGET\fR requests\. -. -.SS "bin\-links" -. -.IP "\(bu" 4 -Default: \fBtrue\fR -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Tells npm to create symlinks (or \fB\|\.cmd\fR shims on Windows) for package -executables\. -. -.P -Set to false to have it not do this\. This can be used to work around -the fact that some file systems don\'t support symlinks, even on -ostensibly Unix systems\. -. -.SS "browser" -. -.IP "\(bu" 4 -Default: OS X: \fB"open"\fR, Windows: \fB"start"\fR, Others: \fB"xdg\-open"\fR -. -.IP "\(bu" 4 -Type: String -. -.IP "" 0 -. -.P -The browser that is called by the \fBnpm docs\fR command to open websites\. -. -.SS "ca" -. -.IP "\(bu" 4 -Default: The npm CA certificate -. -.IP "\(bu" 4 -Type: String or null -. -.IP "" 0 -. -.P -The Certificate Authority signing certificate that is trusted for SSL -connections to the registry\. -. -.P -Set to \fBnull\fR to only allow "known" registrars, or to a specific CA cert -to trust only that specific signing authority\. -. -.P -See also the \fBstrict\-ssl\fR config\. -. -.SS "cache" -. -.IP "\(bu" 4 -Default: Windows: \fB%APPDATA%\\npm\-cache\fR, Posix: \fB~/\.npm\fR -. -.IP "\(bu" 4 -Type: path -. -.IP "" 0 -. -.P -The location of npm\'s cache directory\. See \fBnpm help cache\fR -. -.SS "cache\-lock\-stale" -. -.IP "\(bu" 4 -Default: 60000 (1 minute) -. -.IP "\(bu" 4 -Type: Number -. -.IP "" 0 -. -.P -The number of ms before cache folder lockfiles are considered stale\. -. -.SS "cache\-lock\-retries" -. -.IP "\(bu" 4 -Default: 10 -. -.IP "\(bu" 4 -Type: Number -. -.IP "" 0 -. -.P -Number of times to retry to acquire a lock on cache folder lockfiles\. -. -.SS "cache\-lock\-wait" -. -.IP "\(bu" 4 -Default: 10000 (10 seconds) -. -.IP "\(bu" 4 -Type: Number -. -.IP "" 0 -. -.P -Number of ms to wait for cache lock files to expire\. -. -.SS "cache\-max" -. -.IP "\(bu" 4 -Default: Infinity -. -.IP "\(bu" 4 -Type: Number -. -.IP "" 0 -. -.P -The maximum time (in seconds) to keep items in the registry cache before -re\-checking against the registry\. -. -.P -Note that no purging is done unless the \fBnpm cache clean\fR command is -explicitly used, and that only GET requests use the cache\. -. -.SS "cache\-min" -. -.IP "\(bu" 4 -Default: 10 -. -.IP "\(bu" 4 -Type: Number -. -.IP "" 0 -. -.P -The minimum time (in seconds) to keep items in the registry cache before -re\-checking against the registry\. -. -.P -Note that no purging is done unless the \fBnpm cache clean\fR command is -explicitly used, and that only GET requests use the cache\. -. -.SS "color" -. -.IP "\(bu" 4 -Default: true on Posix, false on Windows -. -.IP "\(bu" 4 -Type: Boolean or \fB"always"\fR -. -.IP "" 0 -. -.P -If false, never shows colors\. If \fB"always"\fR then always shows colors\. -If true, then only prints color codes for tty file descriptors\. -. -.SS "coverage" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -A flag to tell test\-harness to run with their coverage options enabled, -if they respond to the \fBnpm_config_coverage\fR environment variable\. -. -.SS "depth" -. -.IP "\(bu" 4 -Default: Infinity -. -.IP "\(bu" 4 -Type: Number -. -.IP "" 0 -. -.P -The depth to go when recursing directories for \fBnpm ls\fR and \fBnpm cache ls\fR\|\. -. -.SS "description" -. -.IP "\(bu" 4 -Default: true -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Show the description in \fBnpm search\fR -. -.SS "dev" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Install \fBdev\-dependencies\fR along with packages\. -. -.P -Note that \fBdev\-dependencies\fR are also installed if the \fBnpat\fR flag is -set\. -. -.SS "editor" -. -.IP "\(bu" 4 -Default: \fBEDITOR\fR environment variable if set, or \fB"vi"\fR on Posix, -or \fB"notepad"\fR on Windows\. -. -.IP "\(bu" 4 -Type: path -. -.IP "" 0 -. -.P -The command to run for \fBnpm edit\fR or \fBnpm config edit\fR\|\. -. -.SS "engine\-strict" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -If set to true, then npm will stubbornly refuse to install (or even -consider installing) any package that claims to not be compatible with -the current Node\.js version\. -. -.SS "force" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Makes various commands more forceful\. -. -.IP "\(bu" 4 -lifecycle script failure does not block progress\. -. -.IP "\(bu" 4 -publishing clobbers previously published versions\. -. -.IP "\(bu" 4 -skips cache when requesting from the registry\. -. -.IP "\(bu" 4 -prevents checks against clobbering non\-npm files\. -. -.IP "" 0 -. -.SS "fetch\-retries" -. -.IP "\(bu" 4 -Default: 2 -. -.IP "\(bu" 4 -Type: Number -. -.IP "" 0 -. -.P -The "retries" config for the \fBretry\fR module to use when fetching -packages from the registry\. -. -.SS "fetch\-retry\-factor" -. -.IP "\(bu" 4 -Default: 10 -. -.IP "\(bu" 4 -Type: Number -. -.IP "" 0 -. -.P -The "factor" config for the \fBretry\fR module to use when fetching -packages\. -. -.SS "fetch\-retry\-mintimeout" -. -.IP "\(bu" 4 -Default: 10000 (10 seconds) -. -.IP "\(bu" 4 -Type: Number -. -.IP "" 0 -. -.P -The "minTimeout" config for the \fBretry\fR module to use when fetching -packages\. -. -.SS "fetch\-retry\-maxtimeout" -. -.IP "\(bu" 4 -Default: 60000 (1 minute) -. -.IP "\(bu" 4 -Type: Number -. -.IP "" 0 -. -.P -The "maxTimeout" config for the \fBretry\fR module to use when fetching -packages\. -. -.SS "git" -. -.IP "\(bu" 4 -Default: \fB"git"\fR -. -.IP "\(bu" 4 -Type: String -. -.IP "" 0 -. -.P -The command to use for git commands\. If git is installed on the -computer, but is not in the \fBPATH\fR, then set this to the full path to -the git binary\. -. -.SS "global" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Operates in "global" mode, so that packages are installed into the \fBprefix\fR folder instead of the current working directory\. See \fBnpm help folders\fR for more on the differences in behavior\. -. -.IP "\(bu" 4 -packages are installed into the \fB{prefix}/lib/node_modules\fR folder, instead of the -current working directory\. -. -.IP "\(bu" 4 -bin files are linked to \fB{prefix}/bin\fR -. -.IP "\(bu" 4 -man pages are linked to \fB{prefix}/share/man\fR -. -.IP "" 0 -. -.SS "globalconfig" -. -.IP "\(bu" 4 -Default: {prefix}/etc/npmrc -. -.IP "\(bu" 4 -Type: path -. -.IP "" 0 -. -.P -The config file to read for global config options\. -. -.SS "globalignorefile" -. -.IP "\(bu" 4 -Default: {prefix}/etc/npmignore -. -.IP "\(bu" 4 -Type: path -. -.IP "" 0 -. -.P -The config file to read for global ignore patterns to apply to all users -and all projects\. -. -.P -If not found, but there is a "gitignore" file in the -same directory, then that will be used instead\. -. -.SS "group" -. -.IP "\(bu" 4 -Default: GID of the current process -. -.IP "\(bu" 4 -Type: String or Number -. -.IP "" 0 -. -.P -The group to use when running package scripts in global mode as the root -user\. -. -.SS "https\-proxy" -. -.IP "\(bu" 4 -Default: the \fBHTTPS_PROXY\fR or \fBhttps_proxy\fR or \fBHTTP_PROXY\fR or \fBhttp_proxy\fR environment variables\. -. -.IP "\(bu" 4 -Type: url -. -.IP "" 0 -. -.P -A proxy to use for outgoing https requests\. -. -.SS "user\-agent" -. -.IP "\(bu" 4 -Default: node/{process\.version} {process\.platform} {process\.arch} -. -.IP "\(bu" 4 -Type: String -. -.IP "" 0 -. -.P -Sets a User\-Agent to the request header -. -.SS "ignore" -. -.IP "\(bu" 4 -Default: "" -. -.IP "\(bu" 4 -Type: string -. -.IP "" 0 -. -.P -A white\-space separated list of glob patterns of files to always exclude -from packages when building tarballs\. -. -.SS "init\-module" -. -.IP "\(bu" 4 -Default: ~/\.npm\-init\.js -. -.IP "\(bu" 4 -Type: path -. -.IP "" 0 -. -.P -A module that will be loaded by the \fBnpm init\fR command\. See the -documentation for the init\-package\-json \fIhttps://github\.com/isaacs/init\-package\-json\fR module -for more information, or npm help init\. -. -.SS "init\.version" -. -.IP "\(bu" 4 -Default: "0\.0\.0" -. -.IP "\(bu" 4 -Type: semver -. -.IP "" 0 -. -.P -The value \fBnpm init\fR should use by default for the package version\. -. -.SS "init\.author\.name" -. -.IP "\(bu" 4 -Default: "" -. -.IP "\(bu" 4 -Type: String -. -.IP "" 0 -. -.P -The value \fBnpm init\fR should use by default for the package author\'s name\. -. -.SS "init\.author\.email" -. -.IP "\(bu" 4 -Default: "" -. -.IP "\(bu" 4 -Type: String -. -.IP "" 0 -. -.P -The value \fBnpm init\fR should use by default for the package author\'s email\. -. -.SS "init\.author\.url" -. -.IP "\(bu" 4 -Default: "" -. -.IP "\(bu" 4 -Type: String -. -.IP "" 0 -. -.P -The value \fBnpm init\fR should use by default for the package author\'s homepage\. -. -.SS "json" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Whether or not to output JSON data, rather than the normal output\. -. -.P -This feature is currently experimental, and the output data structures -for many commands is either not implemented in JSON yet, or subject to -change\. Only the output from \fBnpm ls \-\-json\fR is currently valid\. -. -.SS "link" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -If true, then local installs will link if there is a suitable globally -installed package\. -. -.P -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: -. -.IP "\(bu" 4 -The package is not already installed globally, or -. -.IP "\(bu" 4 -the globally installed version is identical to the version that is -being installed locally\. -. -.IP "" 0 -. -.SS "loglevel" -. -.IP "\(bu" 4 -Default: "http" -. -.IP "\(bu" 4 -Type: String -. -.IP "\(bu" 4 -Values: "silent", "win", "error", "warn", "http", "info", "verbose", "silly" -. -.IP "" 0 -. -.P -What level of logs to report\. On failure, \fIall\fR logs are written to \fBnpm\-debug\.log\fR in the current working directory\. -. -.P -Any logs of a higher level than the setting are shown\. -The default is "http", which shows http, warn, and error output\. -. -.SS "logstream" -. -.IP "\(bu" 4 -Default: process\.stderr -. -.IP "\(bu" 4 -Type: Stream -. -.IP "" 0 -. -.P -This is the stream that is passed to the npmlog \fIhttps://github\.com/isaacs/npmlog\fR module at run time\. -. -.P -It cannot be set from the command line, but if you are using npm -programmatically, you may wish to send logs to somewhere other than -stderr\. -. -.P -If the \fBcolor\fR config is set to true, then this stream will receive -colored output if it is a TTY\. -. -.SS "long" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Show extended information in \fBnpm ls\fR -. -.SS "message" -. -.IP "\(bu" 4 -Default: "%s" -. -.IP "\(bu" 4 -Type: String -. -.IP "" 0 -. -.P -Commit message which is used by \fBnpm version\fR when creating version commit\. -. -.P -Any "%s" in the message will be replaced with the version number\. -. -.SS "node\-version" -. -.IP "\(bu" 4 -Default: process\.version -. -.IP "\(bu" 4 -Type: semver or false -. -.IP "" 0 -. -.P -The node version to use when checking package\'s "engines" hash\. -. -.SS "npat" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Run tests on installation and report results to the \fBnpaturl\fR\|\. -. -.SS "npaturl" -. -.IP "\(bu" 4 -Default: Not yet implemented -. -.IP "\(bu" 4 -Type: url -. -.IP "" 0 -. -.P -The url to report npat test results\. -. -.SS "onload\-script" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: path -. -.IP "" 0 -. -.P -A node module to \fBrequire()\fR when npm loads\. Useful for programmatic -usage\. -. -.SS "optional" -. -.IP "\(bu" 4 -Default: true -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Attempt to install packages in the \fBoptionalDependencies\fR hash\. Note -that if these packages fail to install, the overall installation -process is not aborted\. -. -.SS "parseable" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Output parseable results from commands that write to -standard output\. -. -.SS "prefix" -. -.IP "\(bu" 4 -Default: see npm help folders -. -.IP "\(bu" 4 -Type: path -. -.IP "" 0 -. -.P -The location to install global items\. If set on the command line, then -it forces non\-global commands to run in the specified folder\. -. -.SS "production" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Set to true to run in "production" mode\. -. -.IP "1" 4 -devDependencies are not installed at the topmost level when running -local \fBnpm install\fR without any arguments\. -. -.IP "2" 4 -Set the NODE_ENV="production" for lifecycle scripts\. -. -.IP "" 0 -. -.SS "proprietary\-attribs" -. -.IP "\(bu" 4 -Default: true -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Whether or not to include proprietary extended attributes in the -tarballs created by npm\. -. -.P -Unless you are expecting to unpack package tarballs with something other -than npm \-\- particularly a very outdated tar implementation \-\- leave -this as true\. -. -.SS "proxy" -. -.IP "\(bu" 4 -Default: \fBHTTP_PROXY\fR or \fBhttp_proxy\fR environment variable, or null -. -.IP "\(bu" 4 -Type: url -. -.IP "" 0 -. -.P -A proxy to use for outgoing http requests\. -. -.SS "rebuild\-bundle" -. -.IP "\(bu" 4 -Default: true -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Rebuild bundled dependencies after installation\. -. -.SS "registry" -. -.IP "\(bu" 4 -Default: https://registry\.npmjs\.org/ -. -.IP "\(bu" 4 -Type: url -. -.IP "" 0 -. -.P -The base URL of the npm package registry\. -. -.SS "rollback" -. -.IP "\(bu" 4 -Default: true -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Remove failed installs\. -. -.SS "save" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Save installed packages to a package\.json file as dependencies\. -. -.P -When used with the \fBnpm rm\fR command, it removes it from the dependencies -hash\. -. -.P -Only works if there is already a package\.json file present\. -. -.SS "save\-bundle" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -If a package would be saved at install time by the use of \fB\-\-save\fR, \fB\-\-save\-dev\fR, or \fB\-\-save\-optional\fR, then also put it in the \fBbundleDependencies\fR list\. -. -.P -When used with the \fBnpm rm\fR command, it removes it from the -bundledDependencies list\. -. -.SS "save\-dev" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Save installed packages to a package\.json file as devDependencies\. -. -.P -When used with the \fBnpm rm\fR command, it removes it from the devDependencies -hash\. -. -.P -Only works if there is already a package\.json file present\. -. -.SS "save\-optional" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Save installed packages to a package\.json file as optionalDependencies\. -. -.P -When used with the \fBnpm rm\fR command, it removes it from the devDependencies -hash\. -. -.P -Only works if there is already a package\.json file present\. -. -.SS "searchopts" -. -.IP "\(bu" 4 -Default: "" -. -.IP "\(bu" 4 -Type: String -. -.IP "" 0 -. -.P -Space\-separated options that are always passed to search\. -. -.SS "searchexclude" -. -.IP "\(bu" 4 -Default: "" -. -.IP "\(bu" 4 -Type: String -. -.IP "" 0 -. -.P -Space\-separated options that limit the results from search\. -. -.SS "searchsort" -. -.IP "\(bu" 4 -Default: "name" -. -.IP "\(bu" 4 -Type: String -. -.IP "\(bu" 4 -Values: "name", "\-name", "date", "\-date", "description", -"\-description", "keywords", "\-keywords" -. -.IP "" 0 -. -.P -Indication of which field to sort search results by\. Prefix with a \fB\-\fR -character to indicate reverse sort\. -. -.SS "shell" -. -.IP "\(bu" 4 -Default: SHELL environment variable, or "bash" on Posix, or "cmd" on -Windows -. -.IP "\(bu" 4 -Type: path -. -.IP "" 0 -. -.P -The shell to run for the \fBnpm explore\fR command\. -. -.SS "shrinkwrap" -. -.IP "\(bu" 4 -Default: true -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -If set to false, then ignore \fBnpm\-shrinkwrap\.json\fR files when -installing\. -. -.SS "sign\-git\-tag" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -If set to true, then the \fBnpm version\fR command will tag the version -using \fB\-s\fR to add a signature\. -. -.P -Note that git requires you to have set up GPG keys in your git configs -for this to work properly\. -. -.SS "strict\-ssl" -. -.IP "\(bu" 4 -Default: true -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Whether or not to do SSL key validation when making requests to the -registry via https\. -. -.P -See also the \fBca\fR config\. -. -.SS "tag" -. -.IP "\(bu" 4 -Default: latest -. -.IP "\(bu" 4 -Type: String -. -.IP "" 0 -. -.P -If you ask npm to install a package and don\'t tell it a specific version, then -it will install the specified tag\. -. -.P -Also the tag that is added to the package@version specified by the \fBnpm -tag\fR command, if no explicit tag is given\. -. -.SS "tmp" -. -.IP "\(bu" 4 -Default: TMPDIR environment variable, or "/tmp" -. -.IP "\(bu" 4 -Type: path -. -.IP "" 0 -. -.P -Where to store temporary files and folders\. All temp files are deleted -on success, but left behind on failure for forensic purposes\. -. -.SS "unicode" -. -.IP "\(bu" 4 -Default: true -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -When set to true, npm uses unicode characters in the tree output\. When -false, it uses ascii characters to draw trees\. -. -.SS "unsafe\-perm" -. -.IP "\(bu" 4 -Default: false if running as root, true otherwise -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -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\. -. -.SS "usage" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Set to show short usage output (like the \-H output) -instead of complete help when doing \fBnpm help help\fR\|\. -. -.SS "user" -. -.IP "\(bu" 4 -Default: "nobody" -. -.IP "\(bu" 4 -Type: String or Number -. -.IP "" 0 -. -.P -The UID to set to when running package scripts as root\. -. -.SS "username" -. -.IP "\(bu" 4 -Default: null -. -.IP "\(bu" 4 -Type: String -. -.IP "" 0 -. -.P -The username on the npm registry\. Set with \fBnpm adduser\fR -. -.SS "userconfig" -. -.IP "\(bu" 4 -Default: ~/\.npmrc -. -.IP "\(bu" 4 -Type: path -. -.IP "" 0 -. -.P -The location of user\-level configuration settings\. -. -.SS "userignorefile" -. -.IP "\(bu" 4 -Default: ~/\.npmignore -. -.IP "\(bu" 4 -Type: path -. -.IP "" 0 -. -.P -The location of a user\-level ignore file to apply to all packages\. -. -.P -If not found, but there is a \.gitignore file in the same directory, then -that will be used instead\. -. -.SS "umask" -. -.IP "\(bu" 4 -Default: 022 -. -.IP "\(bu" 4 -Type: Octal numeric string -. -.IP "" 0 -. -.P -The "umask" value to use when setting the file creation mode on files -and folders\. -. -.P -Folders and executables are given a mode which is \fB0777\fR masked against -this value\. Other files are given a mode which is \fB0666\fR masked against -this value\. Thus, the defaults are \fB0755\fR and \fB0644\fR respectively\. -. -.SS "version" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: boolean -. -.IP "" 0 -. -.P -If true, output the npm version and exit successfully\. -. -.P -Only relevant when specified explicitly on the command line\. -. -.SS "versions" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: boolean -. -.IP "" 0 -. -.P -If true, output the npm version as well as node\'s \fBprocess\.versions\fR -hash, and exit successfully\. -. -.P -Only relevant when specified explicitly on the command line\. -. -.SS "viewer" -. -.IP "\(bu" 4 -Default: "man" on Posix, "browser" on Windows -. -.IP "\(bu" 4 -Type: path -. -.IP "" 0 -. -.P -The program to use to view help content\. -. -.P -Set to \fB"browser"\fR to view html help content in the default web browser\. -. -.SS "yes" -. -.IP "\(bu" 4 -Default: null -. -.IP "\(bu" 4 -Type: Boolean or null -. -.IP "" 0 -. -.P -If set to \fBnull\fR, then prompt the user for responses in some -circumstances\. -. -.P -If set to \fBtrue\fR, then answer "yes" to any prompt\. If set to \fBfalse\fR -then answer "no" to any prompt\. -. -.SH "SEE ALSO" -. -.IP "\(bu" 4 -npm help folders -. -.IP "\(bu" 4 -npm help npm -. -.IP "" 0 - diff --git a/deps/npm/man/man1/dedupe.1 b/deps/npm/man/man1/dedupe.1 deleted file mode 100644 index 63b6fdaf8..000000000 --- a/deps/npm/man/man1/dedupe.1 +++ /dev/null @@ -1,90 +0,0 @@ -.\" Generated with Ronnjs 0.3.8 -.\" http://github.com/kapouer/ronnjs/ -. -.TH "NPM\-DEDUPE" "1" "July 2013" "" "" -. -.SH "NAME" -\fBnpm-dedupe\fR \-\- Reduce duplication -. -.SH "SYNOPSIS" -. -.nf -npm dedupe [package names\.\.\.] -. -.fi -. -.SH "DESCRIPTION" -Searches the local package tree and attempts to simplify the overall -structure by moving dependencies further up the tree, where they can -be more effectively shared by multiple dependent packages\. -. -.P -For example, consider this dependency graph: -. -.IP "" 4 -. -.nf -a -+\-\- b <\-\- depends on c@1\.0\.x -| `\-\- c@1\.0\.3 -`\-\- d <\-\- depends on c@~1\.0\.9 - `\-\- c@1\.0\.10 -. -.fi -. -.IP "" 0 -. -.P -In this case, \fBnpm help dedupe\fR will transform the tree to: -. -.IP "" 4 -. -.nf -a -+\-\- b -+\-\- d -`\-\- c@1\.0\.10 -. -.fi -. -.IP "" 0 -. -.P -Because of the hierarchical nature of node\'s module lookup, b and d -will both get their dependency met by the single c package at the root -level of the tree\. -. -.P -If a suitable version exists at the target location in the tree -already, then it will be left untouched, but the other duplicates will -be deleted\. -. -.P -If no suitable version can be found, then a warning is printed, and -nothing is done\. -. -.P -If any arguments are supplied, then they are filters, and only the -named packages will be touched\. -. -.P -Note that this operation transforms the dependency tree, and may -result in packages getting updated versions, perhaps from the npm -registry\. -. -.P -This feature is experimental, and may change in future versions\. -. -.SH "SEE ALSO" -. -.IP "\(bu" 4 -npm help ls -. -.IP "\(bu" 4 -npm help update -. -.IP "\(bu" 4 -npm help install -. -.IP "" 0 - diff --git a/deps/npm/man/man1/deprecate.1 b/deps/npm/man/man1/deprecate.1 deleted file mode 100644 index f29f0ce6b..000000000 --- a/deps/npm/man/man1/deprecate.1 +++ /dev/null @@ -1,48 +0,0 @@ -.\" Generated with Ronnjs 0.3.8 -.\" http://github.com/kapouer/ronnjs/ -. -.TH "NPM\-DEPRECATE" "1" "July 2013" "" "" -. -.SH "NAME" -\fBnpm-deprecate\fR \-\- Deprecate a version of a package -. -.SH "SYNOPSIS" -. -.nf -npm deprecate [@] -. -.fi -. -.SH "DESCRIPTION" -This command will update the npm registry entry for a package, providing -a deprecation warning to all who attempt to install it\. -. -.P -It works on version ranges as well as specific versions, so you can do -something like this: -. -.IP "" 4 -. -.nf -npm deprecate my\-thing@"< 0\.2\.3" "critical bug fixed in v0\.2\.3" -. -.fi -. -.IP "" 0 -. -.P -Note that you must be the package owner to deprecate something\. See the \fBowner\fR and \fBadduser\fR help topics\. -. -.P -To un\-deprecate a package, specify an empty string (\fB""\fR) for the \fBmessage\fR argument\. -. -.SH "SEE ALSO" -. -.IP "\(bu" 4 -npm help publish -. -.IP "\(bu" 4 -npm help registry -. -.IP "" 0 - diff --git a/deps/npm/man/man1/developers.1 b/deps/npm/man/man1/developers.1 deleted file mode 100644 index aa18ccd01..000000000 --- a/deps/npm/man/man1/developers.1 +++ /dev/null @@ -1,335 +0,0 @@ -.\" Generated with Ronnjs 0.3.8 -.\" http://github.com/kapouer/ronnjs/ -. -.TH "NPM\-DEVELOPERS" "1" "July 2013" "" "" -. -.SH "NAME" -\fBnpm-developers\fR \-\- Developer Guide -. -.SH "DESCRIPTION" -So, you\'ve decided to use npm to develop (and maybe publish/deploy) -your project\. -. -.P -Fantastic! -. -.P -There are a few things that you need to do above the simple steps -that your users will do to install your program\. -. -.SH "About These Documents" -These are man pages\. If you install npm, you should be able to -then do \fBman npm\-thing\fR to get the documentation on a particular -topic, or \fBnpm help thing\fR to see the same information\. -. -.SH "What is a " -A package is: -. -.IP "\(bu" 4 -a) a folder containing a program described by a package\.json file -. -.IP "\(bu" 4 -b) a gzipped tarball containing (a) -. -.IP "\(bu" 4 -c) a url that resolves to (b) -. -.IP "\(bu" 4 -d) a \fB@\fR that is published on the registry with (c) -. -.IP "\(bu" 4 -e) a \fB@\fR that points to (d) -. -.IP "\(bu" 4 -f) a \fB\fR that has a "latest" tag satisfying (e) -. -.IP "\(bu" 4 -g) a \fBgit\fR url that, when cloned, results in (a)\. -. -.IP "" 0 -. -.P -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)\. -. -.P -Git urls can be of the form: -. -.IP "" 4 -. -.nf -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 -. -.fi -. -.IP "" 0 -. -.P -The \fBcommit\-ish\fR can be any tag, sha, or branch which can be supplied as -an argument to \fBgit checkout\fR\|\. The default is \fBmaster\fR\|\. -. -.SH "The package\.json File" -You need to have a \fBpackage\.json\fR file in the root of your project to do -much of anything with npm\. That is basically the whole interface\. -. -.P -See \fBnpm help json\fR for details about what goes in that file\. At the very -least, you need: -. -.IP "\(bu" 4 -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\. -. -.IP -It does not necessarily need to match your github repository name\. -. -.IP -So, \fBnode\-foo\fR and \fBbar\-js\fR are bad names\. \fBfoo\fR or \fBbar\fR are better\. -. -.IP "\(bu" 4 -version: -A semver\-compatible version\. -. -.IP "\(bu" 4 -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\. -. -.IP "\(bu" 4 -author: -Take some credit\. -. -.IP "\(bu" 4 -scripts: -If you have a special compilation or installation script, then you -should put it in the \fBscripts\fR hash\. You should definitely have at -least a basic smoke\-test command as the "scripts\.test" field\. -See npm help scripts\. -. -.IP "\(bu" 4 -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\. -. -.IP "\(bu" 4 -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\. -. -.IP "" 0 -. -.P -You can use \fBnpm init\fR in the root of your package in order to get you -started with a pretty basic package\.json file\. See \fBnpm help init\fR for -more info\. -. -.SH "Keeping files " -Use a \fB\|\.npmignore\fR file to keep stuff out of your package\. If there\'s -no \fB\|\.npmignore\fR file, but there \fIis\fR a \fB\|\.gitignore\fR file, then npm will -ignore the stuff matched by the \fB\|\.gitignore\fR file\. If you \fIwant\fR to -include something that is excluded by your \fB\|\.gitignore\fR file, you can -create an empty \fB\|\.npmignore\fR file to override it\. -. -.P -By default, the following paths and files are ignored, so there\'s no -need to add them to \fB\|\.npmignore\fR explicitly: -. -.IP "\(bu" 4 -\fB\|\.*\.swp\fR -. -.IP "\(bu" 4 -\fB\|\._*\fR -. -.IP "\(bu" 4 -\fB\|\.DS_Store\fR -. -.IP "\(bu" 4 -\fB\|\.git\fR -. -.IP "\(bu" 4 -\fB\|\.hg\fR -. -.IP "\(bu" 4 -\fB\|\.lock\-wscript\fR -. -.IP "\(bu" 4 -\fB\|\.svn\fR -. -.IP "\(bu" 4 -\fB\|\.wafpickle\-*\fR -. -.IP "\(bu" 4 -\fBCVS\fR -. -.IP "\(bu" 4 -\fBnpm\-debug\.log\fR -. -.IP "" 0 -. -.P -Additionally, everything in \fBnode_modules\fR is ignored, except for -bundled dependencies\. npm automatically handles this for you, so don\'t -bother adding \fBnode_modules\fR to \fB\|\.npmignore\fR\|\. -. -.P -The following paths and files are never ignored, so adding them to \fB\|\.npmignore\fR is pointless: -. -.IP "\(bu" 4 -\fBpackage\.json\fR -. -.IP "\(bu" 4 -\fBREADME\.*\fR -. -.IP "" 0 -. -.SH "Link Packages" -\fBnpm link\fR 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 \fBnpm rebuild \-g\fR to update compiled packages, -of course\.) -. -.P -More info at \fBnpm help link\fR\|\. -. -.SH "Before Publishing: Make Sure Your Package Installs and Works" -\fBThis is important\.\fR -. -.P -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\. -. -.P -In the root of your package, do this: -. -.IP "" 4 -. -.nf -npm install \. \-g -. -.fi -. -.IP "" 0 -. -.P -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: -. -.IP "" 4 -. -.nf -npm link -. -.fi -. -.IP "" 0 -. -.P -Use \fBnpm ls \-g\fR to see if it\'s there\. -. -.P -To test a local install, go into some other folder, and then do: -. -.IP "" 4 -. -.nf -cd \.\./some\-other\-folder -npm install \.\./my\-package -. -.fi -. -.IP "" 0 -. -.P -to install it locally into the node_modules folder in that other place\. -. -.P -Then go into the node\-repl, and try using require("my\-thing") to -bring in your module\'s main module\. -. -.SH "Create a User Account" -Create a user with the adduser command\. It works like this: -. -.IP "" 4 -. -.nf -npm adduser -. -.fi -. -.IP "" 0 -. -.P -and then follow the prompts\. -. -.P -This is documented better in npm help adduser\. -. -.SH "Publish your package" -This part\'s easy\. IN the root of your folder, do this: -. -.IP "" 4 -. -.nf -npm publish -. -.fi -. -.IP "" 0 -. -.P -You can give publish a url to a tarball, or a filename of a tarball, -or a path to a folder\. -. -.P -Note that pretty much \fBeverything in that folder will be exposed\fR -by default\. So, if you have secret stuff in there, use a \fB\|\.npmignore\fR file to list out the globs to ignore, or publish -from a fresh checkout\. -. -.SH "Brag about it" -Send emails, write blogs, blab in IRC\. -. -.P -Tell the world how easy it is to install your program! -. -.SH "SEE ALSO" -. -.IP "\(bu" 4 -npm help faq -. -.IP "\(bu" 4 -npm help npm -. -.IP "\(bu" 4 -npm help init -. -.IP "\(bu" 4 -npm help json -. -.IP "\(bu" 4 -npm help scripts -. -.IP "\(bu" 4 -npm help publish -. -.IP "\(bu" 4 -npm help adduser -. -.IP "\(bu" 4 -npm help registry -. -.IP "" 0 - diff --git a/deps/npm/man/man1/disputes.1 b/deps/npm/man/man1/disputes.1 deleted file mode 100644 index 5a3c49bb7..000000000 --- a/deps/npm/man/man1/disputes.1 +++ /dev/null @@ -1,145 +0,0 @@ -.\" Generated with Ronnjs 0.3.8 -.\" http://github.com/kapouer/ronnjs/ -. -.TH "NPM\-DISPUTES" "1" "July 2013" "" "" -. -.SH "NAME" -\fBnpm-disputes\fR \-\- Handling Module Name Disputes -. -.SH "SYNOPSIS" -. -.IP "1" 4 -Get the author email with \fBnpm owner ls \fR -. -.IP "2" 4 -Email the author, CC \fIi@izs\.me\fR\|\. -. -.IP "3" 4 -After a few weeks, if there\'s no resolution, we\'ll sort it out\. -. -.IP "" 0 -. -.P -Don\'t squat on package names\. Publish code or move out of the way\. -. -.SH "DESCRIPTION" -There sometimes arise cases where a user publishes a module, and then -later, some other user wants to use that name\. Here are some common -ways that happens (each of these is based on actual events\.) -. -.IP "1" 4 -Joe writes a JavaScript module \fBfoo\fR, which is not node\-specific\. -Joe doesn\'t use node at all\. Bob wants to use \fBfoo\fR in node, so he -wraps it in an npm module\. Some time later, Joe starts using node, -and wants to take over management of his program\. -. -.IP "2" 4 -Bob writes an npm module \fBfoo\fR, and publishes it\. Perhaps much -later, Joe finds a bug in \fBfoo\fR, and fixes it\. He sends a pull -request to Bob, but Bob doesn\'t have the time to deal with it, -because he has a new job and a new baby and is focused on his new -erlang project, and kind of not involved with node any more\. Joe -would like to publish a new \fBfoo\fR, but can\'t, because the name is -taken\. -. -.IP "3" 4 -Bob writes a 10\-line flow\-control library, and calls it \fBfoo\fR, and -publishes it to the npm registry\. Being a simple little thing, it -never really has to be updated\. Joe works for Foo Inc, the makers -of the critically acclaimed and widely\-marketed \fBfoo\fR JavaScript -toolkit framework\. They publish it to npm as \fBfoojs\fR, but people are -routinely confused when \fBnpm install foo\fR is some different thing\. -. -.IP "4" 4 -Bob writes a parser for the widely\-known \fBfoo\fR file format, because -he needs it for work\. Then, he gets a new job, and never updates the -prototype\. Later on, Joe writes a much more complete \fBfoo\fR parser, -but can\'t publish, because Bob\'s \fBfoo\fR is in the way\. -. -.IP "" 0 -. -.P -The validity of Joe\'s claim in each situation can be debated\. However, -Joe\'s appropriate course of action in each case is the same\. -. -.IP "1" 4 -\fBnpm owner ls foo\fR\|\. This will tell Joe the email address of the -owner (Bob)\. -. -.IP "2" 4 -Joe emails Bob, explaining the situation \fBas respectfully as possible\fR, -and what he would like to do with the module name\. He adds -isaacs \fIi@izs\.me\fR to the CC list of the email\. Mention in the email -that Bob can run \fBnpm owner add joe foo\fR to add Joe as an owner of -the \fBfoo\fR package\. -. -.IP "3" 4 -After a reasonable amount of time, if Bob has not responded, or if -Bob and Joe can\'t come to any sort of resolution, email isaacs \fIi@izs\.me\fR and we\'ll sort it out\. ("Reasonable" is usually about 4 -weeks, but extra time is allowed around common holidays\.) -. -.IP "" 0 -. -.SH "REASONING" -In almost every case so far, the parties involved have been able to reach -an amicable resolution without any major intervention\. Most people -really do want to be reasonable, and are probably not even aware that -they\'re in your way\. -. -.P -Module ecosystems are most vibrant and powerful when they are as -self\-directed as possible\. If an admin one day deletes something you -had worked on, then that is going to make most people quite upset, -regardless of the justification\. When humans solve their problems by -talking to other humans with respect, everyone has the chance to end up -feeling good about the interaction\. -. -.SH "EXCEPTIONS" -Some things are not allowed, and will be removed without discussion if -they are brought to the attention of the npm registry admins, including -but not limited to: -. -.IP "1" 4 -Malware (that is, a package designed to exploit or harm the machine on -which it is installed)\. -. -.IP "2" 4 -Violations of copyright or licenses (for example, cloning an -MIT\-licensed program, and then removing or changing the copyright and -license statement)\. -. -.IP "3" 4 -Illegal content\. -. -.IP "4" 4 -"Squatting" on a package name that you \fIplan\fR to use, but aren\'t -actually using\. Sorry, I don\'t care how great the name is, or how -perfect a fit it is for the thing that someday might happen\. If -someone wants to use it today, and you\'re just taking up space with -an empty tarball, you\'re going to be evicted\. -. -.IP "5" 4 -Putting empty packages in the registry\. Packages must have SOME -functionality\. It can be silly, but it can\'t be \fInothing\fR\|\. (See -also: squatting\.) -. -.IP "6" 4 -Doing weird things with the registry, like using it as your own -personal application database or otherwise putting non\-packagey -things into it\. -. -.IP "" 0 -. -.P -If you see bad behavior like this, please report it right away\. -. -.SH "SEE ALSO" -. -.IP "\(bu" 4 -npm help registry -. -.IP "\(bu" 4 -npm help owner -. -.IP "" 0 - diff --git a/deps/npm/man/man1/docs.1 b/deps/npm/man/man1/docs.1 deleted file mode 100644 index 2c9c4867e..000000000 --- a/deps/npm/man/man1/docs.1 +++ /dev/null @@ -1,68 +0,0 @@ -.\" Generated with Ronnjs 0.3.8 -.\" http://github.com/kapouer/ronnjs/ -. -.TH "NPM\-DOCS" "1" "July 2013" "" "" -. -.SH "NAME" -\fBnpm-docs\fR \-\- Docs for a package in a web browser maybe -. -.SH "SYNOPSIS" -. -.nf -npm docs -npm home -. -.fi -. -.SH "DESCRIPTION" -This command tries to guess at the likely location of a package\'s -documentation URL, and then tries to open it using the \fB\-\-browser\fR -config param\. -. -.SH "CONFIGURATION" -. -.SS "browser" -. -.IP "\(bu" 4 -Default: OS X: \fB"open"\fR, Windows: \fB"start"\fR, Others: \fB"xdg\-open"\fR -. -.IP "\(bu" 4 -Type: String -. -.IP "" 0 -. -.P -The browser that is called by the \fBnpm docs\fR command to open websites\. -. -.SS "registry" -. -.IP "\(bu" 4 -Default: https://registry\.npmjs\.org/ -. -.IP "\(bu" 4 -Type: url -. -.IP "" 0 -. -.P -The base URL of the npm package registry\. -. -.SH "SEE ALSO" -. -.IP "\(bu" 4 -npm help view -. -.IP "\(bu" 4 -npm help publish -. -.IP "\(bu" 4 -npm help registry -. -.IP "\(bu" 4 -npm help config -. -.IP "\(bu" 4 -npm help json -. -.IP "" 0 - diff --git a/deps/npm/man/man1/edit.1 b/deps/npm/man/man1/edit.1 deleted file mode 100644 index ad660f207..000000000 --- a/deps/npm/man/man1/edit.1 +++ /dev/null @@ -1,60 +0,0 @@ -.\" Generated with Ronnjs 0.3.8 -.\" http://github.com/kapouer/ronnjs/ -. -.TH "NPM\-EDIT" "1" "July 2013" "" "" -. -.SH "NAME" -\fBnpm-edit\fR \-\- Edit an installed package -. -.SH "SYNOPSIS" -. -.nf -npm edit [@] -. -.fi -. -.SH "DESCRIPTION" -Opens the package folder in the default editor (or whatever you\'ve -configured as the npm \fBeditor\fR config \-\- see \fBnpm help config\fR\|\.) -. -.P -After it has been edited, the package is rebuilt so as to pick up any -changes in compiled packages\. -. -.P -For instance, you can do \fBnpm install connect\fR to install connect -into your package, and then \fBnpm edit connect\fR to make a few -changes to your locally installed copy\. -. -.SH "CONFIGURATION" -. -.SS "editor" -. -.IP "\(bu" 4 -Default: \fBEDITOR\fR environment variable if set, or \fB"vi"\fR on Posix, -or \fB"notepad"\fR on Windows\. -. -.IP "\(bu" 4 -Type: path -. -.IP "" 0 -. -.P -The command to run for \fBnpm edit\fR or \fBnpm config edit\fR\|\. -. -.SH "SEE ALSO" -. -.IP "\(bu" 4 -npm help folders -. -.IP "\(bu" 4 -npm help explore -. -.IP "\(bu" 4 -npm help install -. -.IP "\(bu" 4 -npm help config -. -.IP "" 0 - diff --git a/deps/npm/man/man1/explore.1 b/deps/npm/man/man1/explore.1 deleted file mode 100644 index d4260fc83..000000000 --- a/deps/npm/man/man1/explore.1 +++ /dev/null @@ -1,76 +0,0 @@ -.\" Generated with Ronnjs 0.3.8 -.\" http://github.com/kapouer/ronnjs/ -. -.TH "NPM\-EXPLORE" "1" "July 2013" "" "" -. -.SH "NAME" -\fBnpm-explore\fR \-\- Browse an installed package -. -.SH "SYNOPSIS" -. -.nf -npm explore [@] [ \-\- ] -. -.fi -. -.SH "DESCRIPTION" -Spawn a subshell in the directory of the installed package specified\. -. -.P -If a command is specified, then it is run in the subshell, which then -immediately terminates\. -. -.P -This is particularly handy in the case of git submodules in the \fBnode_modules\fR folder: -. -.IP "" 4 -. -.nf -npm explore some\-dependency \-\- git pull origin master -. -.fi -. -.IP "" 0 -. -.P -Note that the package is \fInot\fR automatically rebuilt afterwards, so be -sure to use \fBnpm rebuild \fR if you make any changes\. -. -.SH "CONFIGURATION" -. -.SS "shell" -. -.IP "\(bu" 4 -Default: SHELL environment variable, or "bash" on Posix, or "cmd" on -Windows -. -.IP "\(bu" 4 -Type: path -. -.IP "" 0 -. -.P -The shell to run for the \fBnpm explore\fR command\. -. -.SH "SEE ALSO" -. -.IP "\(bu" 4 -npm help submodule -. -.IP "\(bu" 4 -npm help folders -. -.IP "\(bu" 4 -npm help edit -. -.IP "\(bu" 4 -npm help rebuild -. -.IP "\(bu" 4 -npm help build -. -.IP "\(bu" 4 -npm help install -. -.IP "" 0 - diff --git a/deps/npm/man/man1/faq.1 b/deps/npm/man/man1/faq.1 deleted file mode 100644 index 04e0307f4..000000000 --- a/deps/npm/man/man1/faq.1 +++ /dev/null @@ -1,459 +0,0 @@ -.\" Generated with Ronnjs 0.3.8 -.\" http://github.com/kapouer/ronnjs/ -. -.TH "NPM\-FAQ" "1" "July 2013" "" "" -. -.SH "NAME" -\fBnpm-faq\fR \-\- Frequently Asked Questions -. -.SH "Where can I find these docs in HTML?" -\fIhttps://npmjs\.org/doc/\fR, or run: -. -.IP "" 4 -. -.nf -npm config set viewer browser -. -.fi -. -.IP "" 0 -. -.P -to open these documents in your default web browser rather than \fBman\fR\|\. -. -.SH "It didn't work\." -That\'s not really a question\. -. -.SH "Why didn't it work?" -I don\'t know yet\. -. -.P -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\. -. -.SH "Where does npm put stuff?" -See \fBnpm help folders\fR -. -.P -tl;dr: -. -.IP "\(bu" 4 -Use the \fBnpm root\fR command to see where modules go, and the \fBnpm bin\fR -command to see where executables go -. -.IP "\(bu" 4 -Global installs are different from local installs\. If you install -something with the \fB\-g\fR flag, then its executables go in \fBnpm bin \-g\fR -and its modules go in \fBnpm root \-g\fR\|\. -. -.IP "" 0 -. -.SH "How do I install something on my computer in a central location?" -Install it globally by tacking \fB\-g\fR or \fB\-\-global\fR to the command\. (This -is especially important for command line utilities that need to add -their bins to the global system \fBPATH\fR\|\.) -. -.SH "I installed something globally, but I can't " -Install it locally\. -. -.P -The global install location is a place for command\-line utilities -to put their bins in the system \fBPATH\fR\|\. It\'s not for use with \fBrequire()\fR\|\. -. -.P -If you \fBrequire()\fR a module in your code, then that means it\'s a -dependency, and a part of your program\. You need to install it locally -in your program\. -. -.SH "Why can't npm just put everything in one place, like other package managers?" -Not every change is an improvement, but every improvement is a change\. -This would be like asking git to do network IO for every commit\. It\'s -not going to happen, because it\'s a terrible idea that causes more -problems than it solves\. -. -.P -It is much harder to avoid dependency conflicts without nesting -dependencies\. This is fundamental to the way that npm works, and has -proven to be an extremely successful approach\. See \fBnpm help folders\fR for -more details\. -. -.P -If you want a package to be installed in one place, and have all your -programs reference the same copy of it, then use the \fBnpm link\fR command\. -That\'s what it\'s for\. Install it globally, then link it into each -program that uses it\. -. -.SH "Whatever, I really want the old style 'everything global' style\." -Write your own package manager, then\. It\'s not that hard\. -. -.P -npm will not help you do something that is known to be a bad idea\. -. -.SH "Should I check my " -Mikeal Rogers answered this question very well: -. -.P -\fIhttp://www\.mikealrogers\.com/posts/nodemodules\-in\-git\.html\fR -. -.P -tl;dr -. -.IP "\(bu" 4 -Check \fBnode_modules\fR into git for things you \fBdeploy\fR, such as -websites and apps\. -. -.IP "\(bu" 4 -Do not check \fBnode_modules\fR into git for libraries and modules -intended to be reused\. -. -.IP "\(bu" 4 -Use npm to manage dependencies in your dev environment, but not in -your deployment scripts\. -. -.IP "" 0 -. -.SH "Is it 'npm' or 'NPM' or 'Npm'?" -npm should never be capitalized unless it is being displayed in a -location that is customarily all\-caps (such as the title of man pages\.) -. -.SH "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\.) -. -.P -"NPM", however, \fIis\fR an acronym (more precisely, a capitonym) for the -National Association of Pastoral Musicians\. You can learn more -about them at \fIhttp://npm\.org/\fR\|\. -. -.P -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 \fIhttp://www\.cabiatl\.com/mricro/npm/\fR\|\. -. -.P -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 \fByinst\fR\|\. If \fBnpm\fR was ever an -acronym for anything, it was \fBnode pm\fR or maybe \fBnew pm\fR\|\. -. -.P -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 \fB\-\fR 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\. -. -.SH "How do I list installed packages?" -\fBnpm ls\fR -. -.SH "How do I search for packages?" -\fBnpm search\fR -. -.P -Arguments are greps\. \fBnpm search jsdom\fR shows jsdom packages\. -. -.SH "How do I update npm?" -. -.nf -npm update npm \-g -. -.fi -. -.P -You can also update all outdated local packages by doing \fBnpm update\fR without -any arguments, or global packages by doing \fBnpm update \-g\fR\|\. -. -.P -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 \fBupdate\fR -command\.) -. -.P -In those cases, you can do this: -. -.IP "" 4 -. -.nf -curl https://npmjs\.org/install\.sh | sh -. -.fi -. -.IP "" 0 -. -.SH "What is a " -A package is: -. -.IP "\(bu" 4 -a) a folder containing a program described by a package\.json file -. -.IP "\(bu" 4 -b) a gzipped tarball containing (a) -. -.IP "\(bu" 4 -c) a url that resolves to (b) -. -.IP "\(bu" 4 -d) a \fB@\fR that is published on the registry with (c) -. -.IP "\(bu" 4 -e) a \fB@\fR that points to (d) -. -.IP "\(bu" 4 -f) a \fB\fR that has a "latest" tag satisfying (e) -. -.IP "\(bu" 4 -g) a \fBgit\fR url that, when cloned, results in (a)\. -. -.IP "" 0 -. -.P -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)\. -. -.P -Git urls can be of the form: -. -.IP "" 4 -. -.nf -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 -. -.fi -. -.IP "" 0 -. -.P -The \fBcommit\-ish\fR can be any tag, sha, or branch which can be supplied as -an argument to \fBgit checkout\fR\|\. The default is \fBmaster\fR\|\. -. -.SH "What is a " -A module is anything that can be loaded with \fBrequire()\fR in a Node\.js -program\. The following things are all examples of things that can be -loaded as modules: -. -.IP "\(bu" 4 -A folder with a \fBpackage\.json\fR file containing a \fBmain\fR field\. -. -.IP "\(bu" 4 -A folder with an \fBindex\.js\fR file in it\. -. -.IP "\(bu" 4 -A JavaScript file\. -. -.IP "" 0 -. -.P -Most npm packages are modules, because they are libraries that you -load with \fBrequire\fR\|\. However, there\'s no requirement that an npm -package be a module! Some only contain an executable command\-line -interface, and don\'t provide a \fBmain\fR field for use in Node programs\. -. -.P -Almost all npm packages (at least, those that are Node programs) \fIcontain\fR many modules within them (because every file they load with \fBrequire()\fR is a module)\. -. -.P -In the context of a Node program, the \fBmodule\fR is also the thing that -was loaded \fIfrom\fR a file\. For example, in the following program: -. -.IP "" 4 -. -.nf -var req = require(\'request\') -. -.fi -. -.IP "" 0 -. -.P -we might say that "The variable \fBreq\fR refers to the \fBrequest\fR module"\. -. -.SH "So, why is it the "" -The \fBpackage\.json\fR file defines the package\. (See "What is a -package?" above\.) -. -.P -The \fBnode_modules\fR folder is the place Node\.js looks for modules\. -(See "What is a module?" above\.) -. -.P -For example, if you create a file at \fBnode_modules/foo\.js\fR and then -had a program that did \fBvar f = require(\'foo\.js\')\fR then it would load -the module\. However, \fBfoo\.js\fR is not a "package" in this case, -because it does not have a package\.json\. -. -.P -Alternatively, if you create a package which does not have an \fBindex\.js\fR or a \fB"main"\fR field in the \fBpackage\.json\fR file, then it is -not a module\. Even if it\'s installed in \fBnode_modules\fR, it can\'t be -an argument to \fBrequire()\fR\|\. -. -.SH ""node_modules"" -No\. This will never happen\. This question comes up sometimes, -because it seems silly from the outside that npm couldn\'t just be -configured to put stuff somewhere else, and then npm could load them -from there\. It\'s an arbitrary spelling choice, right? What\'s the big -deal? -. -.P -At the time of this writing, the string \fB\'node_modules\'\fR appears 151 -times in 53 separate files in npm and node core (excluding tests and -documentation)\. -. -.P -Some of these references are in node\'s built\-in module loader\. Since -npm is not involved \fBat all\fR at run\-time, node itself would have to -be configured to know where you\'ve decided to stick stuff\. Complexity -hurdle #1\. Since the Node module system is locked, this cannot be -changed, and is enough to kill this request\. But I\'ll continue, in -deference to your deity\'s delicate feelings regarding spelling\. -. -.P -Many of the others are in dependencies that npm uses, which are not -necessarily tightly coupled to npm (in the sense that they do not read -npm\'s configuration files, etc\.) Each of these would have to be -configured to take the name of the \fBnode_modules\fR folder as a -parameter\. Complexity hurdle #2\. -. -.P -Furthermore, npm has the ability to "bundle" dependencies by adding -the dep names to the \fB"bundledDependencies"\fR list in package\.json, -which causes the folder to be included in the package tarball\. What -if the author of a module bundles its dependencies, and they use a -different spelling for \fBnode_modules\fR? npm would have to rename the -folder at publish time, and then be smart enough to unpack it using -your locally configured name\. Complexity hurdle #3\. -. -.P -Furthermore, what happens when you \fIchange\fR this name? Fine, it\'s -easy enough the first time, just rename the \fBnode_modules\fR folders to \fB\|\./blergyblerp/\fR or whatever name you choose\. But what about when you -change it again? npm doesn\'t currently track any state about past -configuration settings, so this would be rather difficult to do -properly\. It would have to track every previous value for this -config, and always accept any of them, or else yesterday\'s install may -be broken tomorrow\. Complexity hurdle #5\. -. -.P -Never going to happen\. The folder is named \fBnode_modules\fR\|\. It is -written indelibly in the Node Way, handed down from the ancient times -of Node 0\.3\. -. -.SH "How do I install node with npm?" -You don\'t\. Try one of these node version managers: -. -.P -Unix: -. -.IP "\(bu" 4 -\fIhttp://github\.com/isaacs/nave\fR -. -.IP "\(bu" 4 -\fIhttp://github\.com/visionmedia/n\fR -. -.IP "\(bu" 4 -\fIhttp://github\.com/creationix/nvm\fR -. -.IP "" 0 -. -.P -Windows: -. -.IP "\(bu" 4 -\fIhttp://github\.com/marcelklehr/nodist\fR -. -.IP "\(bu" 4 -\fIhttps://github\.com/hakobera/nvmw\fR -. -.IP "" 0 -. -.SH "How can I use npm for development?" -See \fBnpm help developers\fR and \fBnpm help json\fR\|\. -. -.P -You\'ll most likely want to \fBnpm link\fR your development folder\. That\'s -awesomely handy\. -. -.P -To set up your own private registry, check out \fBnpm help registry\fR\|\. -. -.SH "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\.) -. -.SH "How do I symlink to a dev folder so I don't have to keep re\-installing?" -See \fBnpm help link\fR -. -.SH "The package registry website\. What is that exactly?" -See \fBnpm help registry\fR\|\. -. -.SH "I forgot my password, and can't publish\. How do I reset it?" -Go to \fIhttps://npmjs\.org/forgot\fR\|\. -. -.SH "I get ECONNREFUSED a lot\. What's up?" -Either the registry is down, or node\'s DNS isn\'t able to reach out\. -. -.P -To check if the registry is down, open up \fIhttp://registry\.npmjs\.org/\fR -in a web browser\. This will also tell you if you are just unable to -access the internet for some reason\. -. -.P -If the registry IS down, let me know by emailing \fIi@izs\.me\fR or posting -an issue at \fIhttps://github\.com/isaacs/npm/issues\fR\|\. We\'ll have -someone kick it or something\. -. -.SH "Why no namespaces?" -Please see this discussion: \fIhttps://github\.com/isaacs/npm/issues/798\fR -. -.P -tl;dr \- It doesn\'t actually make things better, and can make them worse\. -. -.P -If you want to namespace your own packages, you may: simply use the \fB\-\fR character to separate the names\. npm is a mostly anarchic system\. -There is not sufficient need to impose namespace rules on everyone\. -. -.SH "Who does npm?" -\fBnpm view npm author\fR -. -.P -\fBnpm view npm contributors\fR -. -.SH "I have a question or request not addressed here\. Where should I put it?" -Post an issue on the github project: -. -.IP "\(bu" 4 -\fIhttps://github\.com/isaacs/npm/issues\fR -. -.IP "" 0 -. -.SH "Why does npm hate me?" -npm is not capable of hatred\. It loves everyone, especially you\. -. -.SH "SEE ALSO" -. -.IP "\(bu" 4 -npm help npm -. -.IP "\(bu" 4 -npm help developers -. -.IP "\(bu" 4 -npm help json -. -.IP "\(bu" 4 -npm help config -. -.IP "\(bu" 4 -npm help folders -. -.IP "" 0 - diff --git a/deps/npm/man/man1/find.1 b/deps/npm/man/man1/find.1 deleted file mode 100644 index 653597ffa..000000000 --- a/deps/npm/man/man1/find.1 +++ /dev/null @@ -1,72 +0,0 @@ -.\" Generated with Ronnjs/v0.1 -.\" http://github.com/kapouer/ronnjs/ -. -.TH "NPM\-SEARCH" "1" "November 2011" "" "" -. -.SH "NAME" -\fBnpm-search\fR \-\- Search for packages -. -.SH "SYNOPSIS" -. -.nf -npm search [search terms \.\.\.] -. -.fi -. -.SH "DESCRIPTION" -Search the registry for packages matching the search terms\. -. -.SH "CONFIGURATION" -. -.SS "description" -. -.IP "\(bu" 4 -Default: true -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Show the description in \fBnpm search\fR -. -.SS "searchopts" -. -.IP "\(bu" 4 -Default: "" -. -.IP "\(bu" 4 -Type: String -. -.IP "" 0 -. -.P -Space\-separated options that are always passed to search\. -. -.SS "searchexclude" -. -.IP "\(bu" 4 -Default: "" -. -.IP "\(bu" 4 -Type: String -. -.IP "" 0 -. -.P -Space\-separated options that limit the results from search\. -. -.SH "SEE ALSO" -. -.IP "\(bu" 4 -npm help registry -. -.IP "\(bu" 4 -npm help config -. -.IP "\(bu" 4 -npm help view -. -.IP "" 0 - diff --git a/deps/npm/man/man1/folders.1 b/deps/npm/man/man1/folders.1 deleted file mode 100644 index b213d52a6..000000000 --- a/deps/npm/man/man1/folders.1 +++ /dev/null @@ -1,258 +0,0 @@ -.\" Generated with Ronnjs 0.3.8 -.\" http://github.com/kapouer/ronnjs/ -. -.TH "NPM\-FOLDERS" "1" "July 2013" "" "" -. -.SH "NAME" -\fBnpm-folders\fR \-\- Folder Structures Used by npm -. -.SH "DESCRIPTION" -npm puts various things on your computer\. That\'s its job\. -. -.P -This document will tell you what it puts where\. -. -.SS "tl;dr" -. -.IP "\(bu" 4 -Local install (default): puts stuff in \fB\|\./node_modules\fR of the current -package root\. -. -.IP "\(bu" 4 -Global install (with \fB\-g\fR): puts stuff in /usr/local or wherever node -is installed\. -. -.IP "\(bu" 4 -Install it \fBlocally\fR if you\'re going to \fBrequire()\fR it\. -. -.IP "\(bu" 4 -Install it \fBglobally\fR if you\'re going to run it on the command line\. -. -.IP "\(bu" 4 -If you need both, then install it in both places, or use \fBnpm link\fR\|\. -. -.IP "" 0 -. -.SS "prefix Configuration" -The \fBprefix\fR config defaults to the location where node is installed\. -On most systems, this is \fB/usr/local\fR, and most of the time is the same -as node\'s \fBprocess\.installPrefix\fR\|\. -. -.P -On windows, this is the exact location of the node\.exe binary\. On Unix -systems, it\'s one level up, since node is typically installed at \fB{prefix}/bin/node\fR rather than \fB{prefix}/node\.exe\fR\|\. -. -.P -When the \fBglobal\fR 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\. -. -.SS "Node Modules" -Packages are dropped into the \fBnode_modules\fR folder under the \fBprefix\fR\|\. -When installing locally, this means that you can \fBrequire("packagename")\fR to load its main module, or \fBrequire("packagename/lib/path/to/sub/module")\fR to load other modules\. -. -.P -Global installs on Unix systems go to \fB{prefix}/lib/node_modules\fR\|\. -Global installs on Windows go to \fB{prefix}/node_modules\fR (that is, no \fBlib\fR folder\.) -. -.P -If you wish to \fBrequire()\fR a package, then install it locally\. -. -.SS "Executables" -When in global mode, executables are linked into \fB{prefix}/bin\fR on Unix, -or directly into \fB{prefix}\fR on Windows\. -. -.P -When in local mode, executables are linked into \fB\|\./node_modules/\.bin\fR 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 \fBnpm test\fR\|\.) -. -.SS "Man Pages" -When in global mode, man pages are linked into \fB{prefix}/share/man\fR\|\. -. -.P -When in local mode, man pages are not installed\. -. -.P -Man pages are not installed on Windows systems\. -. -.SS "Cache" -See \fBnpm help cache\fR\|\. Cache files are stored in \fB~/\.npm\fR on Posix, or \fB~/npm\-cache\fR on Windows\. -. -.P -This is controlled by the \fBcache\fR configuration param\. -. -.SS "Temp Files" -Temporary files are stored by default in the folder specified by the \fBtmp\fR config, which defaults to the TMPDIR, TMP, or TEMP environment -variables, or \fB/tmp\fR on Unix and \fBc:\\windows\\temp\fR on Windows\. -. -.P -Temp files are given a unique folder under this root for each run of the -program, and are deleted upon successful exit\. -. -.SH "More Information" -When installing locally, npm first tries to find an appropriate \fBprefix\fR folder\. This is so that \fBnpm install foo@1\.2\.3\fR will install -to the sensible root of your package, even if you happen to have \fBcd\fRed -into some other folder\. -. -.P -Starting at the $PWD, npm will walk up the folder tree checking for a -folder that contains either a \fBpackage\.json\fR file, or a \fBnode_modules\fR -folder\. If such a thing is found, then that is treated as the effective -"current directory" for the purpose of running npm commands\. (This -behavior is inspired by and similar to git\'s \.git\-folder seeking -logic when running git commands in a working dir\.) -. -.P -If no package root is found, then the current folder is used\. -. -.P -When you run \fBnpm install foo@1\.2\.3\fR, then the package is loaded into -the cache, and then unpacked into \fB\|\./node_modules/foo\fR\|\. Then, any of -foo\'s dependencies are similarly unpacked into \fB\|\./node_modules/foo/node_modules/\.\.\.\fR\|\. -. -.P -Any bin files are symlinked to \fB\|\./node_modules/\.bin/\fR, so that they may -be found by npm scripts when necessary\. -. -.SS "Global Installation" -If the \fBglobal\fR configuration is set to true, then npm will -install packages "globally"\. -. -.P -For global installation, packages are installed roughly the same way, -but using the folders described above\. -. -.SS "Cycles, Conflicts, and Folder Parsimony" -Cycles are handled using the property of node\'s module system that it -walks up the directories looking for \fBnode_modules\fR folders\. So, at every -stage, if a package is already installed in an ancestor \fBnode_modules\fR -folder, then it is not installed at the current location\. -. -.P -Consider the case above, where \fBfoo \-> bar \-> baz\fR\|\. Imagine if, in -addition to that, baz depended on bar, so you\'d have: \fBfoo \-> bar \-> baz \-> bar \-> baz \.\.\.\fR\|\. However, since the folder -structure is: \fBfoo/node_modules/bar/node_modules/baz\fR, there\'s no need to -put another copy of bar into \fB\|\.\.\./baz/node_modules\fR, since when it calls -require("bar"), it will get the copy that is installed in \fBfoo/node_modules/bar\fR\|\. -. -.P -This shortcut is only used if the exact same -version would be installed in multiple nested \fBnode_modules\fR folders\. It -is still possible to have \fBa/node_modules/b/node_modules/a\fR if the two -"a" packages are different versions\. However, without repeating the -exact same package multiple times, an infinite regress will always be -prevented\. -. -.P -Another optimization can be made by installing dependencies at the -highest level possible, below the localized "target" folder\. -. -.SS "\fIExample\fR" -Consider this dependency graph: -. -.IP "" 4 -. -.nf -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 -. -.fi -. -.IP "" 0 -. -.P -In this case, we might expect a folder structure like this: -. -.IP "" 4 -. -.nf -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] -. -.fi -. -.IP "" 0 -. -.P -Since foo depends directly on \fBbar@1\.2\.3\fR and \fBbaz@1\.2\.3\fR, those are -installed in foo\'s \fBnode_modules\fR folder\. -. -.P -Even though the latest copy of blerg is 1\.3\.7, foo has a specific -dependency on version 1\.2\.5\. So, that gets installed at [A]\. Since the -parent installation of blerg satisfies bar\'s dependency on \fBblerg@1\.x\fR, -it does not install another copy under [B]\. -. -.P -Bar [B] also has dependencies on baz and asdf, so those are installed in -bar\'s \fBnode_modules\fR folder\. Because it depends on \fBbaz@2\.x\fR, it cannot -re\-use the \fBbaz@1\.2\.3\fR installed in the parent \fBnode_modules\fR folder [D], -and must install its own copy [C]\. -. -.P -Underneath bar, the \fBbaz \-> quux \-> bar\fR 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\. -. -.P -Underneath \fBfoo \-> baz\fR [D], quux\'s [E] folder tree is empty, because its -dependency on bar is satisfied by the parent folder copy installed at [B]\. -. -.P -For a graphical breakdown of what is installed where, use \fBnpm ls\fR\|\. -. -.SS "Publishing" -Upon publishing, npm will look in the \fBnode_modules\fR folder\. If any of -the items there are not in the \fBbundledDependencies\fR array, then they will -not be included in the package tarball\. -. -.P -This allows a package maintainer to install all of their dependencies -(and dev dependencies) locally, but only re\-publish those items that -cannot be found elsewhere\. See \fBnpm help json\fR for more information\. -. -.SH "SEE ALSO" -. -.IP "\(bu" 4 -npm help faq -. -.IP "\(bu" 4 -npm help json -. -.IP "\(bu" 4 -npm help install -. -.IP "\(bu" 4 -npm help pack -. -.IP "\(bu" 4 -npm help cache -. -.IP "\(bu" 4 -npm help config -. -.IP "\(bu" 4 -npm help publish -. -.IP "" 0 - diff --git a/deps/npm/man/man1/get.1 b/deps/npm/man/man1/get.1 deleted file mode 100644 index 5075c9f0c..000000000 --- a/deps/npm/man/man1/get.1 +++ /dev/null @@ -1,1154 +0,0 @@ -.\" Generated with Ronnjs/v0.1 -.\" http://github.com/kapouer/ronnjs/ -. -.TH "NPM\-CONFIG" "1" "November 2011" "" "" -. -.SH "NAME" -\fBnpm-config\fR \-\- Manage the npm configuration file -. -.SH "SYNOPSIS" -. -.nf -npm config set [\-\-global] -npm config get -npm config delete -npm config list -npm config edit -npm get -npm set [\-\-global] -. -.fi -. -.SH "DESCRIPTION" -npm gets its configuration values from 6 sources, in this priority: -. -.SS "Command Line Flags" -Putting \fB\-\-foo bar\fR on the command line sets the \fBfoo\fR configuration parameter to \fB"bar"\fR\|\. A \fB\-\-\fR argument tells the cli -parser to stop reading flags\. A \fB\-\-flag\fR parameter that is at the \fIend\fR of -the command will be given the value of \fBtrue\fR\|\. -. -.SS "Environment Variables" -Any environment variables that start with \fBnpm_config_\fR will be interpreted -as a configuration parameter\. For example, putting \fBnpm_config_foo=bar\fR in -your environment will set the \fBfoo\fR configuration parameter to \fBbar\fR\|\. Any -environment configurations that are not given a value will be given the value -of \fBtrue\fR\|\. Config values are case\-insensitive, so \fBNPM_CONFIG_FOO=bar\fR will -work the same\. -. -.SS "Per\-user config file" -\fB$HOME/\.npmrc\fR (or the \fBuserconfig\fR param, if set above) -. -.P -This file is an ini\-file formatted list of \fBkey = value\fR parameters\. -. -.SS "Global config file" -\fB$PREFIX/etc/npmrc\fR (or the \fBglobalconfig\fR param, if set above): -This file is an ini\-file formatted list of \fBkey = value\fR parameters -. -.SS "Built\-in config file" -\fBpath/to/npm/itself/npmrc\fR -. -.P -This is an unchangeable "builtin" -configuration file that npm keeps consistent across updates\. Set -fields in here using the \fB\|\./configure\fR script that comes with npm\. -This is primarily for distribution maintainers to override default -configs in a standard and consistent manner\. -. -.SS "Default Configs" -A set of configuration parameters that are internal to npm, and are -defaults if nothing else is specified\. -. -.SH "Sub\-commands" -Config supports the following sub\-commands: -. -.SS "set" -. -.nf -npm config set key value -. -.fi -. -.P -Sets the config key to the value\. -. -.P -If value is omitted, then it sets it to "true"\. -. -.SS "get" -. -.nf -npm config get key -. -.fi -. -.P -Echo the config value to stdout\. -. -.SS "list" -. -.nf -npm config list -. -.fi -. -.P -Show all the config settings\. -. -.SS "delete" -. -.nf -npm config delete key -. -.fi -. -.P -Deletes the key from all configuration files\. -. -.SS "edit" -. -.nf -npm config edit -. -.fi -. -.P -Opens the config file in an editor\. Use the \fB\-\-global\fR flag to edit the -global config\. -. -.SH "Shorthands and Other CLI Niceties" -The following shorthands are parsed on the command\-line: -. -.IP "\(bu" 4 -\fB\-v\fR: \fB\-\-version\fR -. -.IP "\(bu" 4 -\fB\-h\fR, \fB\-?\fR, \fB\-\-help\fR, \fB\-H\fR: \fB\-\-usage\fR -. -.IP "\(bu" 4 -\fB\-s\fR, \fB\-\-silent\fR: \fB\-\-loglevel silent\fR -. -.IP "\(bu" 4 -\fB\-d\fR: \fB\-\-loglevel info\fR -. -.IP "\(bu" 4 -\fB\-dd\fR, \fB\-\-verbose\fR: \fB\-\-loglevel verbose\fR -. -.IP "\(bu" 4 -\fB\-ddd\fR: \fB\-\-loglevel silly\fR -. -.IP "\(bu" 4 -\fB\-g\fR: \fB\-\-global\fR -. -.IP "\(bu" 4 -\fB\-l\fR: \fB\-\-long\fR -. -.IP "\(bu" 4 -\fB\-m\fR: \fB\-\-message\fR -. -.IP "\(bu" 4 -\fB\-p\fR, \fB\-\-porcelain\fR: \fB\-\-parseable\fR -. -.IP "\(bu" 4 -\fB\-reg\fR: \fB\-\-registry\fR -. -.IP "\(bu" 4 -\fB\-v\fR: \fB\-\-version\fR -. -.IP "\(bu" 4 -\fB\-f\fR: \fB\-\-force\fR -. -.IP "\(bu" 4 -\fB\-l\fR: \fB\-\-long\fR -. -.IP "\(bu" 4 -\fB\-desc\fR: \fB\-\-description\fR -. -.IP "\(bu" 4 -\fB\-S\fR: \fB\-\-save\fR -. -.IP "\(bu" 4 -\fB\-y\fR: \fB\-\-yes\fR -. -.IP "\(bu" 4 -\fB\-n\fR: \fB\-\-yes false\fR -. -.IP "\(bu" 4 -\fBll\fR and \fBla\fR commands: \fBls \-\-long\fR -. -.IP "" 0 -. -.P -If the specified configuration param resolves unambiguously to a known -configuration parameter, then it is expanded to that configuration -parameter\. For example: -. -.IP "" 4 -. -.nf -npm ls \-\-par -# same as: -npm ls \-\-parseable -. -.fi -. -.IP "" 0 -. -.P -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: -. -.IP "" 4 -. -.nf -npm ls \-gpld -# same as: -npm ls \-\-global \-\-parseable \-\-long \-\-loglevel info -. -.fi -. -.IP "" 0 -. -.SH "Per\-Package Config Settings" -When running scripts (see \fBnpm help scripts\fR) -the package\.json "config" keys are overwritten in the environment if -there is a config param of \fB[@]:\fR\|\. For example, if -the package\.json has this: -. -.IP "" 4 -. -.nf -{ "name" : "foo" -, "config" : { "port" : "8080" } -, "scripts" : { "start" : "node server\.js" } } -. -.fi -. -.IP "" 0 -. -.P -and the server\.js is this: -. -.IP "" 4 -. -.nf -http\.createServer(\.\.\.)\.listen(process\.env\.npm_package_config_port) -. -.fi -. -.IP "" 0 -. -.P -then the user could change the behavior by doing: -. -.IP "" 4 -. -.nf -npm config set foo:port 80 -. -.fi -. -.IP "" 0 -. -.SH "Config Settings" -. -.SS "always\-auth" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Force npm to always require authentication when accessing the registry, -even for \fBGET\fR requests\. -. -.SS "bin\-publish" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -If set to true, then binary packages will be created on publish\. -. -.P -This is the way to opt into the "bindist" behavior described below\. -. -.SS "bindist" -. -.IP "\(bu" 4 -Default: Unstable node versions, \fBnull\fR, otherwise \fB"\-\-"\fR -. -.IP "\(bu" 4 -Type: String or \fBnull\fR -. -.IP "" 0 -. -.P -Experimental: on stable versions of node, binary distributions will be -created with this tag\. If a user then installs that package, and their \fBbindist\fR tag is found in the list of binary distributions, they will -get that prebuilt version\. -. -.P -Pre\-build node packages have their preinstall, install, and postinstall -scripts stripped (since they are run prior to publishing), and do not -have their \fBbuild\fR directories automatically ignored\. -. -.P -It\'s yet to be seen if this is a good idea\. -. -.SS "browser" -. -.IP "\(bu" 4 -Default: OS X: \fB"open"\fR, others: \fB"google\-chrome"\fR -. -.IP "\(bu" 4 -Type: String -. -.IP "" 0 -. -.P -The browser that is called by the \fBnpm docs\fR command to open websites\. -. -.SS "ca" -. -.IP "\(bu" 4 -Default: The npm CA certificate -. -.IP "\(bu" 4 -Type: String or null -. -.IP "" 0 -. -.P -The Certificate Authority signing certificate that is trusted for SSL -connections to the registry\. -. -.P -Set to \fBnull\fR to only allow "known" registrars, or to a specific CA cert -to trust only that specific signing authority\. -. -.P -See also the \fBstrict\-ssl\fR config\. -. -.SS "cache" -. -.IP "\(bu" 4 -Default: Windows: \fB~/npm\-cache\fR, Posix: \fB~/\.npm\fR -. -.IP "\(bu" 4 -Type: path -. -.IP "" 0 -. -.P -The location of npm\'s cache directory\. See \fBnpm help cache\fR -. -.SS "color" -. -.IP "\(bu" 4 -Default: true on Posix, false on Windows -. -.IP "\(bu" 4 -Type: Boolean or \fB"always"\fR -. -.IP "" 0 -. -.P -If false, never shows colors\. If \fB"always"\fR then always shows colors\. -If true, then only prints color codes for tty file descriptors\. -. -.SS "depth" -. -.IP "\(bu" 4 -Default: Infinity -. -.IP "\(bu" 4 -Type: Number -. -.IP "" 0 -. -.P -The depth to go when recursing directories for \fBnpm ls\fR and \fBnpm cache ls\fR\|\. -. -.SS "description" -. -.IP "\(bu" 4 -Default: true -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Show the description in \fBnpm search\fR -. -.SS "dev" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Install \fBdev\-dependencies\fR along with packages\. -. -.P -Note that \fBdev\-dependencies\fR are also installed if the \fBnpat\fR flag is -set\. -. -.SS "editor" -. -.IP "\(bu" 4 -Default: \fBEDITOR\fR environment variable if set, or \fB"vi"\fR on Posix, -or \fB"notepad"\fR on Windows\. -. -.IP "\(bu" 4 -Type: path -. -.IP "" 0 -. -.P -The command to run for \fBnpm edit\fR or \fBnpm config edit\fR\|\. -. -.SS "force" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Makes various commands more forceful\. -. -.IP "\(bu" 4 -lifecycle script failure does not block progress\. -. -.IP "\(bu" 4 -publishing clobbers previously published versions\. -. -.IP "\(bu" 4 -skips cache when requesting from the registry\. -. -.IP "\(bu" 4 -prevents checks against clobbering non\-npm files\. -. -.IP "" 0 -. -.SS "global" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Operates in "global" mode, so that packages are installed into the \fBprefix\fR folder instead of the current working directory\. See \fBnpm help folders\fR for more on the differences in behavior\. -. -.IP "\(bu" 4 -packages are installed into the \fBprefix/node_modules\fR folder, instead of the -current working directory\. -. -.IP "\(bu" 4 -bin files are linked to \fBprefix/bin\fR -. -.IP "\(bu" 4 -man pages are linked to \fBprefix/share/man\fR -. -.IP "" 0 -. -.SS "globalconfig" -. -.IP "\(bu" 4 -Default: {prefix}/etc/npmrc -. -.IP "\(bu" 4 -Type: path -. -.IP "" 0 -. -.P -The config file to read for global config options\. -. -.SS "globalignorefile" -. -.IP "\(bu" 4 -Default: {prefix}/etc/npmignore -. -.IP "\(bu" 4 -Type: path -. -.IP "" 0 -. -.P -The config file to read for global ignore patterns to apply to all users -and all projects\. -. -.P -If not found, but there is a "gitignore" file in the -same directory, then that will be used instead\. -. -.SS "group" -. -.IP "\(bu" 4 -Default: GID of the current process -. -.IP "\(bu" 4 -Type: String or Number -. -.IP "" 0 -. -.P -The group to use when running package scripts in global mode as the root -user\. -. -.SS "https\-proxy" -. -.IP "\(bu" 4 -Default: the \fBHTTPS_PROXY\fR or \fBhttps_proxy\fR or \fBHTTP_PROXY\fR or \fBhttp_proxy\fR environment variables\. -. -.IP "\(bu" 4 -Type: url -. -.IP "" 0 -. -.P -A proxy to use for outgoing https requests\. -. -.SS "ignore" -. -.IP "\(bu" 4 -Default: "" -. -.IP "\(bu" 4 -Type: string -. -.IP "" 0 -. -.P -A white\-space separated list of glob patterns of files to always exclude -from packages when building tarballs\. -. -.SS "init\.version" -. -.IP "\(bu" 4 -Default: "0\.0\.0" -. -.IP "\(bu" 4 -Type: semver -. -.IP "" 0 -. -.P -The value \fBnpm init\fR should use by default for the package version\. -. -.SS "init\.author\.name" -. -.IP "\(bu" 4 -Default: "0\.0\.0" -. -.IP "\(bu" 4 -Type: String -. -.IP "" 0 -. -.P -The value \fBnpm init\fR should use by default for the package author\'s name\. -. -.SS "init\.author\.email" -. -.IP "\(bu" 4 -Default: "" -. -.IP "\(bu" 4 -Type: String -. -.IP "" 0 -. -.P -The value \fBnpm init\fR should use by default for the package author\'s email\. -. -.SS "init\.author\.url" -. -.IP "\(bu" 4 -Default: "" -. -.IP "\(bu" 4 -Type: String -. -.IP "" 0 -. -.P -The value \fBnpm init\fR should use by default for the package author\'s homepage\. -. -.SS "link" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -If true, then local installs will link if there is a suitable globally -installed package\. -. -.P -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: -. -.IP "\(bu" 4 -The package is not already installed globally, or -. -.IP "\(bu" 4 -the globally installed version is identical to the version that is -being installed locally\. -. -.IP "" 0 -. -.SS "logfd" -. -.IP "\(bu" 4 -Default: stderr file descriptor -. -.IP "\(bu" 4 -Type: Number or Stream -. -.IP "" 0 -. -.P -The location to write log output\. -. -.SS "loglevel" -. -.IP "\(bu" 4 -Default: "warn" -. -.IP "\(bu" 4 -Type: String -. -.IP "\(bu" 4 -Values: "silent", "win", "error", "warn", "info", "verbose", "silly" -. -.IP "" 0 -. -.P -What level of logs to report\. On failure, \fIall\fR logs are written to \fBnpm\-debug\.log\fR in the current working directory\. -. -.SS "logprefix" -. -.IP "\(bu" 4 -Default: true on Posix, false on Windows -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Whether or not to prefix log messages with "npm" and the log level\. See -also "color" and "loglevel"\. -. -.SS "long" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Show extended information in \fBnpm ls\fR -. -.SS "message" -. -.IP "\(bu" 4 -Default: "%s" -. -.IP "\(bu" 4 -Type: String -. -.IP "" 0 -. -.P -Commit message which is used by \fBnpm version\fR when creating version commit\. -. -.P -Any "%s" in the message will be replaced with the version number\. -. -.SS "node\-version" -. -.IP "\(bu" 4 -Default: process\.version -. -.IP "\(bu" 4 -Type: semver or false -. -.IP "" 0 -. -.P -The node version to use when checking package\'s "engines" hash\. -. -.SS "npat" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Run tests on installation and report results to the \fBnpaturl\fR\|\. -. -.SS "npaturl" -. -.IP "\(bu" 4 -Default: Not yet implemented -. -.IP "\(bu" 4 -Type: url -. -.IP "" 0 -. -.P -The url to report npat test results\. -. -.SS "onload\-script" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: path -. -.IP "" 0 -. -.P -A node module to \fBrequire()\fR when npm loads\. Useful for programmatic -usage\. -. -.SS "outfd" -. -.IP "\(bu" 4 -Default: standard output file descriptor -. -.IP "\(bu" 4 -Type: Number or Stream -. -.IP "" 0 -. -.P -Where to write "normal" output\. This has no effect on log output\. -. -.SS "parseable" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Output parseable results from commands that write to -standard output\. -. -.SS "prefix" -. -.IP "\(bu" 4 -Default: node\'s process\.installPrefix -. -.IP "\(bu" 4 -Type: path -. -.IP "" 0 -. -.P -The location to install global items\. If set on the command line, then -it forces non\-global commands to run in the specified folder\. -. -.SS "production" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Set to true to run in "production" mode\. -. -.IP "1" 4 -devDependencies are not installed at the topmost level when running -local \fBnpm install\fR without any arguments\. -. -.IP "2" 4 -Set the NODE_ENV="production" for lifecycle scripts\. -. -.IP "" 0 -. -.SS "proxy" -. -.IP "\(bu" 4 -Default: \fBHTTP_PROXY\fR or \fBhttp_proxy\fR environment variable, or null -. -.IP "\(bu" 4 -Type: url -. -.IP "" 0 -. -.P -A proxy to use for outgoing http requests\. -. -.SS "rebuild\-bundle" -. -.IP "\(bu" 4 -Default: true -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Rebuild bundled dependencies after installation\. -. -.SS "registry" -. -.IP "\(bu" 4 -Default: https://registry\.npmjs\.org/ -. -.IP "\(bu" 4 -Type: url -. -.IP "" 0 -. -.P -The base URL of the npm package registry\. -. -.SS "rollback" -. -.IP "\(bu" 4 -Default: true -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Remove failed installs\. -. -.SS "save" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Save installed packages to a package\.json file as dependencies\. -. -.P -Only works if there is already a package\.json file present\. -. -.SS "searchopts" -. -.IP "\(bu" 4 -Default: "" -. -.IP "\(bu" 4 -Type: String -. -.IP "" 0 -. -.P -Space\-separated options that are always passed to search\. -. -.SS "searchexclude" -. -.IP "\(bu" 4 -Default: "" -. -.IP "\(bu" 4 -Type: String -. -.IP "" 0 -. -.P -Space\-separated options that limit the results from search\. -. -.SS "shell" -. -.IP "\(bu" 4 -Default: SHELL environment variable, or "bash" on Posix, or "cmd" on -Windows -. -.IP "\(bu" 4 -Type: path -. -.IP "" 0 -. -.P -The shell to run for the \fBnpm explore\fR command\. -. -.SS "strict\-ssl" -. -.IP "\(bu" 4 -Default: true -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Whether or not to do SSL key validation when making requests to the -registry via https\. -. -.P -See also the \fBca\fR config\. -. -.SS "tag" -. -.IP "\(bu" 4 -Default: latest -. -.IP "\(bu" 4 -Type: String -. -.IP "" 0 -. -.P -If you ask npm to install a package and don\'t tell it a specific version, then -it will install the specified tag\. -. -.P -Also the tag that is added to the package@version specified by the \fBnpm -tag\fR command, if no explicit tag is given\. -. -.SS "tmp" -. -.IP "\(bu" 4 -Default: TMPDIR environment variable, or "/tmp" -. -.IP "\(bu" 4 -Type: path -. -.IP "" 0 -. -.P -Where to store temporary files and folders\. All temp files are deleted -on success, but left behind on failure for forensic purposes\. -. -.SS "unicode" -. -.IP "\(bu" 4 -Default: true -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -When set to true, npm uses unicode characters in the tree output\. When -false, it uses ascii characters to draw trees\. -. -.SS "unsafe\-perm" -. -.IP "\(bu" 4 -Default: false if running as root, true otherwise -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -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\. -. -.SS "usage" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Set to show short usage output (like the \-H output) -instead of complete help when doing \fBnpm help help\fR\|\. -. -.SS "user" -. -.IP "\(bu" 4 -Default: "nobody" -. -.IP "\(bu" 4 -Type: String or Number -. -.IP "" 0 -. -.P -The UID to set to when running package scripts as root\. -. -.SS "username" -. -.IP "\(bu" 4 -Default: null -. -.IP "\(bu" 4 -Type: String -. -.IP "" 0 -. -.P -The username on the npm registry\. Set with \fBnpm adduser\fR -. -.SS "userconfig" -. -.IP "\(bu" 4 -Default: ~/\.npmrc -. -.IP "\(bu" 4 -Type: path -. -.IP "" 0 -. -.P -The location of user\-level configuration settings\. -. -.SS "userignorefile" -. -.IP "\(bu" 4 -Default: ~/\.npmignore -. -.IP "\(bu" 4 -Type: path -. -.IP "" 0 -. -.P -The location of a user\-level ignore file to apply to all packages\. -. -.P -If not found, but there is a \.gitignore file in the same directory, then -that will be used instead\. -. -.SS "umask" -. -.IP "\(bu" 4 -Default: 022 -. -.IP "\(bu" 4 -Type: Octal numeric string -. -.IP "" 0 -. -.P -The "umask" value to use when setting the file creation mode on files -and folders\. -. -.P -Folders and executables are given a mode which is \fB0777\fR masked against -this value\. Other files are given a mode which is \fB0666\fR masked against -this value\. Thus, the defaults are \fB0755\fR and \fB0644\fR respectively\. -. -.SS "version" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: boolean -. -.IP "" 0 -. -.P -If true, output the npm version and exit successfully\. -. -.P -Only relevant when specified explicitly on the command line\. -. -.SS "viewer" -. -.IP "\(bu" 4 -Default: "man" on Posix, "browser" on Windows -. -.IP "\(bu" 4 -Type: path -. -.IP "" 0 -. -.P -The program to use to view help content\. -. -.P -Set to \fB"browser"\fR to view html help content in the default web browser\. -. -.SS "yes" -. -.IP "\(bu" 4 -Default: null -. -.IP "\(bu" 4 -Type: Boolean or null -. -.IP "" 0 -. -.P -If set to \fBnull\fR, then prompt the user for responses in some -circumstances\. -. -.P -If set to \fBtrue\fR, then answer "yes" to any prompt\. If set to \fBfalse\fR -then answer "no" to any prompt\. -. -.SH "SEE ALSO" -. -.IP "\(bu" 4 -npm help folders -. -.IP "\(bu" 4 -npm help npm -. -.IP "" 0 - diff --git a/deps/npm/man/man1/global.1 b/deps/npm/man/man1/global.1 deleted file mode 100644 index ddd14dd88..000000000 --- a/deps/npm/man/man1/global.1 +++ /dev/null @@ -1,258 +0,0 @@ -.\" Generated with Ronnjs 0.3.8 -.\" http://github.com/kapouer/ronnjs/ -. -.TH "NPM\-FOLDERS" "1" "July 2013" "" "" -. -.SH "NAME" -\fBnpm-folders\fR \-\- Folder Structures Used by npm -. -.SH "DESCRIPTION" -npm puts various things on your computer\. That\'s its job\. -. -.P -This document will tell you what it puts where\. -. -.SS "tl;dr" -. -.IP "\(bu" 4 -Local install (default): puts stuff in \fB\|\./node_modules\fR of the current -package root\. -. -.IP "\(bu" 4 -Global install (with \fB\-g\fR): puts stuff in /usr/local or wherever node -is installed\. -. -.IP "\(bu" 4 -Install it \fBlocally\fR if you\'re going to \fBrequire()\fR it\. -. -.IP "\(bu" 4 -Install it \fBglobally\fR if you\'re going to run it on the command line\. -. -.IP "\(bu" 4 -If you need both, then install it in both places, or use \fBnpm link\fR\|\. -. -.IP "" 0 -. -.SS "prefix Configuration" -The \fBprefix\fR config defaults to the location where node is installed\. -On most systems, this is \fB/usr/local\fR, and most of the time is the same -as node\'s \fBprocess\.installPrefix\fR\|\. -. -.P -On windows, this is the exact location of the node\.exe binary\. On Unix -systems, it\'s one level up, since node is typically installed at \fB{prefix}/bin/node\fR rather than \fB{prefix}/node\.exe\fR\|\. -. -.P -When the \fBglobal\fR 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\. -. -.SS "Node Modules" -Packages are dropped into the \fBnode_modules\fR folder under the \fBprefix\fR\|\. -When installing locally, this means that you can \fBrequire("packagename")\fR to load its main module, or \fBrequire("packagename/lib/path/to/sub/module")\fR to load other modules\. -. -.P -Global installs on Unix systems go to \fB{prefix}/lib/node_modules\fR\|\. -Global installs on Windows go to \fB{prefix}/node_modules\fR (that is, no \fBlib\fR folder\.) -. -.P -If you wish to \fBrequire()\fR a package, then install it locally\. -. -.SS "Executables" -When in global mode, executables are linked into \fB{prefix}/bin\fR on Unix, -or directly into \fB{prefix}\fR on Windows\. -. -.P -When in local mode, executables are linked into \fB\|\./node_modules/\.bin\fR 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 \fBnpm test\fR\|\.) -. -.SS "Man Pages" -When in global mode, man pages are linked into \fB{prefix}/share/man\fR\|\. -. -.P -When in local mode, man pages are not installed\. -. -.P -Man pages are not installed on Windows systems\. -. -.SS "Cache" -See \fBnpm help cache\fR\|\. Cache files are stored in \fB~/\.npm\fR on Posix, or \fB~/npm\-cache\fR on Windows\. -. -.P -This is controlled by the \fBcache\fR configuration param\. -. -.SS "Temp Files" -Temporary files are stored by default in the folder specified by the \fBtmp\fR config, which defaults to the TMPDIR, TMP, or TEMP environment -variables, or \fB/tmp\fR on Unix and \fBc:\\windows\\temp\fR on Windows\. -. -.P -Temp files are given a unique folder under this root for each run of the -program, and are deleted upon successful exit\. -. -.SH "More Information" -When installing locally, npm first tries to find an appropriate \fBprefix\fR folder\. This is so that \fBnpm install foo@1\.2\.3\fR will install -to the sensible root of your package, even if you happen to have \fBcd\fRed -into some other folder\. -. -.P -Starting at the $PWD, npm will walk up the folder tree checking for a -folder that contains either a \fBpackage\.json\fR file, or a \fBnode_modules\fR -folder\. If such a thing is found, then that is treated as the effective -"current directory" for the purpose of running npm commands\. (This -behavior is inspired by and similar to git\'s \.git\-folder seeking -logic when running git commands in a working dir\.) -. -.P -If no package root is found, then the current folder is used\. -. -.P -When you run \fBnpm install foo@1\.2\.3\fR, then the package is loaded into -the cache, and then unpacked into \fB\|\./node_modules/foo\fR\|\. Then, any of -foo\'s dependencies are similarly unpacked into \fB\|\./node_modules/foo/node_modules/\.\.\.\fR\|\. -. -.P -Any bin files are symlinked to \fB\|\./node_modules/\.bin/\fR, so that they may -be found by npm scripts when necessary\. -. -.SS "Global Installation" -If the \fBglobal\fR configuration is set to true, then npm will -install packages "globally"\. -. -.P -For global installation, packages are installed roughly the same way, -but using the folders described above\. -. -.SS "Cycles, Conflicts, and Folder Parsimony" -Cycles are handled using the property of node\'s module system that it -walks up the directories looking for \fBnode_modules\fR folders\. So, at every -stage, if a package is already installed in an ancestor \fBnode_modules\fR -folder, then it is not installed at the current location\. -. -.P -Consider the case above, where \fBfoo \-> bar \-> baz\fR\|\. Imagine if, in -addition to that, baz depended on bar, so you\'d have: \fBfoo \-> bar \-> baz \-> bar \-> baz \.\.\.\fR\|\. However, since the folder -structure is: \fBfoo/node_modules/bar/node_modules/baz\fR, there\'s no need to -put another copy of bar into \fB\|\.\.\./baz/node_modules\fR, since when it calls -require("bar"), it will get the copy that is installed in \fBfoo/node_modules/bar\fR\|\. -. -.P -This shortcut is only used if the exact same -version would be installed in multiple nested \fBnode_modules\fR folders\. It -is still possible to have \fBa/node_modules/b/node_modules/a\fR if the two -"a" packages are different versions\. However, without repeating the -exact same package multiple times, an infinite regress will always be -prevented\. -. -.P -Another optimization can be made by installing dependencies at the -highest level possible, below the localized "target" folder\. -. -.SS "\fIExample\fR" -Consider this dependency graph: -. -.IP "" 4 -. -.nf -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 -. -.fi -. -.IP "" 0 -. -.P -In this case, we might expect a folder structure like this: -. -.IP "" 4 -. -.nf -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] -. -.fi -. -.IP "" 0 -. -.P -Since foo depends directly on bar@1\.2\.3 and baz@1\.2\.3, those are -installed in foo\'s \fBnode_modules\fR folder\. -. -.P -Even though the latest copy of blerg is 1\.3\.7, foo has a specific -dependency on version 1\.2\.5\. So, that gets installed at [A]\. Since the -parent installation of blerg satisfie\'s bar\'s dependency on blerg@1\.x, -it does not install another copy under [B]\. -. -.P -Bar [B] also has dependencies on baz and asdf, so those are installed in -bar\'s \fBnode_modules\fR folder\. Because it depends on \fBbaz@2\.x\fR, it cannot -re\-use the \fBbaz@1\.2\.3\fR installed in the parent \fBnode_modules\fR folder [D], -and must install its own copy [C]\. -. -.P -Underneath bar, the \fBbaz\->quux\->bar\fR dependency creates a cycle\. -However, because \fBbar\fR is already in \fBquux\fR\'s ancestry [B], it does not -unpack another copy of bar into that folder\. -. -.P -Underneath \fBfoo\->baz\fR [D], quux\'s [E] folder tree is empty, because its -dependency on bar is satisfied by the parent folder copy installed at [B]\. -. -.P -For a graphical breakdown of what is installed where, use \fBnpm ls\fR\|\. -. -.SS "Publishing" -Upon publishing, npm will look in the \fBnode_modules\fR folder\. If any of -the items there are not in the \fBbundledDependencies\fR array, then they will -not be included in the package tarball\. -. -.P -This allows a package maintainer to install all of their dependencies -(and dev dependencies) locally, but only re\-publish those items that -cannot be found elsewhere\. See \fBnpm help json\fR for more information\. -. -.SH "SEE ALSO" -. -.IP "\(bu" 4 -npm help faq -. -.IP "\(bu" 4 -npm help json -. -.IP "\(bu" 4 -npm help install -. -.IP "\(bu" 4 -npm help pack -. -.IP "\(bu" 4 -npm help cache -. -.IP "\(bu" 4 -npm help config -. -.IP "\(bu" 4 -npm help publish -. -.IP "" 0 - diff --git a/deps/npm/man/man1/help-search.1 b/deps/npm/man/man1/help-search.1 deleted file mode 100644 index d3fc80a29..000000000 --- a/deps/npm/man/man1/help-search.1 +++ /dev/null @@ -1,59 +0,0 @@ -.\" Generated with Ronnjs 0.3.8 -.\" http://github.com/kapouer/ronnjs/ -. -.TH "NPM\-HELP\-SEARCH" "1" "July 2013" "" "" -. -.SH "NAME" -\fBnpm-help-search\fR \-\- Search npm help documentation -. -.SH "SYNOPSIS" -. -.nf -npm help\-search some search terms -. -.fi -. -.SH "DESCRIPTION" -This command will search the npm markdown documentation files for the -terms provided, and then list the results, sorted by relevance\. -. -.P -If only one result is found, then it will show that help topic\. -. -.P -If the argument to \fBnpm help\fR is not a known help topic, then it will -call \fBhelp\-search\fR\|\. It is rarely if ever necessary to call this -command directly\. -. -.SH "CONFIGURATION" -. -.SS "long" -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "\(bu" 4 -Default false -. -.IP "" 0 -. -.P -If true, the "long" flag will cause help\-search to output context around -where the terms were found in the documentation\. -. -.P -If false, then help\-search will just list out the help topics found\. -. -.SH "SEE ALSO" -. -.IP "\(bu" 4 -npm help npm -. -.IP "\(bu" 4 -npm help faq -. -.IP "\(bu" 4 -npm help help -. -.IP "" 0 - diff --git a/deps/npm/man/man1/help.1 b/deps/npm/man/man1/help.1 deleted file mode 100644 index 3e5dfcd1c..000000000 --- a/deps/npm/man/man1/help.1 +++ /dev/null @@ -1,71 +0,0 @@ -.\" Generated with Ronnjs 0.3.8 -.\" http://github.com/kapouer/ronnjs/ -. -.TH "NPM\-HELP" "1" "July 2013" "" "" -. -.SH "NAME" -\fBnpm-help\fR \-\- Get help on npm -. -.SH "SYNOPSIS" -. -.nf -npm help -npm help some search terms -. -.fi -. -.SH "DESCRIPTION" -If supplied a topic, then show the appropriate documentation page\. -. -.P -If the topic does not exist, or if multiple terms are provided, then run -the \fBhelp\-search\fR command to find a match\. Note that, if \fBhelp\-search\fR -finds a single subject, then it will run \fBhelp\fR on that topic, so unique -matches are equivalent to specifying a topic name\. -. -.SH "CONFIGURATION" -. -.SS "viewer" -. -.IP "\(bu" 4 -Default: "man" on Posix, "browser" on Windows -. -.IP "\(bu" 4 -Type: path -. -.IP "" 0 -. -.P -The program to use to view help content\. -. -.P -Set to \fB"browser"\fR to view html help content in the default web browser\. -. -.SH "SEE ALSO" -. -.IP "\(bu" 4 -npm help npm -. -.IP "\(bu" 4 -README -. -.IP "\(bu" 4 -npm help faq -. -.IP "\(bu" 4 -npm help folders -. -.IP "\(bu" 4 -npm help config -. -.IP "\(bu" 4 -npm help json -. -.IP "\(bu" 4 -npm help help\-search -. -.IP "\(bu" 4 -npm help index -. -.IP "" 0 - diff --git a/deps/npm/man/man1/home.1 b/deps/npm/man/man1/home.1 deleted file mode 100644 index c63dd3cd9..000000000 --- a/deps/npm/man/man1/home.1 +++ /dev/null @@ -1,68 +0,0 @@ -.\" Generated with Ronnjs/v0.1 -.\" http://github.com/kapouer/ronnjs/ -. -.TH "NPM\-DOCS" "1" "November 2011" "" "" -. -.SH "NAME" -\fBnpm-docs\fR \-\- Docs for a package in a web browser maybe -. -.SH "SYNOPSIS" -. -.nf -npm docs -npm home -. -.fi -. -.SH "DESCRIPTION" -This command tries to guess at the likely location of a package\'s -documentation URL, and then tries to open it using the \fB\-\-browser\fR -config param\. -. -.SH "CONFIGURATION" -. -.SS "browser" -. -.IP "\(bu" 4 -Default: OS X: \fB"open"\fR, others: \fB"google\-chrome"\fR -. -.IP "\(bu" 4 -Type: String -. -.IP "" 0 -. -.P -The browser that is called by the \fBnpm docs\fR command to open websites\. -. -.SS "registry" -. -.IP "\(bu" 4 -Default: https://registry\.npmjs\.org/ -. -.IP "\(bu" 4 -Type: url -. -.IP "" 0 -. -.P -The base URL of the npm package registry\. -. -.SH "SEE ALSO" -. -.IP "\(bu" 4 -npm help view -. -.IP "\(bu" 4 -npm help publish -. -.IP "\(bu" 4 -npm help registry -. -.IP "\(bu" 4 -npm help config -. -.IP "\(bu" 4 -npm help json -. -.IP "" 0 - diff --git a/deps/npm/man/man1/index.1 b/deps/npm/man/man1/index.1 deleted file mode 100644 index daaca49ad..000000000 --- a/deps/npm/man/man1/index.1 +++ /dev/null @@ -1,298 +0,0 @@ -.\" Generated with Ronnjs 0.3.8 -.\" http://github.com/kapouer/ronnjs/ -. -.TH "NPM\-INDEX" "1" "July 2013" "" "" -. -.SH "NAME" -\fBnpm-index\fR \-\- Index of all npm documentation -. -.SH "npm help README" - node package manager -. -.SH "npm help adduser" - Add a registry user account -. -.SH "npm help bin" - Display npm bin folder -. -.SH "npm help bugs" - Bugs for a package in a web browser maybe -. -.SH "npm help build" - Build a package -. -.SH "npm help bundle" - REMOVED -. -.SH "npm help cache" - Manipulates packages cache -. -.SH "npm help changelog" - Changes -. -.SH "npm help coding\-style" - npm\'s "funny" coding style -. -.SH "npm help completion" - Tab Completion for npm -. -.SH "npm help config" - Manage the npm configuration file -. -.SH "npm help dedupe" - Reduce duplication -. -.SH "npm help deprecate" - Deprecate a version of a package -. -.SH "npm help developers" - Developer Guide -. -.SH "npm help disputes" - Handling Module Name Disputes -. -.SH "npm help docs" - Docs for a package in a web browser maybe -. -.SH "npm help edit" - Edit an installed package -. -.SH "npm help explore" - Browse an installed package -. -.SH "npm help faq" - Frequently Asked Questions -. -.SH "npm help folders" - Folder Structures Used by npm -. -.SH "npm help global" - Folder Structures Used by npm -. -.SH "npm help help\-search" - Search npm help documentation -. -.SH "npm help help" - Get help on npm -. -.SH "npm help init" - Interactively create a package\.json file -. -.SH "npm help install" - Install a package -. -.SH "npm help json" - Specifics of npm\'s package\.json handling -. -.SH "npm help link" - Symlink a package folder -. -.SH "npm help ls" - List installed packages -. -.SH "npm help npm" - node package manager -. -.SH "npm help outdated" - Check for outdated packages -. -.SH "npm help owner" - Manage package owners -. -.SH "npm help pack" - Create a tarball from a package -. -.SH "npm help prefix" - Display prefix -. -.SH "npm help prune" - Remove extraneous packages -. -.SH "npm help publish" - Publish a package -. -.SH "npm help rebuild" - Rebuild a package -. -.SH "npm help registry" - The JavaScript Package Registry -. -.SH "npm help removing\-npm" - Cleaning the Slate -. -.SH "npm help restart" - Start a package -. -.SH "npm help rm" - Remove a package -. -.SH "npm help root" - Display npm root -. -.SH "npm help run\-script" - Run arbitrary package scripts -. -.SH "npm help scripts" - How npm handles the "scripts" field -. -.SH "npm help search" - Search for packages -. -.SH "npm help semver" - The semantic versioner for npm -. -.SH "npm help shrinkwrap" - Lock down dependency versions -. -.SH "npm help star" - Mark your favorite packages -. -.SH "npm help stars" - View packages marked as favorites -. -.SH "npm help start" - Start a package -. -.SH "npm help stop" - Stop a package -. -.SH "npm help submodule" - Add a package as a git submodule -. -.SH "npm help tag" - Tag a published version -. -.SH "npm help test" - Test a package -. -.SH "npm help uninstall" - Remove a package -. -.SH "npm help unpublish" - Remove a package from the registry -. -.SH "npm help update" - Update a package -. -.SH "npm help version" - Bump a package version -. -.SH "npm help view" - View registry info -. -.SH "npm help whoami" - Display npm username -. -.SH "npm apihelp bin" - Display npm bin folder -. -.SH "npm apihelp bugs" - Bugs for a package in a web browser maybe -. -.SH "npm apihelp commands" - npm commands -. -.SH "npm apihelp config" - Manage the npm configuration files -. -.SH "npm apihelp deprecate" - Deprecate a version of a package -. -.SH "npm apihelp docs" - Docs for a package in a web browser maybe -. -.SH "npm apihelp edit" - Edit an installed package -. -.SH "npm apihelp explore" - Browse an installed package -. -.SH "npm apihelp help\-search" - Search the help pages -. -.SH "npm apihelp init" - Interactively create a package\.json file -. -.SH "npm apihelp install" - install a package programmatically -. -.SH "npm apihelp link" - Symlink a package folder -. -.SH "npm apihelp load" - Load config settings -. -.SH "npm apihelp ls" - List installed packages -. -.SH "npm apihelp npm" - node package manager -. -.SH "npm apihelp outdated" - Check for outdated packages -. -.SH "npm apihelp owner" - Manage package owners -. -.SH "npm apihelp pack" - Create a tarball from a package -. -.SH "npm apihelp prefix" - Display prefix -. -.SH "npm apihelp prune" - Remove extraneous packages -. -.SH "npm apihelp publish" - Publish a package -. -.SH "npm apihelp rebuild" - Rebuild a package -. -.SH "npm apihelp restart" - Start a package -. -.SH "npm apihelp root" - Display npm root -. -.SH "npm apihelp run\-script" - Run arbitrary package scripts -. -.SH "npm apihelp search" - Search for packages -. -.SH "npm apihelp shrinkwrap" - programmatically generate package shrinkwrap file -. -.SH "npm apihelp start" - Start a package -. -.SH "npm apihelp stop" - Stop a package -. -.SH "npm apihelp submodule" - Add a package as a git submodule -. -.SH "npm apihelp tag" - Tag a published version -. -.SH "npm apihelp test" - Test a package -. -.SH "npm apihelp uninstall" - uninstall a package programmatically -. -.SH "npm apihelp unpublish" - Remove a package from the registry -. -.SH "npm apihelp update" - Update a package -. -.SH "npm apihelp version" - Bump a package version -. -.SH "npm apihelp view" - View registry info -. -.SH "npm apihelp whoami" - Display npm username diff --git a/deps/npm/man/man1/init.1 b/deps/npm/man/man1/init.1 deleted file mode 100644 index 5ffe04399..000000000 --- a/deps/npm/man/man1/init.1 +++ /dev/null @@ -1,43 +0,0 @@ -.\" Generated with Ronnjs 0.3.8 -.\" http://github.com/kapouer/ronnjs/ -. -.TH "NPM\-INIT" "1" "July 2013" "" "" -. -.SH "NAME" -\fBnpm-init\fR \-\- Interactively create a package\.json file -. -.SH "SYNOPSIS" -. -.nf -npm init -. -.fi -. -.SH "DESCRIPTION" -This will ask you a bunch of questions, and then write a package\.json for you\. -. -.P -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\. -. -.P -If you already have a package\.json file, it\'ll read that first, and default to -the options in there\. -. -.P -It is strictly additive, so it does not delete options from your package\.json -without a really good reason to do so\. -. -.SH "SEE ALSO" -. -.IP "\(bu" 4 -\fIhttps://github\.com/isaacs/init\-package\-json\fR -. -.IP "\(bu" 4 -npm help json -. -.IP "\(bu" 4 -npm help version -. -.IP "" 0 - diff --git a/deps/npm/man/man1/install.1 b/deps/npm/man/man1/install.1 deleted file mode 100644 index 57f32acc8..000000000 --- a/deps/npm/man/man1/install.1 +++ /dev/null @@ -1,417 +0,0 @@ -.\" Generated with Ronnjs 0.3.8 -.\" http://github.com/kapouer/ronnjs/ -. -.TH "NPM\-INSTALL" "1" "July 2013" "" "" -. -.SH "NAME" -\fBnpm-install\fR \-\- Install a package -. -.SH "SYNOPSIS" -. -.nf -npm install (with no args in a package dir) -npm install -npm install -npm install -npm install [\-\-save|\-\-save\-dev|\-\-save\-optional] -npm install @ -npm install @ -npm install @ -npm install @ -. -.fi -. -.SH "DESCRIPTION" -This command installs a package, and any packages that it depends on\. If the -package has a shrinkwrap file, the installation of dependencies will be driven -by that\. See npm help shrinkwrap\. -. -.P -A \fBpackage\fR is: -. -.IP "\(bu" 4 -a) a folder containing a program described by a package\.json file -. -.IP "\(bu" 4 -b) a gzipped tarball containing (a) -. -.IP "\(bu" 4 -c) a url that resolves to (b) -. -.IP "\(bu" 4 -d) a \fB@\fR that is published on the registry with (c) -. -.IP "\(bu" 4 -e) a \fB@\fR that points to (d) -. -.IP "\(bu" 4 -f) a \fB\fR that has a "latest" tag satisfying (e) -. -.IP "\(bu" 4 -g) a \fB\fR that resolves to (b) -. -.IP "" 0 -. -.P -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)\. -. -.IP "\(bu" 4 -\fBnpm install\fR (in package directory, no arguments): -. -.IP -Install the dependencies in the local node_modules folder\. -. -.IP -In global mode (ie, with \fB\-g\fR or \fB\-\-global\fR appended to the command), -it installs the current package context (ie, the current working -directory) as a global package\. -. -.IP "\(bu" 4 -\fBnpm install \fR: -. -.IP -Install a package that is sitting in a folder on the filesystem\. -. -.IP "\(bu" 4 -\fBnpm install \fR: -. -.IP -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 \fBnpm link\fR\|\. -. -.IP -Example: -. -.IP "" 4 -. -.nf - npm install \./package\.tgz -. -.fi -. -.IP "" 0 - -. -.IP "\(bu" 4 -\fBnpm install \fR: -. -.IP -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://" -. -.IP -Example: -. -.IP "" 4 -. -.nf - npm install https://github\.com/indexzero/forever/tarball/v0\.5\.6 -. -.fi -. -.IP "" 0 - -. -.IP "\(bu" 4 -\fBnpm install [\-\-save|\-\-save\-dev|\-\-save\-optional]\fR: -. -.IP -Do a \fB@\fR install, where \fB\fR is the "tag" config\. (See \fBnpm help config\fR\|\.) -. -.IP -In most cases, this will install the latest version -of the module published on npm\. -. -.IP -Example: -. -.IP - npm install sax -. -.IP -\fBnpm install\fR takes 3 exclusive, optional flags which save or update -the package version in your main package\.json: -. -.IP "\(bu" 4 -\fB\-\-save\fR: Package will appear in your \fBdependencies\fR\|\. -. -.IP "\(bu" 4 -\fB\-\-save\-dev\fR: Package will appear in your \fBdevDependencies\fR\|\. -. -.IP "\(bu" 4 -\fB\-\-save\-optional\fR: Package will appear in your \fBoptionalDependencies\fR\|\. -. -.IP -Examples: -. -.IP - npm install sax \-\-save - npm install node\-tap \-\-save\-dev - npm install dtrace\-provider \-\-save\-optional -. -.IP -\fBNote\fR: If there is a file or folder named \fB\fR 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\. -. -.IP "" 0 - -. -.IP "\(bu" 4 -\fBnpm install @\fR: -. -.IP -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\. -. -.IP -Example: -. -.IP "" 4 -. -.nf - npm install sax@latest -. -.fi -. -.IP "" 0 - -. -.IP "\(bu" 4 -\fBnpm install @\fR: -. -.IP -Install the specified version of the package\. This will fail if the version -has not been published to the registry\. -. -.IP -Example: -. -.IP "" 4 -. -.nf - npm install sax@0\.1\.1 -. -.fi -. -.IP "" 0 - -. -.IP "\(bu" 4 -\fBnpm install @\fR: -. -.IP -Install a version of the package matching the specified version range\. This -will follow the same rules for resolving dependencies described in \fBnpm help json\fR\|\. -. -.IP -Note that most version ranges must be put in quotes so that your shell will -treat it as a single argument\. -. -.IP -Example: -. -.IP - npm install sax@">=0\.1\.0 <0\.2\.0" -. -.IP "\(bu" 4 -\fBnpm install \fR: -. -.IP -Install a package by cloning a git remote url\. The format of the git -url is: -. -.IP - ://[@][#] -. -.IP -\fB\fR is one of \fBgit\fR, \fBgit+ssh\fR, \fBgit+http\fR, or \fBgit+https\fR\|\. If no \fB\fR is specified, then \fBmaster\fR is -used\. -. -.IP -Examples: -. -.IP "" 4 -. -.nf - 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 -. -.fi -. -.IP "" 0 - -. -.IP "" 0 -. -.P -You may combine multiple arguments, and even multiple types of arguments\. -For example: -. -.IP "" 4 -. -.nf -npm install sax@">=0\.1\.0 <0\.2\.0" bench supervisor -. -.fi -. -.IP "" 0 -. -.P -The \fB\-\-tag\fR argument will apply to all of the specified install targets\. -. -.P -The \fB\-\-force\fR argument will force npm to fetch remote resources even if a -local copy exists on disk\. -. -.IP "" 4 -. -.nf -npm install sax \-\-force -. -.fi -. -.IP "" 0 -. -.P -The \fB\-\-global\fR argument will cause npm to install the package globally -rather than locally\. See \fBnpm help folders\fR\|\. -. -.P -The \fB\-\-link\fR argument will cause npm to link global installs into the -local space in some cases\. -. -.P -The \fB\-\-no\-bin\-links\fR argument will prevent npm from creating symlinks for -any binaries the package might contain\. -. -.P -The \fB\-\-no\-shrinkwrap\fR argument, which will ignore an available -shrinkwrap file and use the package\.json instead\. -. -.P -The \fB\-\-nodedir=/path/to/node/source\fR argument will allow npm to find the -node source code so that npm can compile native modules\. -. -.P -See \fBnpm help config\fR\|\. Many of the configuration params have some -effect on installation, since that\'s most of what npm does\. -. -.SH "ALGORITHM" -To install a package, npm uses the following algorithm: -. -.IP "" 4 -. -.nf -install(where, what, family, ancestors) -fetch what, unpack to /node_modules/ -for each dep in what\.dependencies - resolve dep to precise version -for each dep@version in what\.dependencies - not in /node_modules//node_modules/* - and not in - add precise version deps to - install(/node_modules/, dep, family) -. -.fi -. -.IP "" 0 -. -.P -For this \fBpackage{dep}\fR structure: \fBA{B,C}, B{C}, C{D}\fR, -this algorithm produces: -. -.IP "" 4 -. -.nf -A -+\-\- B -`\-\- C - `\-\- D -. -.fi -. -.IP "" 0 -. -.P -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\. -. -.P -See npm help folders for a more detailed description of the specific -folder structures that npm creates\. -. -.SS "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: -. -.IP "" 4 -. -.nf -A \-> B \-> A\' \-> B\' \-> A \-> B \-> A\' \-> B\' \-> A \-> \.\.\. -. -.fi -. -.IP "" 0 -. -.P -where \fBA\fR is some version of a package, and \fBA\'\fR is a different version -of the same package\. Because \fBB\fR depends on a different version of \fBA\fR -than the one that is already in the tree, it must install a separate -copy\. The same is true of \fBA\'\fR, which must install \fBB\'\fR\|\. Because \fBB\'\fR -depends on the original version of \fBA\fR, which has been overridden, the -cycle falls into infinite regress\. -. -.P -To avoid this situation, npm flat\-out refuses to install any \fBname@version\fR 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\. -. -.SH "SEE ALSO" -. -.IP "\(bu" 4 -npm help folders -. -.IP "\(bu" 4 -npm help update -. -.IP "\(bu" 4 -npm help link -. -.IP "\(bu" 4 -npm help rebuild -. -.IP "\(bu" 4 -npm help scripts -. -.IP "\(bu" 4 -npm help build -. -.IP "\(bu" 4 -npm help config -. -.IP "\(bu" 4 -npm help registry -. -.IP "\(bu" 4 -npm help folders -. -.IP "\(bu" 4 -npm help tag -. -.IP "\(bu" 4 -npm help rm -. -.IP "\(bu" 4 -npm help shrinkwrap -. -.IP "" 0 - diff --git a/deps/npm/man/man1/json.1 b/deps/npm/man/man1/json.1 deleted file mode 100644 index c5558f816..000000000 --- a/deps/npm/man/man1/json.1 +++ /dev/null @@ -1,853 +0,0 @@ -.\" Generated with Ronnjs 0.3.8 -.\" http://github.com/kapouer/ronnjs/ -. -.TH "NPM\-JSON" "1" "July 2013" "" "" -. -.SH "NAME" -\fBnpm-json\fR \-\- Specifics of npm\'s package\.json handling -. -.SH "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\. -. -.P -A lot of the behavior described in this document is affected by the config -settings described in \fBnpm help config\fR\|\. -. -.SH "DEFAULT VALUES" -npm will default some values based on package contents\. -. -.IP "\(bu" 4 -\fB"scripts": {"start": "node server\.js"}\fR -. -.IP -If there is a \fBserver\.js\fR file in the root of your package, then npm -will default the \fBstart\fR command to \fBnode server\.js\fR\|\. -. -.IP "\(bu" 4 -\fB"scripts":{"preinstall": "node\-waf clean || true; node\-waf configure build"}\fR -. -.IP -If there is a \fBwscript\fR file in the root of your package, npm will -default the \fBpreinstall\fR command to compile using node\-waf\. -. -.IP "\(bu" 4 -\fB"scripts":{"preinstall": "node\-gyp rebuild"}\fR -. -.IP -If there is a \fBbinding\.gyp\fR file in the root of your package, npm will -default the \fBpreinstall\fR command to compile using node\-gyp\. -. -.IP "\(bu" 4 -\fB"contributors": [\.\.\.]\fR -. -.IP -If there is an \fBAUTHORS\fR file in the root of your package, npm will -treat each line as a \fBName (url)\fR format, where email and url -are optional\. Lines which start with a \fB#\fR or are blank, will be -ignored\. -. -.IP "" 0 -. -.SH "name" -The \fImost\fR 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\. -. -.P -The name is what your thing is called\. Some tips: -. -.IP "\(bu" 4 -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\.) -. -.IP "\(bu" 4 -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\. -. -.IP "\(bu" 4 -The name will probably be passed as an argument to require(), so it should -be something short, but also reasonably descriptive\. -. -.IP "\(bu" 4 -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/ -. -.IP "" 0 -. -.SH "version" -The \fImost\fR 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\. -. -.P -Version must be parseable by node\-semver \fIhttps://github\.com/isaacs/node\-semver\fR, which is bundled -with npm as a dependency\. (\fBnpm install semver\fR to use it yourself\.) -. -.P -Here\'s how npm\'s semver implementation deviates from what\'s on semver\.org: -. -.IP "\(bu" 4 -Versions can start with "v" -. -.IP "\(bu" 4 -A numeric item separated from the main three\-number version by a hyphen -will be interpreted as a "build" number, and will \fIincrease\fR 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 \fIless than\fR the version without a tag\. -So, \fB0\.1\.2\-7 > 0\.1\.2\-7\-beta > 0\.1\.2\-6 > 0\.1\.2 > 0\.1\.2beta\fR -. -.IP "" 0 -. -.P -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\. -. -.SH "description" -Put a description in it\. It\'s a string\. This helps people discover your -package, as it\'s listed in \fBnpm search\fR\|\. -. -.SH "keywords" -Put keywords in it\. It\'s an array of strings\. This helps people -discover your package as it\'s listed in \fBnpm search\fR\|\. -. -.SH "homepage" -The url to the project homepage\. -. -.P -\fBNOTE\fR: This is \fInot\fR 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\. -. -.P -Literally\. Spit\. I\'m so not kidding\. -. -.SH "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\. -. -.P -It should look like this: -. -.IP "" 4 -. -.nf -{ "url" : "http://github\.com/owner/project/issues" -, "email" : "project@hostname\.com" -} -. -.fi -. -.IP "" 0 -. -.P -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\. -. -.P -If a url is provided, it will be used by the \fBnpm bugs\fR command\. -. -.SH "license" -You should specify a license for your package so that people know how they are -permitted to use it, and any restrictions you\'re placing on it\. -. -.P -The simplest way, assuming you\'re using a common license such as BSD or MIT, is -to just specify the name of the license you\'re using, like this: -. -.IP "" 4 -. -.nf -{ "license" : "BSD" } -. -.fi -. -.IP "" 0 -. -.P -If you have more complex licensing terms, or you want to provide more detail -in your package\.json file, you can use the more verbose plural form, like this: -. -.IP "" 4 -. -.nf -"licenses" : [ - { "type" : "MyLicense" - , "url" : "http://github\.com/owner/project/path/to/license" - } -] -. -.fi -. -.IP "" 0 -. -.P -It\'s also a good idea to include a license file at the top level in your package\. -. -.SH "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: -. -.IP "" 4 -. -.nf -{ "name" : "Barney Rubble" -, "email" : "b@rubble\.com" -, "url" : "http://barnyrubble\.tumblr\.com/" -} -. -.fi -. -.IP "" 0 -. -.P -Or you can shorten that all into a single string, and npm will parse it for you: -. -.IP "" 4 -. -.nf -"Barney Rubble (http://barnyrubble\.tumblr\.com/) -. -.fi -. -.IP "" 0 -. -.P -Both email and url are optional either way\. -. -.P -npm also sets a top\-level "maintainers" field with your npm user info\. -. -.SH "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\.) -. -.P -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"\. -. -.SH "main" -The main field is a module ID that is the primary entry point to your program\. -That is, if your package is named \fBfoo\fR, and a user installs it, and then does \fBrequire("foo")\fR, then your main module\'s exports object will be returned\. -. -.P -This should be a module ID relative to the root of your package folder\. -. -.P -For most modules, it makes the most sense to have a main script and often not -much else\. -. -.SH "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\.) -. -.P -To use this, supply a \fBbin\fR field in your package\.json which is a map of -command name to local file name\. On install, npm will symlink that file into \fBprefix/bin\fR for global installs, or \fB\|\./node_modules/\.bin/\fR for local -installs\. -. -.P -For example, npm has this: -. -.IP "" 4 -. -.nf -{ "bin" : { "npm" : "\./cli\.js" } } -. -.fi -. -.IP "" 0 -. -.P -So, when you install npm, it\'ll create a symlink from the \fBcli\.js\fR script to \fB/usr/local/bin/npm\fR\|\. -. -.P -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: -. -.IP "" 4 -. -.nf -{ "name": "my\-program" -, "version": "1\.2\.5" -, "bin": "\./path/to/program" } -. -.fi -. -.IP "" 0 -. -.P -would be the same as this: -. -.IP "" 4 -. -.nf -{ "name": "my\-program" -, "version": "1\.2\.5" -, "bin" : { "my\-program" : "\./path/to/program" } } -. -.fi -. -.IP "" 0 -. -.SH "man" -Specify either a single file or an array of filenames to put in place for the \fBman\fR program to find\. -. -.P -If only a single file is provided, then it\'s installed such that it is the -result from \fBman \fR, regardless of its actual filename\. For example: -. -.IP "" 4 -. -.nf -{ "name" : "foo" -, "version" : "1\.2\.3" -, "description" : "A packaged foo fooer for fooing foos" -, "main" : "foo\.js" -, "man" : "\./man/doc\.1" -} -. -.fi -. -.IP "" 0 -. -.P -would link the \fB\|\./man/doc\.1\fR file in such that it is the target for \fBman foo\fR -. -.P -If the filename doesn\'t start with the package name, then it\'s prefixed\. -So, this: -. -.IP "" 4 -. -.nf -{ "name" : "foo" -, "version" : "1\.2\.3" -, "description" : "A packaged foo fooer for fooing foos" -, "main" : "foo\.js" -, "man" : [ "\./man/foo\.1", "\./man/bar\.1" ] -} -. -.fi -. -.IP "" 0 -. -.P -will create files to do \fBman foo\fR and \fBman foo\-bar\fR\|\. -. -.P -Man files must end with a number, and optionally a \fB\|\.gz\fR suffix if they are -compressed\. The number dictates which man section the file is installed into\. -. -.IP "" 4 -. -.nf -{ "name" : "foo" -, "version" : "1\.2\.3" -, "description" : "A packaged foo fooer for fooing foos" -, "main" : "foo\.js" -, "man" : [ "\./man/foo\.1", "\./man/foo\.2" ] -} -. -.fi -. -.IP "" 0 -. -.P -will create entries for \fBman foo\fR and \fBman 2 foo\fR -. -.SH "directories" -The CommonJS Packages \fIhttp://wiki\.commonjs\.org/wiki/Packages/1\.0\fR spec details a -few ways that you can indicate the structure of your package using a \fBdirectories\fR -hash\. If you look at npm\'s package\.json \fIhttp://registry\.npmjs\.org/npm/latest\fR, -you\'ll see that it has directories for doc, lib, and man\. -. -.P -In the future, this information may be used in other creative ways\. -. -.SS "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\. -. -.SS "directories\.bin" -If you specify a "bin" directory, then all the files in that folder will -be used as the "bin" hash\. -. -.P -If you have a "bin" hash already, then this has no effect\. -. -.SS "directories\.man" -A folder that is full of man pages\. Sugar to generate a "man" array by -walking the folder\. -. -.SS "directories\.doc" -Put markdown files in here\. Eventually, these will be displayed nicely, -maybe, someday\. -. -.SS "directories\.example" -Put example scripts in here\. Someday, it might be exposed in some clever way\. -. -.SH "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 \fBnpm docs\fR -command will be able to find you\. -. -.P -Do it like this: -. -.IP "" 4 -. -.nf -"repository" : - { "type" : "git" - , "url" : "http://github\.com/isaacs/npm\.git" - } -"repository" : - { "type" : "svn" - , "url" : "http://v8\.googlecode\.com/svn/trunk/" - } -. -.fi -. -.IP "" 0 -. -.P -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\. -. -.SH "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\. -. -.P -See \fBnpm help scripts\fR to find out more about writing package scripts\. -. -.SH "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: -. -.IP "" 4 -. -.nf -{ "name" : "foo" -, "config" : { "port" : "8080" } } -. -.fi -. -.IP "" 0 -. -.P -and then had a "start" command that then referenced the \fBnpm_package_config_port\fR environment variable, then the user could -override that by doing \fBnpm config set foo:port 8001\fR\|\. -. -.P -See \fBnpm help config\fR and \fBnpm help scripts\fR for more on package -configs\. -. -.SH "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" -. -.P -\fBPlease do not put test harnesses in your \fBdependencies\fR hash\.\fR See \fBdevDependencies\fR, below\. -. -.P -Version range descriptors may be any of the following styles, where "version" -is a semver compatible version identifier\. -. -.IP "\(bu" 4 -\fBversion\fR Must match \fBversion\fR exactly -. -.IP "\(bu" 4 -\fB=version\fR Same as just \fBversion\fR -. -.IP "\(bu" 4 -\fB>version\fR Must be greater than \fBversion\fR -. -.IP "\(bu" 4 -\fB>=version\fR etc -. -.IP "\(bu" 4 -\fB=version1 <=version2\fR\|\. -. -.IP "\(bu" 4 -\fBrange1 || range2\fR Passes if either range1 or range2 are satisfied\. -. -.IP "\(bu" 4 -\fBgit\.\.\.\fR See \'Git URLs as Dependencies\' below -. -.IP "" 0 -. -.P -For example, these are all valid: -. -.IP "" 4 -. -.nf -{ "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" - } -} -. -.fi -. -.IP "" 0 -. -.SS "Tilde Version Ranges" -A range specifier starting with a tilde \fB~\fR character is matched against -a version in the following fashion\. -. -.IP "\(bu" 4 -The version must be at least as high as the range\. -. -.IP "\(bu" 4 -The version must be less than the next major revision above the range\. -. -.IP "" 0 -. -.P -For example, the following are equivalent: -. -.IP "\(bu" 4 -\fB"~1\.2\.3" = ">=1\.2\.3 <1\.3\.0"\fR -. -.IP "\(bu" 4 -\fB"~1\.2" = ">=1\.2\.0 <1\.3\.0"\fR -. -.IP "\(bu" 4 -\fB"~1" = ">=1\.0\.0 <1\.1\.0"\fR -. -.IP "" 0 -. -.SS "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\. -. -.P -The following are equivalent: -. -.IP "\(bu" 4 -\fB"1\.2\.x" = ">=1\.2\.0 <1\.3\.0"\fR -. -.IP "\(bu" 4 -\fB"1\.x\.x" = ">=1\.0\.0 <2\.0\.0"\fR -. -.IP "\(bu" 4 -\fB"1\.2" = "1\.2\.x"\fR -. -.IP "\(bu" 4 -\fB"1\.x" = "1\.x\.x"\fR -. -.IP "\(bu" 4 -\fB"1" = "1\.x\.x"\fR -. -.IP "" 0 -. -.P -You may not supply a comparator with a version containing an x\. Any -digits after the first "x" are ignored\. -. -.SS "URLs as Dependencies" -Starting with npm version 0\.2\.14, you may specify a tarball URL in place -of a version range\. -. -.P -This tarball will be downloaded and installed locally to your package at -install time\. -. -.SS "Git URLs as Dependencies" -Git urls can be of the form: -. -.IP "" 4 -. -.nf -git://github\.com/user/project\.git#commit\-ish -git+ssh://user@hostname: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 -. -.fi -. -.IP "" 0 -. -.P -The \fBcommit\-ish\fR can be any tag, sha, or branch which can be supplied as -an argument to \fBgit checkout\fR\|\. The default is \fBmaster\fR\|\. -. -.SH "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\. -. -.P -In this case, it\'s best to list these additional items in a \fBdevDependencies\fR hash\. -. -.P -These things will be installed whenever the \fB\-\-dev\fR configuration flag -is set\. This flag is set automatically when doing \fBnpm link\fR or when doing \fBnpm install\fR from the root of a package, and can be managed like any other npm -configuration param\. See \fBnpm help config\fR for more on the topic\. -. -.SH "bundledDependencies" -Array of package names that will be bundled when publishing the package\. -. -.P -If this is spelled \fB"bundleDependencies"\fR, then that is also honorable\. -. -.SH "optionalDependencies" -If a dependency can be used, but you would like npm to proceed if it -cannot be found or fails to install, then you may put it in the \fBoptionalDependencies\fR hash\. This is a map of package name to version -or url, just like the \fBdependencies\fR hash\. The difference is that -failure is tolerated\. -. -.P -It is still your program\'s responsibility to handle the lack of the -dependency\. For example, something like this: -. -.IP "" 4 -. -.nf -try { - var foo = require(\'foo\') - var fooVersion = require(\'foo/package\.json\')\.version -} catch (er) { - foo = null -} -if ( notGoodFooVersion(fooVersion) ) { - foo = null -} -// \.\. then later in your program \.\. -if (foo) { - foo\.doFooThings() -} -. -.fi -. -.IP "" 0 -. -.P -Entries in \fBoptionalDependencies\fR will override entries of the same name in \fBdependencies\fR, so it\'s usually best to only put in one place\. -. -.SH "engines" -You can specify the version of node that your stuff works on: -. -.IP "" 4 -. -.nf -{ "engines" : { "node" : ">=0\.1\.27 <0\.1\.30" } } -. -.fi -. -.IP "" 0 -. -.P -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\. -. -.P -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\. -. -.P -You can also use the "engines" field to specify which versions of npm -are capable of properly installing your program\. For example: -. -.IP "" 4 -. -.nf -{ "engines" : { "npm" : "~1\.0\.20" } } -. -.fi -. -.IP "" 0 -. -.P -Note that, unless the user has set the \fBengine\-strict\fR config flag, this -field is advisory only\. -. -.SH "engineStrict" -If you are sure that your module will \fIdefinitely not\fR run properly on -versions of Node/npm other than those specified in the \fBengines\fR hash, -then you can set \fB"engineStrict": true\fR in your package\.json file\. -This will override the user\'s \fBengine\-strict\fR config setting\. -. -.P -Please do not do this unless you are really very very sure\. If your -engines hash is something overly restrictive, you can quite easily and -inadvertently lock yourself into obscurity and prevent your users from -updating to new versions of Node\. Consider this choice carefully\. If -people abuse it, it will be removed in a future version of npm\. -. -.SH "os" -You can specify which operating systems your -module will run on: -. -.IP "" 4 -. -.nf -"os" : [ "darwin", "linux" ] -. -.fi -. -.IP "" 0 -. -.P -You can also blacklist instead of whitelist operating systems, -just prepend the blacklisted os with a \'!\': -. -.IP "" 4 -. -.nf -"os" : [ "!win32" ] -. -.fi -. -.IP "" 0 -. -.P -The host operating system is determined by \fBprocess\.platform\fR -. -.P -It is allowed to both blacklist, and whitelist, although there isn\'t any -good reason to do this\. -. -.SH "cpu" -If your code only runs on certain cpu architectures, -you can specify which ones\. -. -.IP "" 4 -. -.nf -"cpu" : [ "x64", "ia32" ] -. -.fi -. -.IP "" 0 -. -.P -Like the \fBos\fR option, you can also blacklist architectures: -. -.IP "" 4 -. -.nf -"cpu" : [ "!arm", "!mips" ] -. -.fi -. -.IP "" 0 -. -.P -The host architecture is determined by \fBprocess\.arch\fR -. -.SH "preferGlobal" -If your package is primarily a command\-line application that should be -installed globally, then set this value to \fBtrue\fR to provide a warning -if it is installed locally\. -. -.P -It doesn\'t actually prevent users from installing it locally, but it -does help prevent some confusion if it doesn\'t work as expected\. -. -.SH "private" -If you set \fB"private": true\fR in your package\.json, then npm will refuse -to publish it\. -. -.P -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 specific registry (for example, an internal registry), -then use the \fBpublishConfig\fR hash described below -to override the \fBregistry\fR config param at publish\-time\. -. -.SH "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\. -. -.P -Any config values can be overridden, but of course only "tag" and -"registry" probably matter for the purposes of publishing\. -. -.P -See \fBnpm help config\fR to see the list of config options that can be -overridden\. -. -.SH "SEE ALSO" -. -.IP "\(bu" 4 -npm help semver -. -.IP "\(bu" 4 -npm help init -. -.IP "\(bu" 4 -npm help version -. -.IP "\(bu" 4 -npm help config -. -.IP "\(bu" 4 -npm help help -. -.IP "\(bu" 4 -npm help faq -. -.IP "\(bu" 4 -npm help install -. -.IP "\(bu" 4 -npm help publish -. -.IP "\(bu" 4 -npm help rm -. -.IP "" 0 - diff --git a/deps/npm/man/man1/link.1 b/deps/npm/man/man1/link.1 deleted file mode 100644 index c5322b99c..000000000 --- a/deps/npm/man/man1/link.1 +++ /dev/null @@ -1,112 +0,0 @@ -.\" Generated with Ronnjs 0.3.8 -.\" http://github.com/kapouer/ronnjs/ -. -.TH "NPM\-LINK" "1" "July 2013" "" "" -. -.SH "NAME" -\fBnpm-link\fR \-\- Symlink a package folder -. -.SH "SYNOPSIS" -. -.nf -npm link (in package folder) -npm link -. -.fi -. -.SH "DESCRIPTION" -Package linking is a two\-step process\. -. -.P -First, \fBnpm link\fR in a package folder will create a globally\-installed -symbolic link from \fBprefix/package\-name\fR to the current folder\. -. -.P -Next, in some other location, \fBnpm link package\-name\fR will create a -symlink from the local \fBnode_modules\fR folder to the global symlink\. -. -.P -Note that \fBpackage\-name\fR is taken from \fBpackage\.json\fR , -not from directory name\. -. -.P -When creating tarballs for \fBnpm publish\fR, the linked packages are -"snapshotted" to their current state by resolving the symbolic links\. -. -.P -This is -handy for installing your own stuff, so that you can work on it and test it -iteratively without having to continually rebuild\. -. -.P -For example: -. -.IP "" 4 -. -.nf -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 -. -.fi -. -.IP "" 0 -. -.P -Now, any changes to ~/projects/node\-redis will be reflected in -~/projects/node\-bloggy/node_modules/redis/ -. -.P -You may also shortcut the two steps in one\. For example, to do the -above use\-case in a shorter way: -. -.IP "" 4 -. -.nf -cd ~/projects/node\-bloggy # go into the dir of your main project -npm link \.\./node\-redis # link the dir of your dependency -. -.fi -. -.IP "" 0 -. -.P -The second line is the equivalent of doing: -. -.IP "" 4 -. -.nf -(cd \.\./node\-redis; npm link) -npm link redis -. -.fi -. -.IP "" 0 -. -.P -That is, it first creates a global link, and then links the global -installation target into your project\'s \fBnode_modules\fR folder\. -. -.SH "SEE ALSO" -. -.IP "\(bu" 4 -npm help developers -. -.IP "\(bu" 4 -npm help faq -. -.IP "\(bu" 4 -npm help json -. -.IP "\(bu" 4 -npm help install -. -.IP "\(bu" 4 -npm help folders -. -.IP "\(bu" 4 -npm help config -. -.IP "" 0 - diff --git a/deps/npm/man/man1/list.1 b/deps/npm/man/man1/list.1 deleted file mode 100644 index 00a743ae1..000000000 --- a/deps/npm/man/man1/list.1 +++ /dev/null @@ -1,125 +0,0 @@ -.\" Generated with Ronnjs 0.3.8 -.\" http://github.com/kapouer/ronnjs/ -. -.TH "NPM\-LS" "1" "August 2012" "" "" -. -.SH "NAME" -\fBnpm-ls\fR \-\- List installed packages -. -.SH "SYNOPSIS" -. -.nf -npm list [ \.\.\.] -npm ls [ \.\.\.] -npm la [ \.\.\.] -npm ll [ \.\.\.] -. -.fi -. -.SH "DESCRIPTION" -This command will print to stdout all the versions of packages that are -installed, as well as their dependencies, in a tree\-structure\. -. -.P -Positional arguments are \fBname@version\-range\fR identifiers, which will -limit the results to only the paths to the packages named\. Note that -nested packages will \fIalso\fR show the paths to the specified packages\. -For example, running \fBnpm ls promzard\fR in npm\'s source tree will show: -. -.IP "" 4 -. -.nf -npm@1.1.59 /path/to/npm -└─┬ init\-package\-json@0\.0\.4 - └── promzard@0\.1\.5 -. -.fi -. -.IP "" 0 -. -.P -It will show print out extraneous, missing, and invalid packages\. -. -.P -When run as \fBll\fR or \fBla\fR, it shows extended information by default\. -. -.SH "CONFIGURATION" -. -.SS "json" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Show information in JSON format\. -. -.SS "long" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Show extended information\. -. -.SS "parseable" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Show parseable output instead of tree view\. -. -.SS "global" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -List packages in the global install prefix instead of in the current -project\. -. -.SH "SEE ALSO" -. -.IP "\(bu" 4 -npm help config -. -.IP "\(bu" 4 -npm help folders -. -.IP "\(bu" 4 -npm help install -. -.IP "\(bu" 4 -npm help link -. -.IP "\(bu" 4 -npm help prune -. -.IP "\(bu" 4 -npm help outdated -. -.IP "\(bu" 4 -npm help update -. -.IP "" 0 - diff --git a/deps/npm/man/man1/ln.1 b/deps/npm/man/man1/ln.1 deleted file mode 100644 index 74bf729b5..000000000 --- a/deps/npm/man/man1/ln.1 +++ /dev/null @@ -1,108 +0,0 @@ -.\" Generated with Ronnjs/v0.1 -.\" http://github.com/kapouer/ronnjs/ -. -.TH "NPM\-LINK" "1" "November 2011" "" "" -. -.SH "NAME" -\fBnpm-link\fR \-\- Symlink a package folder -. -.SH "SYNOPSIS" -. -.nf -npm link (in package folder) -npm link -. -.fi -. -.SH "DESCRIPTION" -Package linking is a two\-step process\. -. -.P -First, \fBnpm link\fR in a package folder will create a globally\-installed -symbolic link from \fBprefix/package\-name\fR to the current folder\. -. -.P -Next, in some other location, \fBnpm link package\-name\fR will create a -symlink from the local \fBnode_modules\fR folder to the global symlink\. -. -.P -When creating tarballs for \fBnpm publish\fR, the linked packages are -"snapshotted" to their current state by resolving the symbolic links\. -. -.P -This is -handy for installing your own stuff, so that you can work on it and test it -iteratively without having to continually rebuild\. -. -.P -For example: -. -.IP "" 4 -. -.nf -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 -. -.fi -. -.IP "" 0 -. -.P -Now, any changes to ~/projects/node\-redis will be reflected in -~/projects/node\-bloggy/node_modules/redis/ -. -.P -You may also shortcut the two steps in one\. For example, to do the -above use\-case in a shorter way: -. -.IP "" 4 -. -.nf -cd ~/projects/node\-bloggy # go into the dir of your main project -npm link \.\./node\-redis # link the dir of your dependency -. -.fi -. -.IP "" 0 -. -.P -The second line is the equivalent of doing: -. -.IP "" 4 -. -.nf -(cd \.\./node\-redis; npm link) -npm link redis -. -.fi -. -.IP "" 0 -. -.P -That is, it first creates a global link, and then links the global -installation target into your project\'s \fBnode_modules\fR folder\. -. -.SH "SEE ALSO" -. -.IP "\(bu" 4 -npm help developers -. -.IP "\(bu" 4 -npm help faq -. -.IP "\(bu" 4 -npm help json -. -.IP "\(bu" 4 -npm help install -. -.IP "\(bu" 4 -npm help folders -. -.IP "\(bu" 4 -npm help config -. -.IP "" 0 - diff --git a/deps/npm/man/man1/ls.1 b/deps/npm/man/man1/ls.1 deleted file mode 100644 index 4c0e793c4..000000000 --- a/deps/npm/man/man1/ls.1 +++ /dev/null @@ -1,130 +0,0 @@ -.\" Generated with Ronnjs 0.3.8 -.\" http://github.com/kapouer/ronnjs/ -. -.TH "NPM\-LS" "1" "July 2013" "" "" -. -.SH "NAME" -\fBnpm-ls\fR \-\- List installed packages -. -.SH "SYNOPSIS" -. -.nf -npm list [ \.\.\.] -npm ls [ \.\.\.] -npm la [ \.\.\.] -npm ll [ \.\.\.] -. -.fi -. -.SH "DESCRIPTION" -This command will print to stdout all the versions of packages that are -installed, as well as their dependencies, in a tree\-structure\. -. -.P -Positional arguments are \fBname@version\-range\fR identifiers, which will -limit the results to only the paths to the packages named\. Note that -nested packages will \fIalso\fR show the paths to the specified packages\. -For example, running \fBnpm ls promzard\fR in npm\'s source tree will show: -. -.IP "" 4 -. -.nf -npm@1.3.2 /path/to/npm -└─┬ init\-package\-json@0\.0\.4 - └── promzard@0\.1\.5 -. -.fi -. -.IP "" 0 -. -.P -It will print out extraneous, missing, and invalid packages\. -. -.P -If a project specifies git urls for dependencies these are shown -in parentheses after the name@version to make it easier for users to -recognize potential forks of a project\. -. -.P -When run as \fBll\fR or \fBla\fR, it shows extended information by default\. -. -.SH "CONFIGURATION" -. -.SS "json" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Show information in JSON format\. -. -.SS "long" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Show extended information\. -. -.SS "parseable" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -Show parseable output instead of tree view\. -. -.SS "global" -. -.IP "\(bu" 4 -Default: false -. -.IP "\(bu" 4 -Type: Boolean -. -.IP "" 0 -. -.P -List packages in the global install prefix instead of in the current -project\. -. -.SH "SEE ALSO" -. -.IP "\(bu" 4 -npm help config -. -.IP "\(bu" 4 -npm help folders -. -.IP "\(bu" 4 -npm help install -. -.IP "\(bu" 4 -npm help link -. -.IP "\(bu" 4 -npm help prune -. -.IP "\(bu" 4 -npm help outdated -. -.IP "\(bu" 4 -npm help update -. -.IP "" 0 - diff --git a/deps/npm/man/man1/npm-README.1 b/deps/npm/man/man1/npm-README.1 new file mode 100644 index 000000000..811acb2b1 --- /dev/null +++ b/deps/npm/man/man1/npm-README.1 @@ -0,0 +1,325 @@ +.\" Generated with Ronnjs 0.3.8 +.\" http://github.com/kapouer/ronnjs/ +. +.TH "NPM" "1" "July 2013" "" "" +. +.SH "NAME" +\fBnpm\fR \-\- node package manager +. +.SH "SYNOPSIS" +This is just enough info to get you up and running\. +. +.P +Much more info available via \fBnpm help\fR once it\'s installed\. +. +.SH "IMPORTANT" +\fBYou need node v0\.8 or higher to run this program\.\fR +. +.P +To install an old \fBand unsupported\fR version of npm that works on node 0\.3 +and prior, clone the git repo and dig through the old tags and branches\. +. +.SH "Super Easy Install" +npm comes with node now\. +. +.SS "Windows Computers" +Get the MSI\. npm is in it\. +. +.SS "Apple Macintosh Computers" +Get the pkg\. npm is in it\. +. +.SS "Other Sorts of Unices" +Run \fBmake install\fR\|\. npm will be installed with node\. +. +.P +If you want a more fancy pants install (a different version, customized +paths, etc\.) then read on\. +. +.SH "Fancy Install (Unix)" +There\'s a pretty robust install script at \fIhttps://npmjs\.org/install\.sh\fR\|\. You can download that and run it\. +. +.SS "Slightly Fancier" +You can set any npm configuration params with that script: +. +.IP "" 4 +. +.nf +npm_config_prefix=/some/path sh install\.sh +. +.fi +. +.IP "" 0 +. +.P +Or, you can run it in uber\-debuggery mode: +. +.IP "" 4 +. +.nf +npm_debug=1 sh install\.sh +. +.fi +. +.IP "" 0 +. +.SS "Even Fancier" +Get the code with git\. Use \fBmake\fR to build the docs and do other stuff\. +If you plan on hacking on npm, \fBmake link\fR is your friend\. +. +.P +If you\'ve got the npm source code, you can also semi\-permanently set +arbitrary config keys using the \fB\|\./configure \-\-key=val \.\.\.\fR, and then +run npm commands by doing \fBnode cli\.js \fR\|\. (This is helpful +for testing, or running stuff without actually installing npm itself\.) +. +.SH "Fancy Windows Install" +You can download a zip file from \fIhttps://npmjs\.org/dist/\fR, and unpack it +in the same folder where node\.exe lives\. +. +.P +If that\'s not fancy enough for you, then you can fetch the code with +git, and mess with it directly\. +. +.SH "Installing on Cygwin" +No\. +. +.SH "Permissions when Using npm to Install Other Stuff" +\fBtl;dr\fR +. +.IP "\(bu" 4 +Use \fBsudo\fR for greater safety\. Or don\'t, if you prefer not to\. +. +.IP "\(bu" 4 +npm will downgrade permissions if it\'s root before running any build +scripts that package authors specified\. +. +.IP "" 0 +. +.SS "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 \fBnobody\fR user prior +to running any package build or test commands\. +. +.P +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\. +. +.P +If you would like to ensure that npm \fBalways\fR runs scripts as the +"nobody" user, and have it fail if it cannot downgrade permissions, then +set the following configuration param: +. +.IP "" 4 +. +.nf +npm config set unsafe\-perm false +. +.fi +. +.IP "" 0 +. +.P +This will prevent running in unsafe mode, even as non\-root users\. +. +.SH "Uninstalling" +So sad to see you go\. +. +.IP "" 4 +. +.nf +sudo npm uninstall npm \-g +. +.fi +. +.IP "" 0 +. +.P +Or, if that fails, +. +.IP "" 4 +. +.nf +sudo make uninstall +. +.fi +. +.IP "" 0 +. +.SH "More Severe Uninstalling" +Usually, the above instructions are sufficient\. That will remove +npm, but leave behind anything you\'ve installed\. +. +.P +If you would like to remove all the packages that you have installed, +then you can use the \fBnpm ls\fR command to find them, and then \fBnpm rm\fR to +remove them\. +. +.P +To remove cruft left behind by npm 0\.x, you can use the included \fBclean\-old\.sh\fR script file\. You can run it conveniently like this: +. +.IP "" 4 +. +.nf +npm explore npm \-g \-\- sh scripts/clean\-old\.sh +. +.fi +. +.IP "" 0 +. +.P +npm uses two configuration files, one for per\-user configs, and another +for global (every\-user) configs\. You can view them by doing: +. +.IP "" 4 +. +.nf +npm config get userconfig # defaults to ~/\.npmrc +npm config get globalconfig # defaults to /usr/local/etc/npmrc +. +.fi +. +.IP "" 0 +. +.P +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\. +. +.SH "Using npm Programmatically" +If you would like to use npm programmatically, you can do that\. +It\'s not very well documented, but it \fIis\fR rather simple\. +. +.P +Most of the time, unless you actually want to do all the things that +npm does, you should try using one of npm\'s dependencies rather than +using npm itself, if possible\. +. +.P +Eventually, npm will be just a thin cli wrapper around the modules +that it depends on, but for now, there are some things that you must +use npm itself to do\. +. +.IP "" 4 +. +.nf +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) { \.\.\.\. }) +}) +. +.fi +. +.IP "" 0 +. +.P +The \fBload\fR function takes an object hash of the command\-line configs\. +The various \fBnpm\.commands\.\fR functions take an \fBarray\fR of +positional argument \fBstrings\fR\|\. The last argument to any \fBnpm\.commands\.\fR function is a callback\. Some commands take other +optional arguments\. Read the source\. +. +.P +You cannot set configs individually for any single npm function at this +time\. Since \fBnpm\fR is a singleton, any call to \fBnpm\.config\.set\fR will +change the value for \fIall\fR npm commands in that process\. +. +.P +See \fB\|\./bin/npm\-cli\.js\fR for an example of pulling config values off of the +command line arguments using nopt\. You may also want to check out \fBnpm +help config\fR to learn about all the options you can set there\. +. +.SH "More Docs" +Check out the docs \fIhttps://npmjs\.org/doc/\fR, +especially the faq \fIhttps://npmjs\.org/doc/faq\.html\fR\|\. +. +.P +You can use the \fBnpm help\fR command to read any of them\. +. +.P +If you\'re a developer, and you want to use npm to publish your program, +you should read this \fIhttps://npmjs\.org/doc/developers\.html\fR +. +.SH "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\. +. +.P +"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\. +. +.P +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\. +. +.P +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 \fIi@izs\.me\fR\|\. +. +.SS "In plain english" +This is mine; not my employer\'s, not Node\'s, not Joyent\'s, not Ryan +Dahl\'s\. +. +.P +If you publish something, it\'s yours, and you are solely accountable +for it\. Not me, not Node, not Joyent, not Ryan Dahl\. +. +.P +If other people publish something, it\'s theirs\. Not mine, not Node\'s, +not Joyent\'s, not Ryan Dahl\'s\. +. +.P +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\. +. +.P +If this concerns you, inspect the source before using packages\. +. +.SH "BUGS" +When you find issues, please report them: +. +.IP "\(bu" 4 +web: \fIhttps://github\.com/isaacs/npm/issues\fR +. +.IP "\(bu" 4 +email: \fInpm\-@googlegroups\.com\fR +. +.IP "" 0 +. +.P +Be sure to include \fIall\fR of the output from the npm command that didn\'t work +as expected\. The \fBnpm\-debug\.log\fR file is also helpful to provide\. +. +.P +You can also look for isaacs in #node\.js on irc://irc\.freenode\.net\. He +will no doubt tell you to put the output in a gist or email\. +. +.SH "SEE ALSO" +. +.IP "\(bu" 4 +npm help npm +. +.IP "\(bu" 4 +npm help faq +. +.IP "\(bu" 4 +npm help help +. +.IP "\(bu" 4 +npm help index +. +.IP "" 0 + diff --git a/deps/npm/man/man1/npm-adduser.1 b/deps/npm/man/man1/npm-adduser.1 new file mode 100644 index 000000000..8696248be --- /dev/null +++ b/deps/npm/man/man1/npm-adduser.1 @@ -0,0 +1,63 @@ +.\" Generated with Ronnjs 0.3.8 +.\" http://github.com/kapouer/ronnjs/ +. +.TH "NPM\-ADDUSER" "1" "July 2013" "" "" +. +.SH "NAME" +\fBnpm-adduser\fR \-\- Add a registry user account +. +.SH "SYNOPSIS" +. +.nf +npm adduser +. +.fi +. +.SH "DESCRIPTION" +Create or verify a user named \fB\fR in the npm registry, and +save the credentials to the \fB\|\.npmrc\fR file\. +. +.P +The username, password, and email are read in from prompts\. +. +.P +You may use this command to change your email address, but not username +or password\. +. +.P +To reset your password, go to \fIhttp://admin\.npmjs\.org/\fR +. +.P +You may use this command multiple times with the same user account to +authorize on a new machine\. +. +.SH "CONFIGURATION" +. +.SS "registry" +Default: http://registry\.npmjs\.org/ +. +.P +The base URL of the npm package registry\. +. +.SH "SEE ALSO" +. +.IP "\(bu" 4 +npm help registry +. +.IP "\(bu" 4 +npm help config +. +.IP "\(bu" 4 +npm help config +. +.IP "\(bu" 4 +npm help npmrc +. +.IP "\(bu" 4 +npm help owner +. +.IP "\(bu" 4 +npm help whoami +. +.IP "" 0 + diff --git a/deps/npm/man/man1/npm-bin.1 b/deps/npm/man/man1/npm-bin.1 new file mode 100644 index 000000000..fe6886053 --- /dev/null +++ b/deps/npm/man/man1/npm-bin.1 @@ -0,0 +1,40 @@ +.\" Generated with Ronnjs 0.3.8 +.\" http://github.com/kapouer/ronnjs/ +. +.TH "NPM\-BIN" "1" "July 2013" "" "" +. +.SH "NAME" +\fBnpm-bin\fR \-\- Display npm bin folder +. +.SH "SYNOPSIS" +. +.nf +npm bin +. +.fi +. +.SH "DESCRIPTION" +Print the folder where npm will install executables\. +. +.SH "SEE ALSO" +. +.IP "\(bu" 4 +npm help prefix +. +.IP "\(bu" 4 +npm help root +. +.IP "\(bu" 4 +npm help folders +. +.IP "\(bu" 4 +npm help config +. +.IP "\(bu" 4 +npm help config +. +.IP "\(bu" 4 +npm help npmrc +. +.IP "" 0 + diff --git a/deps/npm/man/man1/npm-bugs.1 b/deps/npm/man/man1/npm-bugs.1 new file mode 100644 index 000000000..dc2a83752 --- /dev/null +++ b/deps/npm/man/man1/npm-bugs.1 @@ -0,0 +1,76 @@ +.\" Generated with Ronnjs 0.3.8 +.\" http://github.com/kapouer/ronnjs/ +. +.TH "NPM\-BUGS" "1" "July 2013" "" "" +. +.SH "NAME" +\fBnpm-bugs\fR \-\- Bugs for a package in a web browser maybe +. +.SH "SYNOPSIS" +. +.nf +npm bugs +. +.fi +. +.SH "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 \fB\-\-browser\fR +config param\. +. +.SH "CONFIGURATION" +. +.SS "browser" +. +.IP "\(bu" 4 +Default: OS X: \fB"open"\fR, Windows: \fB"start"\fR, Others: \fB"xdg\-open"\fR +. +.IP "\(bu" 4 +Type: String +. +.IP "" 0 +. +.P +The browser that is called by the \fBnpm bugs\fR command to open websites\. +. +.SS "registry" +. +.IP "\(bu" 4 +Default: https://registry\.npmjs\.org/ +. +.IP "\(bu" 4 +Type: url +. +.IP "" 0 +. +.P +The base URL of the npm package registry\. +. +.SH "SEE ALSO" +. +.IP "\(bu" 4 +npm help docs +. +.IP "\(bu" 4 +npm help view +. +.IP "\(bu" 4 +npm help publish +. +.IP "\(bu" 4 +npm help registry +. +.IP "\(bu" 4 +npm help config +. +.IP "\(bu" 4 +npm help config +. +.IP "\(bu" 4 +npm help npmrc +. +.IP "\(bu" 4 +npm help package\.json +. +.IP "" 0 + diff --git a/deps/npm/man/man1/npm-build.1 b/deps/npm/man/man1/npm-build.1 new file mode 100644 index 000000000..1cb520911 --- /dev/null +++ b/deps/npm/man/man1/npm-build.1 @@ -0,0 +1,43 @@ +.\" Generated with Ronnjs 0.3.8 +.\" http://github.com/kapouer/ronnjs/ +. +.TH "NPM\-BUILD" "1" "July 2013" "" "" +. +.SH "NAME" +\fBnpm-build\fR \-\- Build a package +. +.SH "SYNOPSIS" +. +.nf +npm build +. +.fi +. +.IP "\(bu" 4 +\fB\fR: +A folder containing a \fBpackage\.json\fR file in its root\. +. +.IP "" 0 +. +.SH "DESCRIPTION" +This is the plumbing command called by \fBnpm link\fR and \fBnpm install\fR\|\. +. +.P +It should generally not be called directly\. +. +.SH "SEE ALSO" +. +.IP "\(bu" 4 +npm help install +. +.IP "\(bu" 4 +npm help link +. +.IP "\(bu" 4 +npm help scripts +. +.IP "\(bu" 4 +npm help package\.json +. +.IP "" 0 + diff --git a/deps/npm/man/man1/npm-bundle.1 b/deps/npm/man/man1/npm-bundle.1 new file mode 100644 index 000000000..880d23f9d --- /dev/null +++ b/deps/npm/man/man1/npm-bundle.1 @@ -0,0 +1,23 @@ +.\" Generated with Ronnjs 0.3.8 +.\" http://github.com/kapouer/ronnjs/ +. +.TH "NPM\-BUNDLE" "1" "July 2013" "" "" +. +.SH "NAME" +\fBnpm-bundle\fR \-\- REMOVED +. +.SH "DESCRIPTION" +The \fBnpm bundle\fR 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\. +. +.P +Just use \fBnpm install\fR now to do what \fBnpm bundle\fR used to do\. +. +.SH "SEE ALSO" +. +.IP "\(bu" 4 +npm help install +. +.IP "" 0 + diff --git a/deps/npm/man/man1/npm-cache.1 b/deps/npm/man/man1/npm-cache.1 new file mode 100644 index 000000000..1aa5c6286 --- /dev/null +++ b/deps/npm/man/man1/npm-cache.1 @@ -0,0 +1,103 @@ +.\" Generated with Ronnjs 0.3.8 +.\" http://github.com/kapouer/ronnjs/ +. +.TH "NPM\-CACHE" "1" "July 2013" "" "" +. +.SH "NAME" +\fBnpm-cache\fR \-\- Manipulates packages cache +. +.SH "SYNOPSIS" +. +.nf +npm cache add +npm cache add +npm cache add +npm cache add @ +npm cache ls [] +npm cache clean [] +. +.fi +. +.SH "DESCRIPTION" +Used to add, list, or clear the npm cache folder\. +. +.IP "\(bu" 4 +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\. +. +.IP "\(bu" 4 +ls: +Show the data in the cache\. Argument is a path to show in the cache +folder\. Works a bit like the \fBfind\fR program, but limited by the \fBdepth\fR config\. +. +.IP "\(bu" 4 +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\. +. +.IP "" 0 +. +.SH "DETAILS" +npm stores cache data in \fB$HOME/\.npm\fR\|\. For each package that is added +to the cache, three pieces of information are stored in \fB{cache}/{name}/{version}\fR: +. +.IP "\(bu" 4 +\|\.\.\./package/: +A folder containing the package contents as they appear in the tarball\. +. +.IP "\(bu" 4 +\|\.\.\./package\.json: +The package\.json file, as npm sees it, with overlays applied and a _id attribute\. +. +.IP "\(bu" 4 +\|\.\.\./package\.tgz: +The tarball for that version\. +. +.IP "" 0 +. +.P +Additionally, whenever a registry request is made, a \fB\|\.cache\.json\fR file +is placed at the corresponding URI, to store the ETag and the requested +data\. +. +.P +Commands that make non\-essential registry requests (such as \fBsearch\fR and \fBview\fR, or the completion scripts) generally specify a minimum timeout\. +If the \fB\|\.cache\.json\fR file is younger than the specified timeout, then +they do not make an HTTP request to the registry\. +. +.SH "CONFIGURATION" +. +.SS "cache" +Default: \fB$HOME/\.npm\fR on Posix, or \fB$HOME/npm\-cache\fR on Windows\. +. +.P +The root cache folder\. +. +.SH "SEE ALSO" +. +.IP "\(bu" 4 +npm help folders +. +.IP "\(bu" 4 +npm help config +. +.IP "\(bu" 4 +npm help config +. +.IP "\(bu" 4 +npm help npmrc +. +.IP "\(bu" 4 +npm help install +. +.IP "\(bu" 4 +npm help publish +. +.IP "\(bu" 4 +npm help pack +. +.IP "" 0 + diff --git a/deps/npm/man/man1/npm-completion.1 b/deps/npm/man/man1/npm-completion.1 new file mode 100644 index 000000000..25e7bf10c --- /dev/null +++ b/deps/npm/man/man1/npm-completion.1 @@ -0,0 +1,47 @@ +.\" Generated with Ronnjs 0.3.8 +.\" http://github.com/kapouer/ronnjs/ +. +.TH "NPM\-COMPLETION" "1" "July 2013" "" "" +. +.SH "NAME" +\fBnpm-completion\fR \-\- Tab Completion for npm +. +.SH "SYNOPSIS" +. +.nf +\|\. <(npm completion) +. +.fi +. +.SH "DESCRIPTION" +Enables tab\-completion in all npm commands\. +. +.P +The synopsis above +loads the completions into your current shell\. Adding it to +your ~/\.bashrc or ~/\.zshrc will make the completions available +everywhere\. +. +.P +You may of course also pipe the output of npm completion to a file +such as \fB/usr/local/etc/bash_completion\.d/npm\fR if you have a system +that will read that file for you\. +. +.P +When \fBCOMP_CWORD\fR, \fBCOMP_LINE\fR, and \fBCOMP_POINT\fR are defined in the +environment, \fBnpm completion\fR acts in "plumbing mode", and outputs +completions based on the arguments\. +. +.SH "SEE ALSO" +. +.IP "\(bu" 4 +npm help developers +. +.IP "\(bu" 4 +npm help faq +. +.IP "\(bu" 4 +npm help npm +. +.IP "" 0 + diff --git a/deps/npm/man/man1/npm-config.1 b/deps/npm/man/man1/npm-config.1 new file mode 100644 index 000000000..55a00995c --- /dev/null +++ b/deps/npm/man/man1/npm-config.1 @@ -0,0 +1,112 @@ +.\" Generated with Ronnjs 0.3.8 +.\" http://github.com/kapouer/ronnjs/ +. +.TH "NPM\-CONFIG" "1" "July 2013" "" "" +. +.SH "NAME" +\fBnpm-config\fR \-\- Manage the npm configuration files +. +.SH "SYNOPSIS" +. +.nf +npm config set [\-\-global] +npm config get +npm config delete +npm config list +npm config edit +npm get +npm set [\-\-global] +. +.fi +. +.SH "DESCRIPTION" +npm gets its config settings from the command line, environment +variables, \fBnpmrc\fR files, and in some cases, the \fBpackage\.json\fR file\. +. +.P +npm help See npmrc for more information about the npmrc files\. +. +.P +npm help See \fBnpm\-config\fR for a more thorough discussion of the mechanisms +involved\. +. +.P +The \fBnpm config\fR command can be used to update and edit the contents +of the user and global npmrc files\. +. +.SH "Sub\-commands" +Config supports the following sub\-commands: +. +.SS "set" +. +.nf +npm config set key value +. +.fi +. +.P +Sets the config key to the value\. +. +.P +If value is omitted, then it sets it to "true"\. +. +.SS "get" +. +.nf +npm config get key +. +.fi +. +.P +Echo the config value to stdout\. +. +.SS "list" +. +.nf +npm config list +. +.fi +. +.P +Show all the config settings\. +. +.SS "delete" +. +.nf +npm config delete key +. +.fi +. +.P +Deletes the key from all configuration files\. +. +.SS "edit" +. +.nf +npm config edit +. +.fi +. +.P +Opens the config file in an editor\. Use the \fB\-\-global\fR flag to edit the +global config\. +. +.SH "SEE ALSO" +. +.IP "\(bu" 4 +npm help folders +. +.IP "\(bu" 4 +npm help config +. +.IP "\(bu" 4 +npm help package\.json +. +.IP "\(bu" 4 +npm help npmrc +. +.IP "\(bu" 4 +npm help npm +. +.IP "" 0 + diff --git a/deps/npm/man/man1/npm-dedupe.1 b/deps/npm/man/man1/npm-dedupe.1 new file mode 100644 index 000000000..5446cbdd8 --- /dev/null +++ b/deps/npm/man/man1/npm-dedupe.1 @@ -0,0 +1,90 @@ +.\" Generated with Ronnjs 0.3.8 +.\" http://github.com/kapouer/ronnjs/ +. +.TH "NPM\-DEDUPE" "1" "July 2013" "" "" +. +.SH "NAME" +\fBnpm-dedupe\fR \-\- Reduce duplication +. +.SH "SYNOPSIS" +. +.nf +npm dedupe [package names\.\.\.] +. +.fi +. +.SH "DESCRIPTION" +Searches the local package tree and attempts to simplify the overall +structure by moving dependencies further up the tree, where they can +be more effectively shared by multiple dependent packages\. +. +.P +For example, consider this dependency graph: +. +.IP "" 4 +. +.nf +a ++\-\- b <\-\- depends on c@1\.0\.x +| `\-\- c@1\.0\.3 +`\-\- d <\-\- depends on c@~1\.0\.9 + `\-\- c@1\.0\.10 +. +.fi +. +.IP "" 0 +. +.P +npm help In this case, \fBnpm\-dedupe\fR will transform the tree to: +. +.IP "" 4 +. +.nf +a ++\-\- b ++\-\- d +`\-\- c@1\.0\.10 +. +.fi +. +.IP "" 0 +. +.P +Because of the hierarchical nature of node\'s module lookup, b and d +will both get their dependency met by the single c package at the root +level of the tree\. +. +.P +If a suitable version exists at the target location in the tree +already, then it will be left untouched, but the other duplicates will +be deleted\. +. +.P +If no suitable version can be found, then a warning is printed, and +nothing is done\. +. +.P +If any arguments are supplied, then they are filters, and only the +named packages will be touched\. +. +.P +Note that this operation transforms the dependency tree, and may +result in packages getting updated versions, perhaps from the npm +registry\. +. +.P +This feature is experimental, and may change in future versions\. +. +.SH "SEE ALSO" +. +.IP "\(bu" 4 +npm help ls +. +.IP "\(bu" 4 +npm help update +. +.IP "\(bu" 4 +npm help install +. +.IP "" 0 + diff --git a/deps/npm/man/man1/npm-deprecate.1 b/deps/npm/man/man1/npm-deprecate.1 new file mode 100644 index 000000000..265e437cb --- /dev/null +++ b/deps/npm/man/man1/npm-deprecate.1 @@ -0,0 +1,48 @@ +.\" Generated with Ronnjs 0.3.8 +.\" http://github.com/kapouer/ronnjs/ +. +.TH "NPM\-DEPRECATE" "1" "July 2013" "" "" +. +.SH "NAME" +\fBnpm-deprecate\fR \-\- Deprecate a version of a package +. +.SH "SYNOPSIS" +. +.nf +npm deprecate [@] +. +.fi +. +.SH "DESCRIPTION" +This command will update the npm registry entry for a package, providing +a deprecation warning to all who attempt to install it\. +. +.P +It works on version ranges as well as specific versions, so you can do +something like this: +. +.IP "" 4 +. +.nf +npm deprecate my\-thing@"< 0\.2\.3" "critical bug fixed in v0\.2\.3" +. +.fi +. +.IP "" 0 +. +.P +Note that you must be the package owner to deprecate something\. See the \fBowner\fR and \fBadduser\fR help topics\. +. +.P +To un\-deprecate a package, specify an empty string (\fB""\fR) for the \fBmessage\fR argument\. +. +.SH "SEE ALSO" +. +.IP "\(bu" 4 +npm help publish +. +.IP "\(bu" 4 +npm help registry +. +.IP "" 0 + diff --git a/deps/npm/man/man1/npm-docs.1 b/deps/npm/man/man1/npm-docs.1 new file mode 100644 index 000000000..a3a9c4751 --- /dev/null +++ b/deps/npm/man/man1/npm-docs.1 @@ -0,0 +1,74 @@ +.\" Generated with Ronnjs 0.3.8 +.\" http://github.com/kapouer/ronnjs/ +. +.TH "NPM\-DOCS" "1" "July 2013" "" "" +. +.SH "NAME" +\fBnpm-docs\fR \-\- Docs for a package in a web browser maybe +. +.SH "SYNOPSIS" +. +.nf +npm docs +npm home +. +.fi +. +.SH "DESCRIPTION" +This command tries to guess at the likely location of a package\'s +documentation URL, and then tries to open it using the \fB\-\-browser\fR +config param\. +. +.SH "CONFIGURATION" +. +.SS "browser" +. +.IP "\(bu" 4 +Default: OS X: \fB"open"\fR, Windows: \fB"start"\fR, Others: \fB"xdg\-open"\fR +. +.IP "\(bu" 4 +Type: String +. +.IP "" 0 +. +.P +The browser that is called by the \fBnpm docs\fR command to open websites\. +. +.SS "registry" +. +.IP "\(bu" 4 +Default: https://registry\.npmjs\.org/ +. +.IP "\(bu" 4 +Type: url +. +.IP "" 0 +. +.P +The base URL of the npm package registry\. +. +.SH "SEE ALSO" +. +.IP "\(bu" 4 +npm help view +. +.IP "\(bu" 4 +npm help publish +. +.IP "\(bu" 4 +npm help registry +. +.IP "\(bu" 4 +npm help config +. +.IP "\(bu" 4 +npm help config +. +.IP "\(bu" 4 +npm help npmrc +. +.IP "\(bu" 4 +npm help package\.json +. +.IP "" 0 + diff --git a/deps/npm/man/man1/npm-edit.1 b/deps/npm/man/man1/npm-edit.1 new file mode 100644 index 000000000..48213a586 --- /dev/null +++ b/deps/npm/man/man1/npm-edit.1 @@ -0,0 +1,66 @@ +.\" Generated with Ronnjs 0.3.8 +.\" http://github.com/kapouer/ronnjs/ +. +.TH "NPM\-EDIT" "1" "July 2013" "" "" +. +.SH "NAME" +\fBnpm-edit\fR \-\- Edit an installed package +. +.SH "SYNOPSIS" +. +.nf +npm edit [@] +. +.fi +. +.SH "DESCRIPTION" +Opens the package folder in the default editor (or whatever you\'ve +npm help configured as the npm \fBeditor\fR config \-\- see \fBnpm\-config\fR\|\.) +. +.P +After it has been edited, the package is rebuilt so as to pick up any +changes in compiled packages\. +. +.P +For instance, you can do \fBnpm install connect\fR to install connect +into your package, and then \fBnpm edit connect\fR to make a few +changes to your locally installed copy\. +. +.SH "CONFIGURATION" +. +.SS "editor" +. +.IP "\(bu" 4 +Default: \fBEDITOR\fR environment variable if set, or \fB"vi"\fR on Posix, +or \fB"notepad"\fR on Windows\. +. +.IP "\(bu" 4 +Type: path +. +.IP "" 0 +. +.P +The command to run for \fBnpm edit\fR or \fBnpm config edit\fR\|\. +. +.SH "SEE ALSO" +. +.IP "\(bu" 4 +npm help folders +. +.IP "\(bu" 4 +npm help explore +. +.IP "\(bu" 4 +npm help install +. +.IP "\(bu" 4 +npm help config +. +.IP "\(bu" 4 +npm help config +. +.IP "\(bu" 4 +npm help npmrc +. +.IP "" 0 + diff --git a/deps/npm/man/man1/npm-explore.1 b/deps/npm/man/man1/npm-explore.1 new file mode 100644 index 000000000..c534f4ac6 --- /dev/null +++ b/deps/npm/man/man1/npm-explore.1 @@ -0,0 +1,76 @@ +.\" Generated with Ronnjs 0.3.8 +.\" http://github.com/kapouer/ronnjs/ +. +.TH "NPM\-EXPLORE" "1" "July 2013" "" "" +. +.SH "NAME" +\fBnpm-explore\fR \-\- Browse an installed package +. +.SH "SYNOPSIS" +. +.nf +npm explore [@] [ \-\- ] +. +.fi +. +.SH "DESCRIPTION" +Spawn a subshell in the directory of the installed package specified\. +. +.P +If a command is specified, then it is run in the subshell, which then +immediately terminates\. +. +.P +This is particularly handy in the case of git submodules in the \fBnode_modules\fR folder: +. +.IP "" 4 +. +.nf +npm explore some\-dependency \-\- git pull origin master +. +.fi +. +.IP "" 0 +. +.P +Note that the package is \fInot\fR automatically rebuilt afterwards, so be +sure to use \fBnpm rebuild \fR if you make any changes\. +. +.SH "CONFIGURATION" +. +.SS "shell" +. +.IP "\(bu" 4 +Default: SHELL environment variable, or "bash" on Posix, or "cmd" on +Windows +. +.IP "\(bu" 4 +Type: path +. +.IP "" 0 +. +.P +The shell to run for the \fBnpm explore\fR command\. +. +.SH "SEE ALSO" +. +.IP "\(bu" 4 +npm help submodule +. +.IP "\(bu" 4 +npm help folders +. +.IP "\(bu" 4 +npm help edit +. +.IP "\(bu" 4 +npm help rebuild +. +.IP "\(bu" 4 +npm help build +. +.IP "\(bu" 4 +npm help install +. +.IP "" 0 + diff --git a/deps/npm/man/man1/npm-help-search.1 b/deps/npm/man/man1/npm-help-search.1 new file mode 100644 index 000000000..098bcedea --- /dev/null +++ b/deps/npm/man/man1/npm-help-search.1 @@ -0,0 +1,59 @@ +.\" Generated with Ronnjs 0.3.8 +.\" http://github.com/kapouer/ronnjs/ +. +.TH "NPM\-HELP\-SEARCH" "1" "July 2013" "" "" +. +.SH "NAME" +\fBnpm-help-search\fR \-\- Search npm help documentation +. +.SH "SYNOPSIS" +. +.nf +npm help\-search some search terms +. +.fi +. +.SH "DESCRIPTION" +This command will search the npm markdown documentation files for the +terms provided, and then list the results, sorted by relevance\. +. +.P +If only one result is found, then it will show that help topic\. +. +.P +If the argument to \fBnpm help\fR is not a known help topic, then it will +call \fBhelp\-search\fR\|\. It is rarely if ever necessary to call this +command directly\. +. +.SH "CONFIGURATION" +. +.SS "long" +. +.IP "\(bu" 4 +Type: Boolean +. +.IP "\(bu" 4 +Default false +. +.IP "" 0 +. +.P +If true, the "long" flag will cause help\-search to output context around +where the terms were found in the documentation\. +. +.P +If false, then help\-search will just list out the help topics found\. +. +.SH "SEE ALSO" +. +.IP "\(bu" 4 +npm help npm +. +.IP "\(bu" 4 +npm help faq +. +.IP "\(bu" 4 +npm help help +. +.IP "" 0 + diff --git a/deps/npm/man/man1/npm-help.1 b/deps/npm/man/man1/npm-help.1 new file mode 100644 index 000000000..ce5f77266 --- /dev/null +++ b/deps/npm/man/man1/npm-help.1 @@ -0,0 +1,77 @@ +.\" Generated with Ronnjs 0.3.8 +.\" http://github.com/kapouer/ronnjs/ +. +.TH "NPM\-HELP" "1" "July 2013" "" "" +. +.SH "NAME" +\fBnpm-help\fR \-\- Get help on npm +. +.SH "SYNOPSIS" +. +.nf +npm help +npm help some search terms +. +.fi +. +.SH "DESCRIPTION" +If supplied a topic, then show the appropriate documentation page\. +. +.P +If the topic does not exist, or if multiple terms are provided, then run +the \fBhelp\-search\fR command to find a match\. Note that, if \fBhelp\-search\fR +finds a single subject, then it will run \fBhelp\fR on that topic, so unique +matches are equivalent to specifying a topic name\. +. +.SH "CONFIGURATION" +. +.SS "viewer" +. +.IP "\(bu" 4 +Default: "man" on Posix, "browser" on Windows +. +.IP "\(bu" 4 +Type: path +. +.IP "" 0 +. +.P +The program to use to view help content\. +. +.P +Set to \fB"browser"\fR to view html help content in the default web browser\. +. +.SH "SEE ALSO" +. +.IP "\(bu" 4 +npm help npm +. +.IP "\(bu" 4 +README +. +.IP "\(bu" 4 +npm help faq +. +.IP "\(bu" 4 +npm help folders +. +.IP "\(bu" 4 +npm help config +. +.IP "\(bu" 4 +npm help config +. +.IP "\(bu" 4 +npm help npmrc +. +.IP "\(bu" 4 +npm help package\.json +. +.IP "\(bu" 4 +npm help help\-search +. +.IP "\(bu" 4 +npm help index +. +.IP "" 0 + diff --git a/deps/npm/man/man1/npm-init.1 b/deps/npm/man/man1/npm-init.1 new file mode 100644 index 000000000..4e8b6b1a4 --- /dev/null +++ b/deps/npm/man/man1/npm-init.1 @@ -0,0 +1,43 @@ +.\" Generated with Ronnjs 0.3.8 +.\" http://github.com/kapouer/ronnjs/ +. +.TH "NPM\-INIT" "1" "July 2013" "" "" +. +.SH "NAME" +\fBnpm-init\fR \-\- Interactively create a package\.json file +. +.SH "SYNOPSIS" +. +.nf +npm init +. +.fi +. +.SH "DESCRIPTION" +This will ask you a bunch of questions, and then write a package\.json for you\. +. +.P +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\. +. +.P +If you already have a package\.json file, it\'ll read that first, and default to +the options in there\. +. +.P +It is strictly additive, so it does not delete options from your package\.json +without a really good reason to do so\. +. +.SH "SEE ALSO" +. +.IP "\(bu" 4 +\fIhttps://github\.com/isaacs/init\-package\-json\fR +. +.IP "\(bu" 4 +npm help package\.json +. +.IP "\(bu" 4 +npm help version +. +.IP "" 0 + diff --git a/deps/npm/man/man1/npm-install.1 b/deps/npm/man/man1/npm-install.1 new file mode 100644 index 000000000..d6ddfac94 --- /dev/null +++ b/deps/npm/man/man1/npm-install.1 @@ -0,0 +1,423 @@ +.\" Generated with Ronnjs 0.3.8 +.\" http://github.com/kapouer/ronnjs/ +. +.TH "NPM\-INSTALL" "1" "July 2013" "" "" +. +.SH "NAME" +\fBnpm-install\fR \-\- Install a package +. +.SH "SYNOPSIS" +. +.nf +npm install (with no args in a package dir) +npm install +npm install +npm install +npm install [\-\-save|\-\-save\-dev|\-\-save\-optional] +npm install @ +npm install @ +npm install @ +npm install @ +. +.fi +. +.SH "DESCRIPTION" +This command installs a package, and any packages that it depends on\. If the +package has a shrinkwrap file, the installation of dependencies will be driven +npm help by that\. See npm\-shrinkwrap\. +. +.P +A \fBpackage\fR is: +. +.IP "\(bu" 4 +a) a folder containing a program described by a package\.json file +. +.IP "\(bu" 4 +b) a gzipped tarball containing (a) +. +.IP "\(bu" 4 +c) a url that resolves to (b) +. +.IP "\(bu" 4 +d) a \fB@\fR that is published on the registry with (c) +. +.IP "\(bu" 4 +e) a \fB@\fR that points to (d) +. +.IP "\(bu" 4 +f) a \fB\fR that has a "latest" tag satisfying (e) +. +.IP "\(bu" 4 +g) a \fB\fR that resolves to (b) +. +.IP "" 0 +. +.P +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)\. +. +.IP "\(bu" 4 +\fBnpm install\fR (in package directory, no arguments): +. +.IP +Install the dependencies in the local node_modules folder\. +. +.IP +In global mode (ie, with \fB\-g\fR or \fB\-\-global\fR appended to the command), +it installs the current package context (ie, the current working +directory) as a global package\. +. +.IP "\(bu" 4 +\fBnpm install \fR: +. +.IP +Install a package that is sitting in a folder on the filesystem\. +. +.IP "\(bu" 4 +\fBnpm install \fR: +. +.IP +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 \fBnpm link\fR\|\. +. +.IP +Example: +. +.IP "" 4 +. +.nf + npm install \./package\.tgz +. +.fi +. +.IP "" 0 + +. +.IP "\(bu" 4 +\fBnpm install \fR: +. +.IP +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://" +. +.IP +Example: +. +.IP "" 4 +. +.nf + npm install https://github\.com/indexzero/forever/tarball/v0\.5\.6 +. +.fi +. +.IP "" 0 + +. +.IP "\(bu" 4 +\fBnpm install [\-\-save|\-\-save\-dev|\-\-save\-optional]\fR: +. +.IP +Do a \fB@\fR install, where \fB\fR is the "tag" config\. (npm help See \fBnpm\-config\fR\|\.) +. +.IP +In most cases, this will install the latest version +of the module published on npm\. +. +.IP +Example: +. +.IP + npm install sax +. +.IP +\fBnpm install\fR takes 3 exclusive, optional flags which save or update +the package version in your main package\.json: +. +.IP "\(bu" 4 +\fB\-\-save\fR: Package will appear in your \fBdependencies\fR\|\. +. +.IP "\(bu" 4 +\fB\-\-save\-dev\fR: Package will appear in your \fBdevDependencies\fR\|\. +. +.IP "\(bu" 4 +\fB\-\-save\-optional\fR: Package will appear in your \fBoptionalDependencies\fR\|\. +. +.IP +Examples: +. +.IP + npm install sax \-\-save + npm install node\-tap \-\-save\-dev + npm install dtrace\-provider \-\-save\-optional +. +.IP +\fBNote\fR: If there is a file or folder named \fB\fR 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\. +. +.IP "" 0 + +. +.IP "\(bu" 4 +\fBnpm install @\fR: +. +.IP +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\. +. +.IP +Example: +. +.IP "" 4 +. +.nf + npm install sax@latest +. +.fi +. +.IP "" 0 + +. +.IP "\(bu" 4 +\fBnpm install @\fR: +. +.IP +Install the specified version of the package\. This will fail if the version +has not been published to the registry\. +. +.IP +Example: +. +.IP "" 4 +. +.nf + npm install sax@0\.1\.1 +. +.fi +. +.IP "" 0 + +. +.IP "\(bu" 4 +\fBnpm install @\fR: +. +.IP +Install a version of the package matching the specified version range\. This +npm help will follow the same rules for resolving dependencies described in \fBpackage\.json\fR\|\. +. +.IP +Note that most version ranges must be put in quotes so that your shell will +treat it as a single argument\. +. +.IP +Example: +. +.IP + npm install sax@">=0\.1\.0 <0\.2\.0" +. +.IP "\(bu" 4 +\fBnpm install \fR: +. +.IP +Install a package by cloning a git remote url\. The format of the git +url is: +. +.IP + ://[@][#] +. +.IP +\fB\fR is one of \fBgit\fR, \fBgit+ssh\fR, \fBgit+http\fR, or \fBgit+https\fR\|\. If no \fB\fR is specified, then \fBmaster\fR is +used\. +. +.IP +Examples: +. +.IP "" 4 +. +.nf + 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 +. +.fi +. +.IP "" 0 + +. +.IP "" 0 +. +.P +You may combine multiple arguments, and even multiple types of arguments\. +For example: +. +.IP "" 4 +. +.nf +npm install sax@">=0\.1\.0 <0\.2\.0" bench supervisor +. +.fi +. +.IP "" 0 +. +.P +The \fB\-\-tag\fR argument will apply to all of the specified install targets\. +. +.P +The \fB\-\-force\fR argument will force npm to fetch remote resources even if a +local copy exists on disk\. +. +.IP "" 4 +. +.nf +npm install sax \-\-force +. +.fi +. +.IP "" 0 +. +.P +The \fB\-\-global\fR argument will cause npm to install the package globally +npm help rather than locally\. See \fBnpm\-folders\fR\|\. +. +.P +The \fB\-\-link\fR argument will cause npm to link global installs into the +local space in some cases\. +. +.P +The \fB\-\-no\-bin\-links\fR argument will prevent npm from creating symlinks for +any binaries the package might contain\. +. +.P +The \fB\-\-no\-shrinkwrap\fR argument, which will ignore an available +shrinkwrap file and use the package\.json instead\. +. +.P +The \fB\-\-nodedir=/path/to/node/source\fR argument will allow npm to find the +node source code so that npm can compile native modules\. +. +.P +npm help See \fBnpm\-config\fR\|\. Many of the configuration params have some +effect on installation, since that\'s most of what npm does\. +. +.SH "ALGORITHM" +To install a package, npm uses the following algorithm: +. +.IP "" 4 +. +.nf +install(where, what, family, ancestors) +fetch what, unpack to /node_modules/ +for each dep in what\.dependencies + resolve dep to precise version +for each dep@version in what\.dependencies + not in /node_modules//node_modules/* + and not in + add precise version deps to + install(/node_modules/, dep, family) +. +.fi +. +.IP "" 0 +. +.P +For this \fBpackage{dep}\fR structure: \fBA{B,C}, B{C}, C{D}\fR, +this algorithm produces: +. +.IP "" 4 +. +.nf +A ++\-\- B +`\-\- C + `\-\- D +. +.fi +. +.IP "" 0 +. +.P +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\. +. +.P +npm help See npm\-folders for a more detailed description of the specific +folder structures that npm creates\. +. +.SS "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: +. +.IP "" 4 +. +.nf +A \-> B \-> A\' \-> B\' \-> A \-> B \-> A\' \-> B\' \-> A \-> \.\.\. +. +.fi +. +.IP "" 0 +. +.P +where \fBA\fR is some version of a package, and \fBA\'\fR is a different version +of the same package\. Because \fBB\fR depends on a different version of \fBA\fR +than the one that is already in the tree, it must install a separate +copy\. The same is true of \fBA\'\fR, which must install \fBB\'\fR\|\. Because \fBB\'\fR +depends on the original version of \fBA\fR, which has been overridden, the +cycle falls into infinite regress\. +. +.P +To avoid this situation, npm flat\-out refuses to install any \fBname@version\fR 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\. +. +.SH "SEE ALSO" +. +.IP "\(bu" 4 +npm help folders +. +.IP "\(bu" 4 +npm help update +. +.IP "\(bu" 4 +npm help link +. +.IP "\(bu" 4 +npm help rebuild +. +.IP "\(bu" 4 +npm help scripts +. +.IP "\(bu" 4 +npm help build +. +.IP "\(bu" 4 +npm help config +. +.IP "\(bu" 4 +npm help config +. +.IP "\(bu" 4 +npm help npmrc +. +.IP "\(bu" 4 +npm help registry +. +.IP "\(bu" 4 +npm help folders +. +.IP "\(bu" 4 +npm help tag +. +.IP "\(bu" 4 +npm help rm +. +.IP "\(bu" 4 +npm help shrinkwrap +. +.IP "" 0 + diff --git a/deps/npm/man/man1/npm-link.1 b/deps/npm/man/man1/npm-link.1 new file mode 100644 index 000000000..d972d8548 --- /dev/null +++ b/deps/npm/man/man1/npm-link.1 @@ -0,0 +1,118 @@ +.\" Generated with Ronnjs 0.3.8 +.\" http://github.com/kapouer/ronnjs/ +. +.TH "NPM\-LINK" "1" "July 2013" "" "" +. +.SH "NAME" +\fBnpm-link\fR \-\- Symlink a package folder +. +.SH "SYNOPSIS" +. +.nf +npm link (in package folder) +npm link +. +.fi +. +.SH "DESCRIPTION" +Package linking is a two\-step process\. +. +.P +First, \fBnpm link\fR in a package folder will create a globally\-installed +symbolic link from \fBprefix/package\-name\fR to the current folder\. +. +.P +Next, in some other location, \fBnpm link package\-name\fR will create a +symlink from the local \fBnode_modules\fR folder to the global symlink\. +. +.P +Note that \fBpackage\-name\fR is taken from \fBpackage\.json\fR , +not from directory name\. +. +.P +When creating tarballs for \fBnpm publish\fR, the linked packages are +"snapshotted" to their current state by resolving the symbolic links\. +. +.P +This is +handy for installing your own stuff, so that you can work on it and test it +iteratively without having to continually rebuild\. +. +.P +For example: +. +.IP "" 4 +. +.nf +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 +. +.fi +. +.IP "" 0 +. +.P +Now, any changes to ~/projects/node\-redis will be reflected in +~/projects/node\-bloggy/node_modules/redis/ +. +.P +You may also shortcut the two steps in one\. For example, to do the +above use\-case in a shorter way: +. +.IP "" 4 +. +.nf +cd ~/projects/node\-bloggy # go into the dir of your main project +npm link \.\./node\-redis # link the dir of your dependency +. +.fi +. +.IP "" 0 +. +.P +The second line is the equivalent of doing: +. +.IP "" 4 +. +.nf +(cd \.\./node\-redis; npm link) +npm link redis +. +.fi +. +.IP "" 0 +. +.P +That is, it first creates a global link, and then links the global +installation target into your project\'s \fBnode_modules\fR folder\. +. +.SH "SEE ALSO" +. +.IP "\(bu" 4 +npm help developers +. +.IP "\(bu" 4 +npm help faq +. +.IP "\(bu" 4 +npm help package\.json +. +.IP "\(bu" 4 +npm help install +. +.IP "\(bu" 4 +npm help folders +. +.IP "\(bu" 4 +npm help config +. +.IP "\(bu" 4 +npm help config +. +.IP "\(bu" 4 +npm help npmrc +. +.IP "" 0 + diff --git a/deps/npm/man/man1/npm-ls.1 b/deps/npm/man/man1/npm-ls.1 new file mode 100644 index 000000000..39f525db5 --- /dev/null +++ b/deps/npm/man/man1/npm-ls.1 @@ -0,0 +1,136 @@ +.\" Generated with Ronnjs 0.3.8 +.\" http://github.com/kapouer/ronnjs/ +. +.TH "NPM\-LS" "1" "July 2013" "" "" +. +.SH "NAME" +\fBnpm-ls\fR \-\- List installed packages +. +.SH "SYNOPSIS" +. +.nf +npm list [ \.\.\.] +npm ls [ \.\.\.] +npm la [ \.\.\.] +npm ll [ \.\.\.] +. +.fi +. +.SH "DESCRIPTION" +This command will print to stdout all the versions of packages that are +installed, as well as their dependencies, in a tree\-structure\. +. +.P +Positional arguments are \fBname@version\-range\fR identifiers, which will +limit the results to only the paths to the packages named\. Note that +nested packages will \fIalso\fR show the paths to the specified packages\. +For example, running \fBnpm ls promzard\fR in npm\'s source tree will show: +. +.IP "" 4 +. +.nf +npm@1.3.3 /path/to/npm +└─┬ init\-package\-json@0\.0\.4 + └── promzard@0\.1\.5 +. +.fi +. +.IP "" 0 +. +.P +It will print out extraneous, missing, and invalid packages\. +. +.P +If a project specifies git urls for dependencies these are shown +in parentheses after the name@version to make it easier for users to +recognize potential forks of a project\. +. +.P +When run as \fBll\fR or \fBla\fR, it shows extended information by default\. +. +.SH "CONFIGURATION" +. +.SS "json" +. +.IP "\(bu" 4 +Default: false +. +.IP "\(bu" 4 +Type: Boolean +. +.IP "" 0 +. +.P +Show information in JSON format\. +. +.SS "long" +. +.IP "\(bu" 4 +Default: false +. +.IP "\(bu" 4 +Type: Boolean +. +.IP "" 0 +. +.P +Show extended information\. +. +.SS "parseable" +. +.IP "\(bu" 4 +Default: false +. +.IP "\(bu" 4 +Type: Boolean +. +.IP "" 0 +. +.P +Show parseable output instead of tree view\. +. +.SS "global" +. +.IP "\(bu" 4 +Default: false +. +.IP "\(bu" 4 +Type: Boolean +. +.IP "" 0 +. +.P +List packages in the global install prefix instead of in the current +project\. +. +.SH "SEE ALSO" +. +.IP "\(bu" 4 +npm help config +. +.IP "\(bu" 4 +npm help config +. +.IP "\(bu" 4 +npm help npmrc +. +.IP "\(bu" 4 +npm help folders +. +.IP "\(bu" 4 +npm help install +. +.IP "\(bu" 4 +npm help link +. +.IP "\(bu" 4 +npm help prune +. +.IP "\(bu" 4 +npm help outdated +. +.IP "\(bu" 4 +npm help update +. +.IP "" 0 + diff --git a/deps/npm/man/man1/npm-outdated.1 b/deps/npm/man/man1/npm-outdated.1 new file mode 100644 index 000000000..4ef2e8497 --- /dev/null +++ b/deps/npm/man/man1/npm-outdated.1 @@ -0,0 +1,32 @@ +.\" Generated with Ronnjs 0.3.8 +.\" http://github.com/kapouer/ronnjs/ +. +.TH "NPM\-OUTDATED" "1" "July 2013" "" "" +. +.SH "NAME" +\fBnpm-outdated\fR \-\- Check for outdated packages +. +.SH "SYNOPSIS" +. +.nf +npm outdated [ [ \.\.\.]] +. +.fi +. +.SH "DESCRIPTION" +This command will check the registry to see if any (or, specific) installed +packages are currently outdated\. +. +.SH "SEE ALSO" +. +.IP "\(bu" 4 +npm help update +. +.IP "\(bu" 4 +npm help registry +. +.IP "\(bu" 4 +npm help folders +. +.IP "" 0 + diff --git a/deps/npm/man/man1/npm-owner.1 b/deps/npm/man/man1/npm-owner.1 new file mode 100644 index 000000000..b0ba9e809 --- /dev/null +++ b/deps/npm/man/man1/npm-owner.1 @@ -0,0 +1,58 @@ +.\" Generated with Ronnjs 0.3.8 +.\" http://github.com/kapouer/ronnjs/ +. +.TH "NPM\-OWNER" "1" "July 2013" "" "" +. +.SH "NAME" +\fBnpm-owner\fR \-\- Manage package owners +. +.SH "SYNOPSIS" +. +.nf +npm owner ls +npm owner add +npm owner rm +. +.fi +. +.SH "DESCRIPTION" +Manage ownership of published packages\. +. +.IP "\(bu" 4 +ls: +List all the users who have access to modify a package and push new versions\. +Handy when you need to know who to bug for help\. +. +.IP "\(bu" 4 +add: +Add a new user as a maintainer of a package\. This user is enabled to modify +metadata, publish new versions, and add other owners\. +. +.IP "\(bu" 4 +rm: +Remove a user from the package owner list\. This immediately revokes their +privileges\. +. +.IP "" 0 +. +.P +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\. +. +.SH "SEE ALSO" +. +.IP "\(bu" 4 +npm help publish +. +.IP "\(bu" 4 +npm help registry +. +.IP "\(bu" 4 +npm help adduser +. +.IP "\(bu" 4 +npm help disputes +. +.IP "" 0 + diff --git a/deps/npm/man/man1/npm-pack.1 b/deps/npm/man/man1/npm-pack.1 new file mode 100644 index 000000000..b591b9ebe --- /dev/null +++ b/deps/npm/man/man1/npm-pack.1 @@ -0,0 +1,48 @@ +.\" Generated with Ronnjs 0.3.8 +.\" http://github.com/kapouer/ronnjs/ +. +.TH "NPM\-PACK" "1" "July 2013" "" "" +. +.SH "NAME" +\fBnpm-pack\fR \-\- Create a tarball from a package +. +.SH "SYNOPSIS" +. +.nf +npm pack [ [ \.\.\.]] +. +.fi +. +.SH "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 \fB\-\.tgz\fR, and then write the filenames out to +stdout\. +. +.P +If the same package is specified multiple times, then the file will be +overwritten the second time\. +. +.P +If no arguments are supplied, then npm packs the current package folder\. +. +.SH "SEE ALSO" +. +.IP "\(bu" 4 +npm help cache +. +.IP "\(bu" 4 +npm help publish +. +.IP "\(bu" 4 +npm help config +. +.IP "\(bu" 4 +npm help config +. +.IP "\(bu" 4 +npm help npmrc +. +.IP "" 0 + diff --git a/deps/npm/man/man1/npm-prefix.1 b/deps/npm/man/man1/npm-prefix.1 new file mode 100644 index 000000000..60897bc0b --- /dev/null +++ b/deps/npm/man/man1/npm-prefix.1 @@ -0,0 +1,40 @@ +.\" Generated with Ronnjs 0.3.8 +.\" http://github.com/kapouer/ronnjs/ +. +.TH "NPM\-PREFIX" "1" "July 2013" "" "" +. +.SH "NAME" +\fBnpm-prefix\fR \-\- Display prefix +. +.SH "SYNOPSIS" +. +.nf +npm prefix +. +.fi +. +.SH "DESCRIPTION" +Print the prefix to standard out\. +. +.SH "SEE ALSO" +. +.IP "\(bu" 4 +npm help root +. +.IP "\(bu" 4 +npm help bin +. +.IP "\(bu" 4 +npm help folders +. +.IP "\(bu" 4 +npm help config +. +.IP "\(bu" 4 +npm help config +. +.IP "\(bu" 4 +npm help npmrc +. +.IP "" 0 + diff --git a/deps/npm/man/man1/npm-prune.1 b/deps/npm/man/man1/npm-prune.1 new file mode 100644 index 000000000..283d6885c --- /dev/null +++ b/deps/npm/man/man1/npm-prune.1 @@ -0,0 +1,37 @@ +.\" Generated with Ronnjs 0.3.8 +.\" http://github.com/kapouer/ronnjs/ +. +.TH "NPM\-PRUNE" "1" "July 2013" "" "" +. +.SH "NAME" +\fBnpm-prune\fR \-\- Remove extraneous packages +. +.SH "SYNOPSIS" +. +.nf +npm prune [ [ +npm publish +. +.fi +. +.SH "DESCRIPTION" +Publishes a package to the registry so that it can be installed by name\. +. +.IP "\(bu" 4 +\fB\fR: +A folder containing a package\.json file +. +.IP "\(bu" 4 +\fB\fR: +A url or file path to a gzipped tar archive containing a single folder +with a package\.json file inside\. +. +.IP "" 0 +. +.P +Fails if the package name and version combination already exists in +the registry\. Overwrites when the "\-\-force" flag is set\. +. +.SH "SEE ALSO" +. +.IP "\(bu" 4 +npm help registry +. +.IP "\(bu" 4 +npm help adduser +. +.IP "\(bu" 4 +npm help owner +. +.IP "\(bu" 4 +npm help deprecate +. +.IP "\(bu" 4 +npm help tag +. +.IP "" 0 + diff --git a/deps/npm/man/man1/npm-rebuild.1 b/deps/npm/man/man1/npm-rebuild.1 new file mode 100644 index 000000000..c0dc36a35 --- /dev/null +++ b/deps/npm/man/man1/npm-rebuild.1 @@ -0,0 +1,36 @@ +.\" Generated with Ronnjs 0.3.8 +.\" http://github.com/kapouer/ronnjs/ +. +.TH "NPM\-REBUILD" "1" "July 2013" "" "" +. +.SH "NAME" +\fBnpm-rebuild\fR \-\- Rebuild a package +. +.SH "SYNOPSIS" +. +.nf +npm rebuild [ [ \.\.\.]] +. +.fi +. +.IP "\(bu" 4 +\fB\fR: +The package to rebuild +. +.IP "" 0 +. +.SH "DESCRIPTION" +This command runs the \fBnpm build\fR command on the matched folders\. This is useful +when you install a new version of node, and must recompile all your C++ addons with +the new binary\. +. +.SH "SEE ALSO" +. +.IP "\(bu" 4 +npm help build +. +.IP "\(bu" 4 +npm help install +. +.IP "" 0 + diff --git a/deps/npm/man/man1/npm-restart.1 b/deps/npm/man/man1/npm-restart.1 new file mode 100644 index 000000000..061c15774 --- /dev/null +++ b/deps/npm/man/man1/npm-restart.1 @@ -0,0 +1,42 @@ +.\" Generated with Ronnjs 0.3.8 +.\" http://github.com/kapouer/ronnjs/ +. +.TH "NPM\-RESTART" "1" "July 2013" "" "" +. +.SH "NAME" +\fBnpm-restart\fR \-\- Start a package +. +.SH "SYNOPSIS" +. +.nf +npm restart +. +.fi +. +.SH "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\. +. +.P +If no version is specified, then it restarts the "active" version\. +. +.SH "SEE ALSO" +. +.IP "\(bu" 4 +npm help run\-script +. +.IP "\(bu" 4 +npm help scripts +. +.IP "\(bu" 4 +npm help test +. +.IP "\(bu" 4 +npm help start +. +.IP "\(bu" 4 +npm help stop +. +.IP "" 0 + diff --git a/deps/npm/man/man1/npm-rm.1 b/deps/npm/man/man1/npm-rm.1 new file mode 100644 index 000000000..b19c51b1f --- /dev/null +++ b/deps/npm/man/man1/npm-rm.1 @@ -0,0 +1,42 @@ +.\" Generated with Ronnjs 0.3.8 +.\" http://github.com/kapouer/ronnjs/ +. +.TH "NPM\-RM" "1" "July 2013" "" "" +. +.SH "NAME" +\fBnpm-rm\fR \-\- Remove a package +. +.SH "SYNOPSIS" +. +.nf +npm rm +npm uninstall +. +.fi +. +.SH "DESCRIPTION" +This uninstalls a package, completely removing everything npm installed +on its behalf\. +. +.SH "SEE ALSO" +. +.IP "\(bu" 4 +npm help prune +. +.IP "\(bu" 4 +npm help install +. +.IP "\(bu" 4 +npm help folders +. +.IP "\(bu" 4 +npm help config +. +.IP "\(bu" 4 +npm help config +. +.IP "\(bu" 4 +npm help npmrc +. +.IP "" 0 + diff --git a/deps/npm/man/man1/npm-root.1 b/deps/npm/man/man1/npm-root.1 new file mode 100644 index 000000000..2fbbbd6c6 --- /dev/null +++ b/deps/npm/man/man1/npm-root.1 @@ -0,0 +1,40 @@ +.\" Generated with Ronnjs 0.3.8 +.\" http://github.com/kapouer/ronnjs/ +. +.TH "NPM\-ROOT" "1" "July 2013" "" "" +. +.SH "NAME" +\fBnpm-root\fR \-\- Display npm root +. +.SH "SYNOPSIS" +. +.nf +npm root +. +.fi +. +.SH "DESCRIPTION" +Print the effective \fBnode_modules\fR folder to standard out\. +. +.SH "SEE ALSO" +. +.IP "\(bu" 4 +npm help prefix +. +.IP "\(bu" 4 +npm help bin +. +.IP "\(bu" 4 +npm help folders +. +.IP "\(bu" 4 +npm help config +. +.IP "\(bu" 4 +npm help config +. +.IP "\(bu" 4 +npm help npmrc +. +.IP "" 0 + diff --git a/deps/npm/man/man1/npm-run-script.1 b/deps/npm/man/man1/npm-run-script.1 new file mode 100644 index 000000000..00de0d967 --- /dev/null +++ b/deps/npm/man/man1/npm-run-script.1 @@ -0,0 +1,41 @@ +.\" Generated with Ronnjs 0.3.8 +.\" http://github.com/kapouer/ronnjs/ +. +.TH "NPM\-RUN\-SCRIPT" "1" "July 2013" "" "" +. +.SH "NAME" +\fBnpm-run-script\fR \-\- Run arbitrary package scripts +. +.SH "SYNOPSIS" +. +.nf +npm run\-script