s2/minifyfromhtml
1
0
Fork 0
mirror of https://github.com/S2-/minifyfromhtml.git synced 2025-08-03 12:20:04 +02:00
Code Issues Releases Wiki Activity

update packages to latest version

Browse Source
This commit is contained in:
s2
2022-08-20 18:51:33 +02:00
parent 09663a35a5
commit 806ebf9a57
4513 changed files with 366205 additions and 92512 deletions
Download Patch File Download Diff File Expand all files Collapse all files

74
node_modules/npm/doc/cli/npm-access.md generated vendored Normal file
View File

@@ -0,0 +1,74 @@
npm-access(1) -- Set access level on published packages
=======================================================
## SYNOPSIS
npm access public [<package>]
npm access restricted [<package>]
npm access grant <read-only|read-write> <scope:team> [<package>]
npm access revoke <scope:team> [<package>]
npm access ls-packages [<user>|<scope>|<scope:team>]
npm access ls-collaborators [<package> [<user>]]
npm access edit [<package>]
## DESCRIPTION
Used to set access controls on private packages.
For all of the subcommands, `npm access` will perform actions on the packages
in the current working directory if no package name is passed to the
subcommand.
* public / restricted:
Set a package to be either publicly accessible or restricted.
* grant / revoke:
Add or remove the ability of users and teams to have read-only or read-write
access to a package.
* ls-packages:
Show all of the packages a user or a team is able to access, along with the
access level, except for read-only public packages (it won't print the whole
registry listing)
* ls-collaborators:
Show all of the access privileges for a package. Will only show permissions
for packages to which you have at least read access. If `<user>` is passed in,
the list is filtered only to teams _that_ user happens to belong to.
* edit:
Set the access privileges for a package at once using `$EDITOR`.
## DETAILS
`npm access` always operates directly on the current registry, configurable
from the command line using `--registry=<registry url>`.
Unscoped packages are *always public*.
Scoped packages *default to restricted*, but you can either publish them as
public using `npm publish --access=public`, or set their access as public using
`npm access public` after the initial publish.
You must have privileges to set the access of a package:
* You are an owner of an unscoped or scoped package.
* You are a member of the team that owns a scope.
* You have been given read-write privileges for a package, either as a member
of a team or directly as an owner.
If your account is not paid, then attempts to publish scoped packages will fail
with an HTTP 402 status code (logically enough), unless you use
`--access=public`.
Management of teams and team memberships is done with the `npm team` command.
## SEE ALSO
* npm-team(1)
* npm-publish(1)
* npm-config(7)
* npm-registry(7)

75
node_modules/npm/doc/cli/npm-adduser.md generated vendored Normal file
View File

@@ -0,0 +1,75 @@
npm-adduser(1) -- Add a registry user account
=============================================
## SYNOPSIS
npm adduser [--registry=url] [--scope=@orgname] [--always-auth]
aliases: login, add-user
## DESCRIPTION
Create or verify a user named `<username>` in the specified registry, and
save the credentials to the `.npmrc` file. If no registry is specified,
the default registry will be used (see `npm-config(7)`).
The username, password, and email are read in from prompts.
To reset your password, go to <https://www.npmjs.com/forgot>
To change your email address, go to <https://www.npmjs.com/email-edit>
You may use this command multiple times with the same user account to
authorize on a new machine. When authenticating on a new machine,
the username, password and email address must all match with
your existing record.
`npm login` is an alias to `adduser` and behaves exactly the same way.
## CONFIGURATION
### registry
Default: https://registry.npmjs.org/
The base URL of the npm package registry. If `scope` is also specified,
this registry will only be used for packages with that scope. See `npm-scope(7)`.
### scope
Default: none
If specified, the user and login credentials given will be associated
with the specified scope. See `npm-scope(7)`. You can use both at the same time,
e.g.
npm adduser --registry=http://myregistry.example.com --scope=@myco
This will set a registry for the given scope and login or create a user for
that registry at the same time.
### always-auth
Default: false
If specified, save configuration indicating that all requests to the given
registry should include authorization information. Useful for private
registries. Can be used with `--registry` and / or `--scope`, e.g.
npm adduser --registry=http://private-registry.example.com --always-auth
This will ensure that all requests to that registry (including for tarballs)
include an authorization header. This setting may be necessary for use with
private registries where metadata and package tarballs are stored on hosts with
different hostnames. See `always-auth` in `npm-config(7)` for more details on
always-auth. Registry-specific configuration of `always-auth` takes precedence
over any global configuration.
## SEE ALSO
* npm-registry(7)
* npm-config(1)
* npm-config(7)
* npmrc(5)
* npm-owner(1)
* npm-whoami(1)

19
node_modules/npm/doc/cli/npm-bin.md generated vendored Normal file
View File

@@ -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(5)
* npm-config(1)
* npm-config(7)
* npmrc(5)

44
node_modules/npm/doc/cli/npm-bugs.md generated vendored Normal file
View File

@@ -0,0 +1,44 @@
npm-bugs(1) -- Bugs for a package in a web browser maybe
========================================================
## SYNOPSIS
npm bugs <pkgname>
npm bugs (with no args in a package dir)
aliases: issues
## 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. If no package name is provided, it will search for
a `package.json` in the current folder and use the `name` property.
## 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)

25
node_modules/npm/doc/cli/npm-build.md generated vendored Normal file
View File

@@ -0,0 +1,25 @@
npm-build(1) -- Build a package
===============================
## SYNOPSIS
npm build <package-folder>
* `<package-folder>`:
A folder containing a `package.json` file in its root.
## DESCRIPTION
This is the plumbing command called by `npm link` and `npm install`.
It should generally be called during installation, but if you need to run it
directly, run:
npm run-script build
## SEE ALSO
* npm-install(1)
* npm-link(1)
* npm-scripts(7)
* package.json(5)

14
node_modules/npm/doc/cli/npm-bundle.md generated vendored Normal file
View File

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

70
node_modules/npm/doc/cli/npm-cache.md generated vendored Normal file
View File

@@ -0,0 +1,70 @@
npm-cache(1) -- Manipulates packages cache
==========================================
## SYNOPSIS
npm cache add <tarball file>
npm cache add <folder>
npm cache add <tarball url>
npm cache add <name>@<version>
npm cache ls [<path>]
npm cache clean [<path>]
## DESCRIPTION
Used to add, list, or clear the npm cache folder.
* add:
Add the specified package to the local cache. This command is primarily
intended to be used internally by npm, but it can provide a way to
add data to the local installation cache explicitly.
* ls:
Show the data in the cache. Argument is a path to show in the cache
folder. Works a bit like the `find` program, but limited by the
`depth` config.
* clean:
Delete data out of the cache folder. If an argument is provided, then
it specifies a subpath to delete. If no argument is provided, then
the entire cache is cleared.
## DETAILS
npm stores cache data in the directory specified in `npm config get cache`.
For each package that is added to the cache, three pieces of information are
stored in `{cache}/{name}/{version}`:
* .../package/package.json:
The package.json file, as npm sees it.
* .../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. This is stored in `{cache}/{hostname}/{path}/.cache.json`.
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: `~/.npm` on Posix, or `%AppData%/npm-cache` on Windows.
The root cache folder.
## SEE ALSO
* npm-folders(5)
* npm-config(1)
* npm-config(7)
* npmrc(5)
* npm-install(1)
* npm-publish(1)
* npm-pack(1)

29
node_modules/npm/doc/cli/npm-completion.md generated vendored Normal file
View File

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

73
node_modules/npm/doc/cli/npm-config.md generated vendored Normal file
View File

@@ -0,0 +1,73 @@
npm-config(1) -- 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 c [set|get|delete|list]
npm get <key>
npm set <key> <value> [--global]
aliases: c
## 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)

60
node_modules/npm/doc/cli/npm-dedupe.md generated vendored Normal file
View File

@@ -0,0 +1,60 @@
npm-dedupe(1) -- Reduce duplication
===================================
## SYNOPSIS
npm dedupe [package names...]
npm ddp [package names...]
aliases: find-dupes, ddp
## 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.
The `--tag` argument will apply to all of the affected dependencies. If a
tag with the given name exists, the tagged version is preferred over newer
versions.
## SEE ALSO
* npm-ls(1)
* npm-update(1)
* npm-install(1)

26
node_modules/npm/doc/cli/npm-deprecate.md generated vendored Normal file
View File

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

87
node_modules/npm/doc/cli/npm-dist-tag.md generated vendored Normal file
View File

@@ -0,0 +1,87 @@
npm-dist-tag(1) -- Modify package distribution tags
===================================================
## SYNOPSIS
npm dist-tag add <pkg>@<version> [<tag>]
npm dist-tag rm <pkg> <tag>
npm dist-tag ls [<pkg>]
aliases: dist-tags
## DESCRIPTION
Add, remove, and enumerate distribution tags on a package:
* add:
Tags the specified version of the package with the specified tag, or the
`--tag` config if not specified.
* rm:
Clear a tag that is no longer in use from the package.
* ls:
Show all of the dist-tags for a package, defaulting to the package in
the current prefix.
A tag can be used when installing packages as a reference to a version instead
of using a specific version number:
npm install <name>@<tag>
When installing dependencies, a preferred tagged version may be specified:
npm install --tag <tag>
This also applies to `npm dedupe`.
Publishing a package sets the `latest` tag to the published version unless the
`--tag` option is used. For example, `npm publish --tag=beta`.
By default, `npm install <pkg>` (without any `@<version>` or `@<tag>`
specifier) installs the `latest` tag.
## PURPOSE
Tags can be used to provide an alias instead of version numbers.
For example, a project might choose to have multiple streams of development
and use a different tag for each stream,
e.g., `stable`, `beta`, `dev`, `canary`.
By default, the `latest` tag is used by npm to identify the current version of
a package, and `npm install <pkg>` (without any `@<version>` or `@<tag>`
specifier) installs the `latest` tag. Typically, projects only use the `latest`
tag for stable release versions, and use other tags for unstable versions such
as prereleases.
The `next` tag is used by some projects to identify the upcoming version.
By default, other than `latest`, no tag has any special significance to npm
itself.
## CAVEATS
This command used to be known as `npm tag`, which only created new tags, and so
had a different syntax.
Tags must share a namespace with version numbers, because they are specified in
the same slot: `npm install <pkg>@<version>` vs `npm install <pkg>@<tag>`.
Tags that can be interpreted as valid semver ranges will be rejected. For
example, `v1.4` cannot be used as a tag, because it is interpreted by semver as
`>=1.4.0 <1.5.0`. See <https://github.com/npm/npm/issues/6082>.
The simplest way to avoid semver problems with tags is to use tags that do not
begin with a number or the letter `v`.
## SEE ALSO
* npm-tag(1)
* npm-publish(1)
* npm-install(1)
* npm-dedupe(1)
* npm-registry(7)
* npm-config(1)
* npm-config(7)
* npmrc(5)

44
node_modules/npm/doc/cli/npm-docs.md generated vendored Normal file
View File

@@ -0,0 +1,44 @@
npm-docs(1) -- Docs for a package in a web browser maybe
========================================================
## SYNOPSIS
npm docs [<pkgname> [<pkgname> ...]]
npm docs (with no args in a package dir)
npm home [<pkgname> [<pkgname> ...]]
npm home (with no args in a package dir)
## 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. You can pass multiple package names at once. If no
package name is provided, it will search for a `package.json` in
the current folder and use the `name` property.
## 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)

37
node_modules/npm/doc/cli/npm-edit.md generated vendored Normal file
View File

@@ -0,0 +1,37 @@
npm-edit(1) -- Edit an installed package
========================================
## SYNOPSIS
npm edit <name>[@<version>]
## DESCRIPTION
Opens the package folder in the default editor (or whatever you've
configured as the npm `editor` config -- see `npm-config(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(5)
* npm-explore(1)
* npm-install(1)
* npm-config(1)
* npm-config(7)
* npmrc(5)

39
node_modules/npm/doc/cli/npm-explore.md generated vendored Normal file
View File

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

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

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

40
node_modules/npm/doc/cli/npm-help.md generated vendored Normal file
View File

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

38
node_modules/npm/doc/cli/npm-init.md generated vendored Normal file
View File

@@ -0,0 +1,38 @@
npm-init(1) -- Interactively create a package.json file
=======================================================
## SYNOPSIS
npm init [-f|--force|-y|--yes]
## 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.
If you invoke it with `-f`, `--force`, `-y`, or `--yes`, it will use only
defaults and not prompt you for any options.
## CONFIGURATION
### scope
* Default: none
* Type: String
The scope under which the new module should be created.
## SEE ALSO
* <https://github.com/isaacs/init-package-json>
* package.json(5)
* npm-version(1)
* npm-scope(7)

339
node_modules/npm/doc/cli/npm-install.md generated vendored Normal file
View File

@@ -0,0 +1,339 @@
npm-install(1) -- Install a package
===================================
## SYNOPSIS
npm install (with no args in a package dir)
npm install <tarball file>
npm install <tarball url>
npm install <folder>
npm install [@<scope>/]<name> [--save|--save-dev|--save-optional] [--save-exact] [--save-bundle]
npm install [@<scope>/]<name>@<tag>
npm install [@<scope>/]<name>@<version>
npm install [@<scope>/]<name>@<version range>
npm i (with any of the previous argument usage)
## 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(5)` file
* b) a gzipped tarball containing (a)
* c) a url that resolves to (b)
* d) a `<name>@<version>` that is published on the registry (see `npm-registry(7)`) with (c)
* e) a `<name>@<tag>` (see `npm-dist-tag(1)`) 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.
By default, `npm install` will install all modules listed as dependencies
in `package.json(5)`.
With the `--production` flag (or when the `NODE_ENV` environment variable
is set to `production`), npm will not install modules listed in
`devDependencies`.
* `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 [@<scope>/]<name> [--save|--save-dev|--save-optional]`:
Do a `<name>@<tag>` install, where `<tag>` is the "tag" config. (See
`npm-config(7)`. The config's default value is `latest`.)
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`.
When using any of the above options to save dependencies to your
package.json, there are two additional, optional flags:
* `--save-exact`: Saved dependencies will be configured with an
exact version rather than using npm's default semver range
operator.
* `-B, --save-bundle`: Saved dependencies will also be added to your `bundleDependencies` list.
Note: if you do not include the @-symbol on your scope name, npm will
interpret this as a GitHub repository instead, see below. Scopes names
must also be followed by a slash.
Examples:
npm install sax --save
npm install githubname/reponame
npm install @myorg/privatepackage
npm install node-tap --save-dev
npm install dtrace-provider --save-optional
npm install readable-stream --save --save-exact
npm install ansi-regex --save --save-bundle
**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 [@<scope>/]<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 @myorg/mypackage@latest
* `npm install [@<scope>/]<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 @myorg/privatepackage@1.5.0
* `npm install [@<scope>/]<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 @myorg/privatepackage@">=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>[:<password>]@]<hostname>[:<port>][:/]<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.
The following git environment variables are recognized by npm and will be added
to the environment when running git:
* `GIT_ASKPASS`
* `GIT_EXEC_PATH`
* `GIT_PROXY_COMMAND`
* `GIT_SSH`
* `GIT_SSH_COMMAND`
* `GIT_SSL_CAINFO`
* `GIT_SSL_NO_VERIFY`
See the git man page for details.
Examples:
npm install git+ssh://git@github.com:npm/npm.git#v1.0.27
npm install git+https://isaacs@github.com/npm/npm.git
npm install git://github.com/npm/npm.git#v1.0.27
GIT_SSH_COMMAND='ssh -i ~/.ssh/custom_ident' npm install git+ssh://git@github.com:npm/npm.git
* `npm install <githubname>/<githubrepo>[#<commit-ish>]`:
* `npm install github:<githubname>/<githubrepo>[#<commit-ish>]`:
Install the package at `https://github.com/githubname/githubrepo` by
attempting to clone it using `git`.
If you don't specify a *commit-ish* then `master` will be used.
Examples:
npm install mygithubuser/myproject
npm install github:mygithubuser/myproject
* `npm install gist:[<githubname>/]<gistID>[#<commit-ish>]`:
Install the package at `https://gist.github.com/gistID` by attempting to
clone it using `git`. The GitHub username associated with the gist is
optional and will not be saved in `package.json` if `--save` is used.
If you don't specify a *commit-ish* then `master` will be used.
Example:
npm install gist:101a11beef
* `npm install bitbucket:<bitbucketname>/<bitbucketrepo>[#<commit-ish>]`:
Install the package at `https://bitbucket.org/bitbucketname/bitbucketrepo`
by attempting to clone it using `git`.
If you don't specify a *commit-ish* then `master` will be used.
Example:
npm install bitbucket:mybitbucketuser/myproject
* `npm install gitlab:<gitlabname>/<gitlabrepo>[#<commit-ish>]`:
Install the package at `https://gitlab.com/gitlabname/gitlabrepo`
by attempting to clone it using `git`.
If you don't specify a *commit-ish* then `master` will be used.
Example:
npm install gitlab:mygitlabuser/myproject
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. If a
tag with the given name exists, the tagged version is preferred over newer
versions.
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(5)`.
The `--ignore-scripts` argument will cause npm to not execute any
scripts defined in the package.json. See `npm-scripts(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-optional` argument will prevent optional dependencies from
being installed.
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(5) 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(5)
* 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-tag(1)
* npm-uninstall(1)
* npm-shrinkwrap(1)
* package.json(5)

74
node_modules/npm/doc/cli/npm-link.md generated vendored Normal file
View File

@@ -0,0 +1,74 @@
npm-link(1) -- Symlink a package folder
=======================================
## SYNOPSIS
npm link (in package folder)
npm link [@<scope>/]<pkgname>
npm ln (with any of the previous argument usage)
## DESCRIPTION
Package linking is a two-step process.
First, `npm link` in a package folder will create a symlink in the global folder
`{prefix}/lib/node_modules/<package>` that links to the package where the `npm
link` command was executed. (see `npm-config(7)` for the value of `prefix`). It
will also link any bins in the package to `{prefix}/bin/{name}`.
Next, in some other location, `npm link package-name` will create a
symbolic link from globally-installed `package-name` to `node_modules/`
of the current folder.
Note that `package-name` is taken from `package.json`,
not from directory name.
The package name can be optionally prefixed with a scope. See `npm-scope(7)`.
The scope must be preceded by an @-symbol and followed by a slash.
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/node-redis/. Note that the link should
be to the package name, not the directory name for that package.
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 node-redis
That is, it first creates a global link, and then links the global
installation target into your project's `node_modules` folder.
If your linked package is scoped (see `npm-scope(7)`) your link command must
include that scope, e.g.
npm link @myorg/privatepackage
## SEE ALSO
* npm-developers(7)
* npm-faq(7)
* package.json(5)
* npm-install(1)
* npm-folders(5)
* npm-config(1)
* npm-config(7)
* npmrc(5)

45
node_modules/npm/doc/cli/npm-logout.md generated vendored Normal file
View File

@@ -0,0 +1,45 @@
npm-logout(1) -- Log out of the registry
========================================
## SYNOPSIS
npm logout [--registry=url] [--scope=@orgname]
## DESCRIPTION
When logged into a registry that supports token-based authentication, tell the
server to end this token's session. This will invalidate the token everywhere
you're using it, not just for the current environment.
When logged into a legacy registry that uses username and password authentication, this will
clear the credentials in your user configuration. In this case, it will _only_ affect
the current environment.
If `--scope` is provided, this will find the credentials for the registry
connected to that scope, if set.
## CONFIGURATION
### registry
Default: https://registry.npmjs.org/
The base URL of the npm package registry. If `scope` is also specified,
it takes precedence.
### scope
Default: none
If specified, you will be logged out of the specified scope. See `npm-scope(7)`.
npm logout --scope=@myco
## SEE ALSO
* npm-adduser(1)
* npm-registry(7)
* npm-config(1)
* npm-config(7)
* npmrc(5)
* npm-whoami(1)

94
node_modules/npm/doc/cli/npm-ls.md generated vendored Normal file
View File

@@ -0,0 +1,94 @@
npm-ls(1) -- List installed packages
======================================
## SYNOPSIS
npm list [[@<scope>/]<pkg> ...]
npm ls [[@<scope>/]<pkg> ...]
npm la [[@<scope>/]<pkg> ...]
npm ll [[@<scope>/]<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@@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.
### depth
* Type: Int
Max display depth of the dependency tree.
### prod / production
* Type: Boolean
* Default: false
Display only the dependency tree for packages in `dependencies`.
### dev
* Type: Boolean
* Default: false
Display only the dependency tree for packages in `devDependencies`.
## SEE ALSO
* npm-config(1)
* npm-config(7)
* npmrc(5)
* npm-folders(5)
* npm-install(1)
* npm-link(1)
* npm-prune(1)
* npm-outdated(1)
* npm-update(1)

112
node_modules/npm/doc/cli/npm-outdated.md generated vendored Normal file
View File

@@ -0,0 +1,112 @@
npm-outdated(1) -- Check for outdated packages
==============================================
## SYNOPSIS
npm outdated [<name> [<name> ...]]
## DESCRIPTION
This command will check the registry to see if any (or, specific) installed
packages are currently outdated.
In the output:
* `wanted` is the maximum version of the package that satisfies the semver
range specified in `package.json`. If there's no available semver range (i.e.
you're running `npm outdated --global`, or the package isn't included in
`package.json`), then `wanted` shows the currently-installed version.
* `latest` is the version of the package tagged as latest in the registry.
Running `npm publish` with no special configuration will publish the package
with a dist-tag of `latest`. This may or may not be the maximum version of
the package, or the most-recently published version of the package, depending
on how the package's developer manages the latest dist-tag(1).
* `location` is where in the dependency tree the package is located. Note that
`npm outdated` defaults to a depth of 0, so unless you override that, you'll
always be seeing only top-level dependencies that are outdated.
* `package type` (when using `--long` / `-l`) tells you whether this package is
a `dependency` or a `devDependency`. Packages not included in `package.json`
are always marked `dependencies`.
### An example
```
$ npm outdated
Package Current Wanted Latest Location
glob 5.0.15 5.0.15 6.0.1 test-outdated-output
nothingness 0.0.3 git git test-outdated-output
npm 3.5.1 3.5.2 3.5.1 test-outdated-output
local-dev 0.0.3 linked linked test-outdated-output
once 1.3.2 1.3.3 1.3.3 test-outdated-output
```
With these `dependencies`:
```json
{
"glob": "^5.0.15",
"nothingness": "github:othiym23/nothingness#master",
"npm": "^3.5.1",
"once": "^1.3.1"
}
```
A few things to note:
* `glob` requires `^5`, which prevents npm from installing `glob@6`, which is
outside the semver range.
* Git dependencies will always be reinstalled, because of how they're specified.
The installed committish might satisfy the dependency specifier (if it's
something immutable, like a commit SHA), or it might not, so `npm outdated` and
`npm update` have to fetch Git repos to check. This is why currently doing a
reinstall of a Git dependency always forces a new clone and install.
* `npm@3.5.2` is marked as "wanted", but "latest" is `npm@3.5.1` because npm
uses dist-tags to manage its `latest` and `next` release channels. `npm update`
will install the _newest_ version, but `npm install npm` (with no semver range)
will install whatever's tagged as `latest`.
* `once` is just plain out of date. Reinstalling `node_modules` from scratch or
running `npm update` will bring it up to spec.
## 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
Check packages in the global install prefix instead of in the current
project.
### depth
* Default: 0
* Type: Int
Max depth for checking dependency tree.
## SEE ALSO
* npm-update(1)
* npm-dist-tag(1)
* npm-registry(7)
* npm-folders(5)

35
node_modules/npm/doc/cli/npm-owner.md generated vendored Normal file
View File

@@ -0,0 +1,35 @@
npm-owner(1) -- Manage package owners
=====================================
## SYNOPSIS
npm owner ls <package name>
npm owner add <user> <package name>
npm owner rm <user> <package name>
aliases: author
## 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)

27
node_modules/npm/doc/cli/npm-pack.md generated vendored Normal file
View File

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

16
node_modules/npm/doc/cli/npm-ping.md generated vendored Normal file
View File

@@ -0,0 +1,16 @@
npm-ping(1) -- Ping npm registry
================================
## SYNOPSIS
npm ping [--registry <registry>]
## DESCRIPTION
Ping the configured or given npm registry and verify authentication.
## SEE ALSO
* npm-config(1)
* npm-config(7)
* npmrc(5)

23
node_modules/npm/doc/cli/npm-prefix.md generated vendored Normal file
View File

@@ -0,0 +1,23 @@
npm-prefix(1) -- Display prefix
===============================
## SYNOPSIS
npm prefix [-g]
## DESCRIPTION
Print the local prefix to standard out. This is the closest parent directory
to contain a package.json file unless `-g` is also specified.
If `-g` is specified, this will be the value of the global prefix. See
`npm-config(7)` for more detail.
## SEE ALSO
* npm-root(1)
* npm-bin(1)
* npm-folders(5)
* npm-config(1)
* npm-config(7)
* npmrc(5)

27
node_modules/npm/doc/cli/npm-prune.md generated vendored Normal file
View File

@@ -0,0 +1,27 @@
npm-prune(1) -- Remove extraneous packages
==========================================
## SYNOPSIS
npm prune [<name> [<name ...]]
npm prune [<name> [<name ...]] [--production]
## 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.
If the `--production` flag is specified or the `NODE_ENV` environment
variable is set to `production`, this command will remove the packages
specified in your `devDependencies`. Setting `--production=false` will
negate `NODE_ENV` being set to `production`.
## SEE ALSO
* npm-uninstall(1)
* npm-folders(5)
* npm-ls(1)

55
node_modules/npm/doc/cli/npm-publish.md generated vendored Normal file
View File

@@ -0,0 +1,55 @@
npm-publish(1) -- Publish a package
===================================
## SYNOPSIS
npm publish <tarball> [--tag <tag>] [--access <public|restricted>]
npm publish <folder> [--tag <tag>] [--access <public|restricted>]
## DESCRIPTION
Publishes a package to the registry so that it can be installed by name. All
files in the package directory are included if no local `.gitignore` or
`.npmignore` file is present. See `npm-developers(7)` for full details on
what's included in the published package, as well as details on how the package
is built.
By default npm will publish to the public registry. This can be overridden by
specifying a different default registry or using a `npm-scope(7)` in the name
(see `package.json(5)`).
* `<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.
* `[--tag <tag>]`
Registers the published package with the given tag, such that `npm install
<name>@<tag>` will install this version. By default, `npm publish` updates
and `npm install` installs the `latest` tag. See `npm-dist-tag(1)` for
details about tags.
* `[--access <public|restricted>]`
Tells the registry whether this package should be published as public or
restricted. Only applies to scoped packages, which default to `restricted`.
If you don't have a paid account, you must publish with `--access public`
to publish scoped packages.
Fails if the package name and version combination already exists in
the specified registry.
Once a package is published with a given name and version, that
specific name and version combination can never be used again, even if
it is removed with npm-unpublish(1).
## SEE ALSO
* npm-registry(7)
* npm-scope(7)
* npm-adduser(1)
* npm-owner(1)
* npm-deprecate(1)
* npm-tag(1)

21
node_modules/npm/doc/cli/npm-rebuild.md generated vendored Normal file
View File

@@ -0,0 +1,21 @@
npm-rebuild(1) -- Rebuild a package
===================================
## SYNOPSIS
npm rebuild [<name> [<name> ...]]
npm rb [<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
* npm-build(1)
* npm-install(1)

28
node_modules/npm/doc/cli/npm-repo.md generated vendored Normal file
View File

@@ -0,0 +1,28 @@
npm-repo(1) -- Open package repository page in the browser
========================================================
## SYNOPSIS
npm repo <pkgname>
npm repo (with no args in a package dir)
## DESCRIPTION
This command tries to guess at the likely location of a package's
repository URL, and then tries to open it using the `--browser`
config param. If no package name is provided, it will search for
a `package.json` in the current folder and use the `name` property.
## CONFIGURATION
### browser
* Default: OS X: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
* Type: String
The browser that is called by the `npm repo` command to open websites.
## SEE ALSO
* npm-docs(1)
* npm-config(1)

40
node_modules/npm/doc/cli/npm-restart.md generated vendored Normal file
View File

@@ -0,0 +1,40 @@
npm-restart(1) -- Restart a package
===================================
## SYNOPSIS
npm restart [-- <args>]
## DESCRIPTION
This restarts a package.
This runs a package's "stop", "restart", and "start" scripts, and associated
pre- and post- scripts, in the order given below:
1. prerestart
2. prestop
3. stop
4. poststop
5. restart
6. prestart
7. start
8. poststart
9. postrestart
## NOTE
Note that the "restart" script is run **in addition to** the "stop"
and "start" scripts, not instead of them.
This is the behavior as of `npm` major version 2. A change in this
behavior will be accompanied by an increase in major version number
## SEE ALSO
* npm-run-script(1)
* npm-scripts(7)
* npm-test(1)
* npm-start(1)
* npm-stop(1)
* npm-restart(3)

23
node_modules/npm/doc/cli/npm-rm.md generated vendored Normal file
View File

@@ -0,0 +1,23 @@
npm-rm(1) -- Remove a package
=============================
## SYNOPSIS
npm rm <name>
npm r <name>
npm uninstall <name>
npm un <name>
## DESCRIPTION
This uninstalls a package, completely removing everything npm installed
on its behalf.
## SEE ALSO
* npm-prune(1)
* npm-install(1)
* npm-folders(5)
* npm-config(1)
* npm-config(7)
* npmrc(5)

19
node_modules/npm/doc/cli/npm-root.md generated vendored Normal file
View File

@@ -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(5)
* npm-config(1)
* npm-config(7)
* npmrc(5)

48
node_modules/npm/doc/cli/npm-run-script.md generated vendored Normal file
View File

@@ -0,0 +1,48 @@
npm-run-script(1) -- Run arbitrary package scripts
==================================================
## SYNOPSIS
npm run-script [command] [-- <args>]
npm run [command] [-- <args>]
## DESCRIPTION
This runs an arbitrary command from a package's `"scripts"` object. If no
`"command"` is provided, it will list the available scripts. `run[-script]` is
used by the test, start, restart, and stop commands, but can be called
directly, as well. When the scripts in the package are printed out, they're
separated into lifecycle (test, start, restart) and directly-run scripts.
As of [`npm@2.0.0`](http://blog.npmjs.org/post/98131109725/npm-2-0-0), you can
use custom arguments when executing scripts. The special option `--` is used by
[getopt](http://goo.gl/KxMmtG) to delimit the end of the options. npm will pass
all the arguments after the `--` directly to your script:
npm run test -- --grep="pattern"
The arguments will only be passed to the script specified after ```npm run```
and not to any pre or post script.
The `env` script is a special built-in command that can be used to list
environment variables that will be available to the script at runtime. If an
"env" command is defined in your package it will take precedence over the
built-in.
In addition to the shell's pre-existing `PATH`, `npm run` adds
`node_modules/.bin` to the `PATH` provided to scripts. Any binaries provided by
locally-installed dependencies can be used without the `node_modules/.bin`
prefix. For example, if there is a `devDependency` on `tap` in your package,
you should write:
"scripts": {"test": "tap test/\*.js"}
instead of `"scripts": {"test": "node_modules/.bin/tap test/\*.js"}` to run your tests.
## SEE ALSO
* npm-scripts(7)
* npm-test(1)
* npm-start(1)
* npm-restart(1)
* npm-stop(1)

45
node_modules/npm/doc/cli/npm-search.md generated vendored Normal file
View File

@@ -0,0 +1,45 @@
npm-search(1) -- Search for packages
====================================
## SYNOPSIS
npm search [-l|--long] [search terms ...]
aliases: s, se, find
## 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.)
## CONFIGURATION
### long
* Default: false
* Type: Boolean
Display full package descriptions and other long text across multiple
lines. When disabled (default) search results are truncated to fit
neatly on a single line. Modules with extremely long names will
fall on multiple lines.
### registry
* Default: https://registry.npmjs.org/
* Type : url
Search the specified registry for modules. If you have configured npm to point to a different default registry,
such as your internal private module repository, `npm search` will default to that registry when searching.
Pass a different registry url such as the default above in order to override this setting.
## SEE ALSO
* npm-registry(7)
* npm-config(1)
* npm-config(7)
* npmrc(5)
* npm-view(1)

180
node_modules/npm/doc/cli/npm-shrinkwrap.md generated vendored Normal file
View File

@@ -0,0 +1,180 @@
npm-shrinkwrap(1) -- 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",
"from": "B@^0.0.1",
"resolved": "https://registry.npmjs.org/B/-/B-0.0.1.tgz",
"dependencies": {
"C": {
"version": "0.0.1",
"from": "org/C#v0.0.1",
"resolved": "git://github.com/org/C.git#5c380ae319fc4efe9e7f2d9c78b0faa588fd99b4"
}
}
}
}
}
The shrinkwrap command has locked down the dependencies based on
what's currently installed in node_modules. When `npm install`
installs a package with an `npm-shrinkwrap.json` 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.0.1, 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
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
* npm-install(1)
* package.json(5)
* npm-ls(1)

22
node_modules/npm/doc/cli/npm-star.md generated vendored Normal file
View File

@@ -0,0 +1,22 @@
npm-star(1) -- 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
* npm-view(1)
* npm-whoami(1)
* npm-adduser(1)

22
node_modules/npm/doc/cli/npm-stars.md generated vendored Normal file
View File

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

24
node_modules/npm/doc/cli/npm-start.md generated vendored Normal file
View File

@@ -0,0 +1,24 @@
npm-start(1) -- Start a package
===============================
## SYNOPSIS
npm start [-- <args>]
## DESCRIPTION
This runs an arbitrary command specified in the package's `"start"` property of
its `"scripts"` object. If no `"start"` property is specified on the
`"scripts"` object, it will run `node server.js`.
As of [`npm@2.0.0`](http://blog.npmjs.org/post/98131109725/npm-2-0-0), you can
use custom arguments when executing scripts. Refer to npm-run-script(1) for
more details.
## SEE ALSO
* npm-run-script(1)
* npm-scripts(7)
* npm-test(1)
* npm-restart(1)
* npm-stop(1)

18
node_modules/npm/doc/cli/npm-stop.md generated vendored Normal file
View File

@@ -0,0 +1,18 @@
npm-stop(1) -- Stop a package
=============================
## SYNOPSIS
npm stop [-- <args>]
## DESCRIPTION
This runs a package's "stop" script, if one was provided.
## SEE ALSO
* npm-run-script(1)
* npm-scripts(7)
* npm-test(1)
* npm-start(1)
* npm-restart(1)

60
node_modules/npm/doc/cli/npm-tag.md generated vendored Normal file
View File

@@ -0,0 +1,60 @@
npm-tag(1) -- Tag a published version
=====================================
## SYNOPSIS
npm tag <name>@<version> [<tag>]
## DESCRIPTION
THIS COMMAND IS DEPRECATED. See npm-dist-tag(1) for details.
Tags the specified version of the package with the specified tag, or the
`--tag` config if not specified.
A tag can be used when installing packages as a reference to a version instead
of using a specific version number:
npm install <name>@<tag>
When installing dependencies, a preferred tagged version may be specified:
npm install --tag <tag>
This also applies to `npm dedupe`.
Publishing a package always sets the "latest" tag to the published version.
## PURPOSE
Tags can be used to provide an alias instead of version numbers. For
example, `npm` currently uses the tag "next" to identify the upcoming
version, and the tag "latest" to identify the current version.
A project might choose to have multiple streams of development, e.g.,
"stable", "canary".
## CAVEATS
Tags must share a namespace with version numbers, because they are
specified in the same slot: `npm install <pkg>@<version>` vs `npm
install <pkg>@<tag>`.
Tags that can be interpreted as valid semver ranges will be
rejected. For example, `v1.4` cannot be used as a tag, because it is
interpreted by semver as `>=1.4.0 <1.5.0`. See
<https://github.com/npm/npm/issues/6082>.
The simplest way to avoid semver problems with tags is to use tags
that do not begin with a number or the letter `v`.
## SEE ALSO
* npm-publish(1)
* npm-install(1)
* npm-dedupe(1)
* npm-registry(7)
* npm-config(1)
* npm-config(7)
* npm-dist-tag(1)
* npmrc(5)

55
node_modules/npm/doc/cli/npm-team.md generated vendored Normal file
View File

@@ -0,0 +1,55 @@
npm-team(1) -- Manage organization teams and team memberships
=============================================================
## SYNOPSIS
npm team create <scope:team>
npm team destroy <scope:team>
npm team add <scope:team> <user>
npm team rm <scope:team> <user>
npm team ls <scope>|<scope:team>
npm team edit <scope:team>
## DESCRIPTION
Used to manage teams in organizations, and change team memberships. Does not
handle permissions for packages.
Teams must always be fully qualified with the organization/scope they belond to
when operating on them, separated by a colon (`:`). That is, if you have a
`developers` team on a `foo` organization, you must always refer to that team as
`foo:developers` in these commands.
* create / destroy:
Create a new team, or destroy an existing one.
* add / rm:
Add a user to an existing team, or remove a user from a team they belong to.
* ls:
If performed on an organization name, will return a list of existing teams
under that organization. If performed on a team, it will instead return a list
of all users belonging to that particular team.
## DETAILS
`npm team` always operates directly on the current registry, configurable from
the command line using `--registry=<registry url>`.
In order to create teams and manage team membership, you must be a *team admin*
under the given organization. Listing teams and team memberships may be done by
any member of the organizations.
Organization creation and management of team admins and *organization* members
is done through the website, not the npm CLI.
To use teams to manage permissions on packages belonging to your organization,
use the `npm access` command to grant or revoke the appropriate permissions.
## SEE ALSO
* npm-access(1)
* npm-registr(7)

23
node_modules/npm/doc/cli/npm-test.md generated vendored Normal file
View File

@@ -0,0 +1,23 @@
npm-test(1) -- Test a package
=============================
## SYNOPSIS
npm test [-- <args>]
aliases: t, tst
## 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
* npm-run-script(1)
* npm-scripts(7)
* npm-start(1)
* npm-restart(1)
* npm-stop(1)

46
node_modules/npm/doc/cli/npm-uninstall.md generated vendored Normal file
View File

@@ -0,0 +1,46 @@
npm-uninstall(1) -- Remove a package
=============================
## SYNOPSIS
npm uninstall [@<scope>/]<package> [--save|--save-dev|--save-optional]
npm rm (with any of the previous argument usage)
## DESCRIPTION
This uninstalls a package, completely removing everything npm installed
on its behalf.
Example:
npm uninstall sax
In global mode (ie, with `-g` or `--global` appended to the command),
it uninstalls the current package context as a global package.
`npm uninstall` takes 3 exclusive, optional flags which save or update
the package version in your main package.json:
* `--save`: Package will be removed from your `dependencies`.
* `--save-dev`: Package will be removed from your `devDependencies`.
* `--save-optional`: Package will be removed from your `optionalDependencies`.
Scope is optional and follows the usual rules for `npm-scope(7)`.
Examples:
npm uninstall sax --save
npm uninstall @myorg/privatepackage --save
npm uninstall node-tap --save-dev
npm uninstall dtrace-provider --save-optional
## SEE ALSO
* npm-prune(1)
* npm-install(1)
* npm-folders(5)
* npm-config(1)
* npm-config(7)
* npmrc(5)

38
node_modules/npm/doc/cli/npm-unpublish.md generated vendored Normal file
View File

@@ -0,0 +1,38 @@
npm-unpublish(1) -- Remove a package from the registry
======================================================
## SYNOPSIS
npm unpublish [@<scope>/]<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.
Even if a package version is unpublished, that specific name and
version combination can never be reused. In order to publish the
package again, a new version number must be used.
The scope is optional and follows the usual rules for `npm-scope(7)`.
## SEE ALSO
* npm-deprecate(1)
* npm-publish(1)
* npm-registry(7)
* npm-adduser(1)
* npm-owner(1)

148
node_modules/npm/doc/cli/npm-update.md generated vendored Normal file
View File

@@ -0,0 +1,148 @@
npm-update(1) -- Update a package
=================================
## SYNOPSIS
npm update [-g] [<name> [<name> ...]]
aliases: up, upgrade
## DESCRIPTION
This command will update all the packages listed to the latest version
(specified by the `tag` config), respecting semver.
It will also install missing packages. As with all commands that install
packages, the `--dev` flag will cause `devDependencies` to be processed
as well.
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.
As of `npm@2.6.1`, the `npm update` will only inspect top-level packages.
Prior versions of `npm` would also recursively inspect all dependencies.
To get the old behavior, use `npm --depth 9999 update`.
## EXAMPLES
IMPORTANT VERSION NOTE: these examples assume `npm@2.6.1` or later. For
older versions of `npm`, you must specify `--depth 0` to get the behavior
described below.
For the examples below, assume that the current package is `app` and it depends
on dependencies, `dep1` (`dep2`, .. etc.). The published versions of `dep1` are:
```
{
"dist-tags": { "latest": "1.2.2" },
"versions": [
"1.2.2",
"1.2.1",
"1.2.0",
"1.1.2",
"1.1.1",
"1.0.0",
"0.4.1",
"0.4.0",
"0.2.0"
]
}
```
### Caret Dependencies
If `app`'s `package.json` contains:
```
"dependencies": {
"dep1": "^1.1.1"
}
```
Then `npm update` will install `dep1@1.2.2`, because `1.2.2` is `latest` and
`1.2.2` satisfies `^1.1.1`.
### Tilde Dependencies
However, if `app`'s `package.json` contains:
```
"dependencies": {
"dep1": "~1.1.1"
}
```
In this case, running `npm update` will install `dep1@1.1.2`. Even though the `latest`
tag points to `1.2.2`, this version does not satisfy `~1.1.1`, which is equivalent
to `>=1.1.1 <1.2.0`. So the highest-sorting version that satisfies `~1.1.1` is used,
which is `1.1.2`.
### Caret Dependencies below 1.0.0
Suppose `app` has a caret dependency on a version below `1.0.0`, for example:
```
"dependencies": {
"dep1": "^0.2.0"
}
```
`npm update` will install `dep1@0.2.0`, because there are no other
versions which satisfy `^0.2.0`.
If the dependence were on `^0.4.0`:
```
"dependencies": {
"dep1": "^0.4.0"
}
```
Then `npm update` will install `dep1@0.4.1`, because that is the highest-sorting
version that satisfies `^0.4.0` (`>= 0.4.0 <0.5.0`)
### Recording Updates with `--save`
When you want to update a package and save the new version as
the minimum required dependency in `package.json`, you can use
`npm update --save`. For example if `package.json` contains
```
"dependencies": {
"dep1": "^1.1.1"
}
```
Then `npm update --save` will install `dep1@1.2.2` (i.e., `latest`),
and `package.json` will be modified:
```
"dependencies": {
"dep1": "^1.2.2"
}
```
Note that `npm` will only write an updated version to `package.json`
if it installs a new package.
### Updating Globally-Installed Packages
`npm update -g` will apply the `update` action to each globally installed
package that is `outdated` -- that is, has a version that is different from
`latest`.
NOTE: If a package has been upgraded to a version newer than `latest`, it will
be _downgraded_.
## SEE ALSO
* npm-install(1)
* npm-outdated(1)
* npm-shrinkwrap(1)
* npm-registry(7)
* npm-folders(5)
* npm-ls(1)

90
node_modules/npm/doc/cli/npm-version.md generated vendored Normal file
View File

@@ -0,0 +1,90 @@
npm-version(1) -- Bump a package version
========================================
## SYNOPSIS
npm version [<newversion> | major | minor | patch | premajor | preminor | prepatch | prerelease]
## DESCRIPTION
Run this in a package directory to bump the version and write the new
data back to `package.json` and, if present, `npm-shrinkwrap.json`.
The `newversion` argument should be a valid semver string, *or* a
valid second argument to semver.inc (one of `patch`, `minor`, `major`,
`prepatch`, `preminor`, `premajor`, `prerelease`). 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.
This behavior is controlled by `git-tag-version` (see below), and can
be disabled on the command line by running `npm --no-git-tag-version version`.
It will fail if the working directory is not clean, unless the `--force`
flag is set.
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:
If `preversion`, `version`, or `postversion` are in the `scripts` property of
the package.json, they will be executed as part of running `npm version`.
The exact order of execution is as follows:
1. Check to make sure the git working directory is clean before we get started.
Your scripts may add files to the commit in future steps.
This step is skipped if the `--force` flag is set.
2. Run the `preversion` script. These scripts have access to the old `version` in package.json.
A typical use would be running your full test suite before deploying.
Any files you want added to the commit should be explicitly added using `git add`.
3. Bump `version` in `package.json` as requested (`patch`, `minor`, `major`, etc).
4. Run the `version` script. These scripts have access to the new `version` in package.json
(so they can incorporate it into file headers in generated files for example).
Again, scripts should explicitly add generated files to the commit using `git add`.
5. Commit and tag.
6. Run the `postversion` script. Use it to clean up the file system or automatically push
the commit and/or tag.
Take the following example:
"scripts": {
"preversion": "npm test",
"version": "npm run build && git add -A dist",
"postversion": "git push && git push --tags && rm -rf build/temp"
}
This runs all your tests, and proceeds only if they pass. Then runs your `build` script, and
adds everything in the `dist` directory to the commit. After the commit, it pushes the new commit
and tag up to the server, and deletes the `build/temp` directory.
## CONFIGURATION
### git-tag-version
* Default: true
* Type: Boolean
Commit and tag the version change.
## SEE ALSO
* npm-init(1)
* npm-run-script(1)
* npm-scripts(7)
* package.json(5)
* semver(7)
* config(7)

95
node_modules/npm/doc/cli/npm-view.md generated vendored Normal file
View File

@@ -0,0 +1,95 @@
npm-view(1) -- View registry info
=================================
## SYNOPSIS
npm view [@<scope>/]<name>[@<version>] [<field>[.<subfield>]...]
npm v [@<scope>/]<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 fields 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
To show the `connect` package version history, you can do
this:
npm view connect versions
## 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
* npm-search(1)
* npm-registry(7)
* npm-config(1)
* npm-config(7)
* npmrc(5)
* npm-docs(1)

17
node_modules/npm/doc/cli/npm-whoami.md generated vendored Normal file
View File

@@ -0,0 +1,17 @@
npm-whoami(1) -- Display npm username
=====================================
## SYNOPSIS
npm whoami
## DESCRIPTION
Print the `username` config to standard output.
## SEE ALSO
* npm-config(1)
* npm-config(7)
* npmrc(5)
* npm-adduser(1)

167
node_modules/npm/doc/cli/npm.md generated vendored Normal file
View File

@@ -0,0 +1,167 @@
npm(1) -- javascript package manager
====================================
## SYNOPSIS
npm <command> [args]
## VERSION
@VERSION@
## DESCRIPTION
npm is the package manager for the Node JavaScript platform. It puts
modules in place so that node can find them, and manages dependency
conflicts intelligently.
It is extremely configurable to support a wide variety of use cases.
Most commonly, it is used to publish, discover, install, and develop node
programs.
Run `npm help` to get a list of available commands.
## INTRODUCTION
You probably got npm because you want to install stuff.
Use `npm install blerg` to install the latest version of "blerg". Check out
`npm-install(1)` for more info. It can do a lot of stuff.
Use the `npm search` command to show everything that's available.
Use `npm ls` to show everything you've installed.
## DEPENDENCIES
If a package references to another package with a git URL, npm depends
on a preinstalled git.
If one of the packages npm tries to install is a native node module and
requires compiling of C++ Code, npm will use
[node-gyp](https://github.com/TooTallNate/node-gyp) for that task.
For a Unix system, [node-gyp](https://github.com/TooTallNate/node-gyp)
needs Python, make and a buildchain like GCC. On Windows,
Python and Microsoft Visual Studio C++ are needed. Python 3 is
not supported by [node-gyp](https://github.com/TooTallNate/node-gyp).
For more information visit
[the node-gyp repository](https://github.com/TooTallNate/node-gyp) and
the [node-gyp Wiki](https://github.com/TooTallNate/node-gyp/wiki).
## DIRECTORIES
See `npm-folders(5)` 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, read
the contributing guidelines and check the issues list.
* https://github.com/npm/npm/wiki/Contributing-Guidelines
* <https://github.com/npm/npm/issues>
## BUGS
When you find issues, please report them:
* web:
<https://github.com/npm/npm/issues>
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.
## AUTHOR
[Isaac Z. Schlueter](http://blog.izs.me/) ::
[isaacs](https://github.com/isaacs/) ::
[@izs](http://twitter.com/izs) ::
<i@izs.me>
## SEE ALSO
* npm-help(1)
* npm-faq(7)
* README
* package.json(5)
* npm-install(1)
* npm-config(1)
* npm-config(7)
* npmrc(5)
* npm-index(7)
* npm(3)