mirror of
https://github.com/S2-/minifyfromhtml.git
synced 2025-08-04 12:40:05 +02:00
update packages to latest version
This commit is contained in:
151
node_modules/npm/html/doc/misc/npm-coding-style.html
generated
vendored
Normal file
151
node_modules/npm/html/doc/misc/npm-coding-style.html
generated
vendored
Normal file
@@ -0,0 +1,151 @@
|
||||
<!doctype html>
|
||||
<html>
|
||||
<title>npm-coding-style</title>
|
||||
<meta charset="utf-8">
|
||||
<link rel="stylesheet" type="text/css" href="../../static/style.css">
|
||||
<link rel="canonical" href="https://www.npmjs.org/doc/misc/npm-coding-style.html">
|
||||
<script async=true src="../../static/toc.js"></script>
|
||||
|
||||
<body>
|
||||
<div id="wrapper">
|
||||
|
||||
<h1><a href="../misc/npm-coding-style.html">npm-coding-style</a></h1> <p>npm's "funny" coding style</p>
|
||||
<h2 id="description">DESCRIPTION</h2>
|
||||
<p>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>
|
||||
<p>If you want to contribute to npm (which is very encouraged), you should
|
||||
make your code conform to npm's style.</p>
|
||||
<p>Note: this concerns npm's code not the specific packages that you can download from the npm registry.</p>
|
||||
<h2 id="line-length">Line Length</h2>
|
||||
<p>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.</p>
|
||||
<h2 id="indentation">Indentation</h2>
|
||||
<p>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>
|
||||
<p>Configure your editor appropriately.</p>
|
||||
<h2 id="curly-braces">Curly braces</h2>
|
||||
<p>Curly braces belong on the same line as the thing that necessitates them.</p>
|
||||
<p>Bad:</p>
|
||||
<pre><code>function ()
|
||||
{
|
||||
</code></pre><p>Good:</p>
|
||||
<pre><code>function () {
|
||||
</code></pre><p>If a block needs to wrap to the next line, use a curly brace. Don't
|
||||
use it if it doesn't.</p>
|
||||
<p>Bad:</p>
|
||||
<pre><code>if (foo) { bar() }
|
||||
while (foo)
|
||||
bar()
|
||||
</code></pre><p>Good:</p>
|
||||
<pre><code>if (foo) bar()
|
||||
while (foo) {
|
||||
bar()
|
||||
}
|
||||
</code></pre><h2 id="semicolons">Semicolons</h2>
|
||||
<p>Don't use them except in four situations:</p>
|
||||
<ul>
|
||||
<li><code>for (;;)</code> loops. They're actually required.</li>
|
||||
<li>null loops like: <code>while (something) ;</code> (But you'd better have a good
|
||||
reason for doing that.)</li>
|
||||
<li><code>case "foo": doSomething(); break</code></li>
|
||||
<li>In front of a leading <code>(</code> or <code>[</code> at the start of the line.
|
||||
This prevents the expression from being interpreted
|
||||
as a function call or property access, respectively.</li>
|
||||
</ul>
|
||||
<p>Some examples of good semicolon usage:</p>
|
||||
<pre><code>;(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()
|
||||
}
|
||||
</code></pre><p>Note that starting lines with <code>-</code> and <code>+</code> also should be prefixed
|
||||
with a semicolon, but this is much less common.</p>
|
||||
<h2 id="comma-first">Comma First</h2>
|
||||
<p>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:</p>
|
||||
<pre><code>var magicWords = [ "abracadabra"
|
||||
, "gesundheit"
|
||||
, "ventrilo"
|
||||
]
|
||||
, spells = { "fireball" : function () { setOnFire() }
|
||||
, "water" : function () { putOut() }
|
||||
}
|
||||
, a = 1
|
||||
, b = "abc"
|
||||
, etc
|
||||
, somethingElse
|
||||
</code></pre><h2 id="whitespace">Whitespace</h2>
|
||||
<p>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>
|
||||
<p>Don't leave trailing whitespace at the end of lines. Don't indent empty
|
||||
lines. Don't use more spaces than are helpful.</p>
|
||||
<h2 id="functions">Functions</h2>
|
||||
<p>Use named functions. They make stack traces a lot easier to read.</p>
|
||||
<h2 id="callbacks-sync-async-style">Callbacks, Sync/async Style</h2>
|
||||
<p>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>
|
||||
<p>The callback should always be the last argument in the list. Its first
|
||||
argument is the Error or null.</p>
|
||||
<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.</p>
|
||||
<h2 id="errors">Errors</h2>
|
||||
<p>Always create a new Error object with your message. Don't just return a
|
||||
string message to the callback. Stack traces are handy.</p>
|
||||
<h2 id="logging">Logging</h2>
|
||||
<p>Logging is done using the <a href="https://github.com/npm/npmlog">npmlog</a>
|
||||
utility.</p>
|
||||
<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>
|
||||
<p>Use appropriate log levels. See <code><a href="../misc/npm-config.html">npm-config(7)</a></code> and search for
|
||||
"loglevel".</p>
|
||||
<h2 id="case-naming-etc-">Case, naming, etc.</h2>
|
||||
<p>Use <code>lowerCamelCase</code> for multiword identifiers when they refer to objects,
|
||||
functions, methods, properties, or anything not specified in this section.</p>
|
||||
<p>Use <code>UpperCamelCase</code> for class names (things that you'd pass to "new").</p>
|
||||
<p>Use <code>all-lower-hyphen-css-case</code> for multiword filenames and config keys.</p>
|
||||
<p>Use named functions. They make stack traces easier to follow.</p>
|
||||
<p>Use <code>CAPS_SNAKE_CASE</code> for constants, things that should never change
|
||||
and are rarely used.</p>
|
||||
<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.</p>
|
||||
<h2 id="null-undefined-false-0">null, undefined, false, 0</h2>
|
||||
<p>Boolean variables and functions should always be either <code>true</code> or
|
||||
<code>false</code>. Don't set it to 0 unless it's supposed to be a number.</p>
|
||||
<p>When something is intentionally missing or removed, set it to <code>null</code>.</p>
|
||||
<p>Don't set things to <code>undefined</code>. Reserve that value to mean "not yet
|
||||
set to anything."</p>
|
||||
<p>Boolean objects are verboten.</p>
|
||||
<h2 id="see-also">SEE ALSO</h2>
|
||||
<ul>
|
||||
<li><a href="../misc/npm-developers.html">npm-developers(7)</a></li>
|
||||
<li><a href="../misc/npm-faq.html">npm-faq(7)</a></li>
|
||||
<li><a href="../cli/npm.html">npm(1)</a></li>
|
||||
</ul>
|
||||
|
||||
</div>
|
||||
|
||||
<table border=0 cellspacing=0 cellpadding=0 id=npmlogo>
|
||||
<tr><td style="width:180px;height:10px;background:rgb(237,127,127)" colspan=18> </td></tr>
|
||||
<tr><td rowspan=4 style="width:10px;height:10px;background:rgb(237,127,127)"> </td><td style="width:40px;height:10px;background:#fff" colspan=4> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=4> </td><td style="width:40px;height:10px;background:#fff" colspan=4> </td><td rowspan=4 style="width:10px;height:10px;background:rgb(237,127,127)"> </td><td colspan=6 style="width:60px;height:10px;background:#fff"> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=4> </td></tr>
|
||||
<tr><td colspan=2 style="width:20px;height:30px;background:#fff" rowspan=3> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:20px;height:10px;background:#fff" rowspan=4 colspan=2> </td><td style="width:10px;height:20px;background:rgb(237,127,127)" rowspan=2> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:20px;height:10px;background:#fff" rowspan=3 colspan=2> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td></tr>
|
||||
<tr><td style="width:10px;height:10px;background:#fff" rowspan=2> </td></tr>
|
||||
<tr><td style="width:10px;height:10px;background:#fff"> </td></tr>
|
||||
<tr><td style="width:60px;height:10px;background:rgb(237,127,127)" colspan=6> </td><td colspan=10 style="width:10px;height:10px;background:rgb(237,127,127)"> </td></tr>
|
||||
<tr><td colspan=5 style="width:50px;height:10px;background:#fff"> </td><td style="width:40px;height:10px;background:rgb(237,127,127)" colspan=4> </td><td style="width:90px;height:10px;background:#fff" colspan=9> </td></tr>
|
||||
</table>
|
||||
<p id="footer">npm-coding-style — npm@2.15.12</p>
|
||||
|
||||
818
node_modules/npm/html/doc/misc/npm-config.html
generated
vendored
Normal file
818
node_modules/npm/html/doc/misc/npm-config.html
generated
vendored
Normal file
@@ -0,0 +1,818 @@
|
||||
<!doctype html>
|
||||
<html>
|
||||
<title>npm-config</title>
|
||||
<meta charset="utf-8">
|
||||
<link rel="stylesheet" type="text/css" href="../../static/style.css">
|
||||
<link rel="canonical" href="https://www.npmjs.org/doc/misc/npm-config.html">
|
||||
<script async=true src="../../static/toc.js"></script>
|
||||
|
||||
<body>
|
||||
<div id="wrapper">
|
||||
|
||||
<h1><a href="../misc/npm-config.html">npm-config</a></h1> <p>More than you probably want to know about npm configuration</p>
|
||||
<h2 id="description">DESCRIPTION</h2>
|
||||
<p>npm gets its configuration values from the following sources, sorted by priority:</p>
|
||||
<h3 id="command-line-flags">Command Line Flags</h3>
|
||||
<p>Putting <code>--foo bar</code> on the command line sets the <code>foo</code> configuration
|
||||
parameter to <code>"bar"</code>. A <code>--</code> argument tells the cli parser to stop
|
||||
reading flags. A <code>--flag</code> parameter that is at the <em>end</em> of the
|
||||
command will be given the value of <code>true</code>.</p>
|
||||
<h3 id="environment-variables">Environment Variables</h3>
|
||||
<p>Any environment variables that start with <code>npm_config_</code> will be
|
||||
interpreted as a configuration parameter. For example, putting
|
||||
<code>npm_config_foo=bar</code> in your environment will set the <code>foo</code>
|
||||
configuration parameter to <code>bar</code>. Any environment configurations that
|
||||
are not given a value will be given the value of <code>true</code>. Config
|
||||
values are case-insensitive, so <code>NPM_CONFIG_FOO=bar</code> will work the
|
||||
same.</p>
|
||||
<h3 id="npmrc-files">npmrc Files</h3>
|
||||
<p>The four relevant files are:</p>
|
||||
<ul>
|
||||
<li>per-project configuration file (<code>/path/to/my/project/.npmrc</code>)</li>
|
||||
<li>per-user configuration file (defaults to <code>$HOME/.npmrc</code>; configurable via CLI
|
||||
option <code>--userconfig</code> or environment variable <code>$NPM_CONF_USERCONFIG</code>)</li>
|
||||
<li>global configuration file (defaults to <code>$PREFIX/etc/npmrc</code>; configurable via
|
||||
CLI option <code>--globalconfig</code> or environment variable <code>$NPM_CONF_GLOBALCONFIG</code>)</li>
|
||||
<li>npm's built-in configuration file (<code>/path/to/npm/npmrc</code>)</li>
|
||||
</ul>
|
||||
<p>See <a href="../files/npmrc.html">npmrc(5)</a> for more details.</p>
|
||||
<h3 id="default-configs">Default Configs</h3>
|
||||
<p>A set of configuration parameters that are internal to npm, and are
|
||||
defaults if nothing else is specified.</p>
|
||||
<h2 id="shorthands-and-other-cli-niceties">Shorthands and Other CLI Niceties</h2>
|
||||
<p>The following shorthands are parsed on the command-line:</p>
|
||||
<ul>
|
||||
<li><code>-v</code>: <code>--version</code></li>
|
||||
<li><code>-h</code>, <code>-?</code>, <code>--help</code>, <code>-H</code>: <code>--usage</code></li>
|
||||
<li><code>-s</code>, <code>--silent</code>: <code>--loglevel silent</code></li>
|
||||
<li><code>-q</code>, <code>--quiet</code>: <code>--loglevel warn</code></li>
|
||||
<li><code>-d</code>: <code>--loglevel info</code></li>
|
||||
<li><code>-dd</code>, <code>--verbose</code>: <code>--loglevel verbose</code></li>
|
||||
<li><code>-ddd</code>: <code>--loglevel silly</code></li>
|
||||
<li><code>-g</code>: <code>--global</code></li>
|
||||
<li><code>-C</code>: <code>--prefix</code></li>
|
||||
<li><code>-l</code>: <code>--long</code></li>
|
||||
<li><code>-m</code>: <code>--message</code></li>
|
||||
<li><code>-p</code>, <code>--porcelain</code>: <code>--parseable</code></li>
|
||||
<li><code>-reg</code>: <code>--registry</code></li>
|
||||
<li><code>-f</code>: <code>--force</code></li>
|
||||
<li><code>-desc</code>: <code>--description</code></li>
|
||||
<li><code>-S</code>: <code>--save</code></li>
|
||||
<li><code>-D</code>: <code>--save-dev</code></li>
|
||||
<li><code>-O</code>: <code>--save-optional</code></li>
|
||||
<li><code>-B</code>: <code>--save-bundle</code></li>
|
||||
<li><code>-E</code>: <code>--save-exact</code></li>
|
||||
<li><code>-y</code>: <code>--yes</code></li>
|
||||
<li><code>-n</code>: <code>--yes false</code></li>
|
||||
<li><code>ll</code> and <code>la</code> commands: <code>ls --long</code></li>
|
||||
</ul>
|
||||
<p>If the specified configuration param resolves unambiguously to a known
|
||||
configuration parameter, then it is expanded to that configuration
|
||||
parameter. For example:</p>
|
||||
<pre><code>npm ls --par
|
||||
# same as:
|
||||
npm ls --parseable
|
||||
</code></pre><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:</p>
|
||||
<pre><code>npm ls -gpld
|
||||
# same as:
|
||||
npm ls --global --parseable --long --loglevel info
|
||||
</code></pre><h2 id="per-package-config-settings">Per-Package Config Settings</h2>
|
||||
<p>When running scripts (see <code><a href="../misc/npm-scripts.html">npm-scripts(7)</a></code>) the package.json "config"
|
||||
keys are overwritten in the environment if there is a config param of
|
||||
<code><name>[@<version>]:<key></code>. For example, if the package.json has
|
||||
this:</p>
|
||||
<pre><code>{ "name" : "foo"
|
||||
, "config" : { "port" : "8080" }
|
||||
, "scripts" : { "start" : "node server.js" } }
|
||||
</code></pre><p>and the server.js is this:</p>
|
||||
<pre><code>http.createServer(...).listen(process.env.npm_package_config_port)
|
||||
</code></pre><p>then the user could change the behavior by doing:</p>
|
||||
<pre><code>npm config set foo:port 80
|
||||
</code></pre><p>See <a href="../files/package.json.html">package.json(5)</a> for more information.</p>
|
||||
<h2 id="config-settings">Config Settings</h2>
|
||||
<h3 id="access">access</h3>
|
||||
<ul>
|
||||
<li>Default: <code>restricted</code></li>
|
||||
<li>Type: Access</li>
|
||||
</ul>
|
||||
<p>When publishing scoped packages, the access level defaults to <code>restricted</code>. If
|
||||
you want your scoped package to be publicly viewable (and installable) set
|
||||
<code>--access=public</code>. The only valid values for <code>access</code> are <code>public</code> and
|
||||
<code>restricted</code>. Unscoped packages <em>always</em> have an access level of <code>public</code>.</p>
|
||||
<h3 id="always-auth">always-auth</h3>
|
||||
<ul>
|
||||
<li>Default: false</li>
|
||||
<li>Type: Boolean</li>
|
||||
</ul>
|
||||
<p>Force npm to always require authentication when accessing the registry,
|
||||
even for <code>GET</code> requests.</p>
|
||||
<h3 id="bin-links">bin-links</h3>
|
||||
<ul>
|
||||
<li>Default: <code>true</code></li>
|
||||
<li>Type: Boolean</li>
|
||||
</ul>
|
||||
<p>Tells npm to create symlinks (or <code>.cmd</code> shims on Windows) for package
|
||||
executables.</p>
|
||||
<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.</p>
|
||||
<h3 id="browser">browser</h3>
|
||||
<ul>
|
||||
<li>Default: OS X: <code>"open"</code>, Windows: <code>"start"</code>, Others: <code>"xdg-open"</code></li>
|
||||
<li>Type: String</li>
|
||||
</ul>
|
||||
<p>The browser that is called by the <code>npm docs</code> command to open websites.</p>
|
||||
<h3 id="ca">ca</h3>
|
||||
<ul>
|
||||
<li>Default: The npm CA certificate</li>
|
||||
<li>Type: String, Array or null</li>
|
||||
</ul>
|
||||
<p>The Certificate Authority signing certificate that is trusted for SSL
|
||||
connections to the registry. Values should be in PEM format with newlines
|
||||
replaced by the string "\n". For example:</p>
|
||||
<pre><code>ca="-----BEGIN CERTIFICATE-----\nXXXX\nXXXX\n-----END CERTIFICATE-----"
|
||||
</code></pre><p>Set to <code>null</code> to only allow "known" registrars, or to a specific CA cert
|
||||
to trust only that specific signing authority.</p>
|
||||
<p>Multiple CAs can be trusted by specifying an array of certificates:</p>
|
||||
<pre><code>ca[]="..."
|
||||
ca[]="..."
|
||||
</code></pre><p>See also the <code>strict-ssl</code> config.</p>
|
||||
<h3 id="cafile">cafile</h3>
|
||||
<ul>
|
||||
<li>Default: <code>null</code></li>
|
||||
<li>Type: path</li>
|
||||
</ul>
|
||||
<p>A path to a file containing one or multiple Certificate Authority signing
|
||||
certificates. Similar to the <code>ca</code> setting, but allows for multiple CA's, as
|
||||
well as for the CA information to be stored in a file on disk.</p>
|
||||
<h3 id="cache">cache</h3>
|
||||
<ul>
|
||||
<li>Default: Windows: <code>%AppData%\npm-cache</code>, Posix: <code>~/.npm</code></li>
|
||||
<li>Type: path</li>
|
||||
</ul>
|
||||
<p>The location of npm's cache directory. See <code><a href="../cli/npm-cache.html">npm-cache(1)</a></code></p>
|
||||
<h3 id="cache-lock-stale">cache-lock-stale</h3>
|
||||
<ul>
|
||||
<li>Default: 60000 (1 minute)</li>
|
||||
<li>Type: Number</li>
|
||||
</ul>
|
||||
<p>The number of ms before cache folder lockfiles are considered stale.</p>
|
||||
<h3 id="cache-lock-retries">cache-lock-retries</h3>
|
||||
<ul>
|
||||
<li>Default: 10</li>
|
||||
<li>Type: Number</li>
|
||||
</ul>
|
||||
<p>Number of times to retry to acquire a lock on cache folder lockfiles.</p>
|
||||
<h3 id="cache-lock-wait">cache-lock-wait</h3>
|
||||
<ul>
|
||||
<li>Default: 10000 (10 seconds)</li>
|
||||
<li>Type: Number</li>
|
||||
</ul>
|
||||
<p>Number of ms to wait for cache lock files to expire.</p>
|
||||
<h3 id="cache-max">cache-max</h3>
|
||||
<ul>
|
||||
<li>Default: Infinity</li>
|
||||
<li>Type: Number</li>
|
||||
</ul>
|
||||
<p>The maximum time (in seconds) to keep items in the registry cache before
|
||||
re-checking against the registry.</p>
|
||||
<p>Note that no purging is done unless the <code>npm cache clean</code> command is
|
||||
explicitly used, and that only GET requests use the cache.</p>
|
||||
<h3 id="cache-min">cache-min</h3>
|
||||
<ul>
|
||||
<li>Default: 10</li>
|
||||
<li>Type: Number</li>
|
||||
</ul>
|
||||
<p>The minimum time (in seconds) to keep items in the registry cache before
|
||||
re-checking against the registry.</p>
|
||||
<p>Note that no purging is done unless the <code>npm cache clean</code> command is
|
||||
explicitly used, and that only GET requests use the cache.</p>
|
||||
<h3 id="cert">cert</h3>
|
||||
<ul>
|
||||
<li>Default: <code>null</code></li>
|
||||
<li>Type: String</li>
|
||||
</ul>
|
||||
<p>A client certificate to pass when accessing the registry. Values should be in
|
||||
PEM format with newlines replaced by the string "\n". For example:</p>
|
||||
<pre><code>cert="-----BEGIN CERTIFICATE-----\nXXXX\nXXXX\n-----END CERTIFICATE-----"
|
||||
</code></pre><p>It is <em>not</em> the path to a certificate file (and there is no "certfile" option).</p>
|
||||
<h3 id="color">color</h3>
|
||||
<ul>
|
||||
<li>Default: true</li>
|
||||
<li>Type: Boolean or <code>"always"</code></li>
|
||||
</ul>
|
||||
<p>If false, never shows colors. If <code>"always"</code> then always shows colors.
|
||||
If true, then only prints color codes for tty file descriptors.</p>
|
||||
<h3 id="depth">depth</h3>
|
||||
<ul>
|
||||
<li>Default: Infinity</li>
|
||||
<li>Type: Number</li>
|
||||
</ul>
|
||||
<p>The depth to go when recursing directories for <code>npm ls</code>,
|
||||
<code>npm cache ls</code>, and <code>npm outdated</code>.</p>
|
||||
<p>For <code>npm outdated</code>, a setting of <code>Infinity</code> will be treated as <code>0</code>
|
||||
since that gives more useful information. To show the outdated status
|
||||
of all packages and dependents, use a large integer value,
|
||||
e.g., <code>npm outdated --depth 9999</code></p>
|
||||
<h3 id="description">description</h3>
|
||||
<ul>
|
||||
<li>Default: true</li>
|
||||
<li>Type: Boolean</li>
|
||||
</ul>
|
||||
<p>Show the description in <code>npm search</code></p>
|
||||
<h3 id="dev">dev</h3>
|
||||
<ul>
|
||||
<li>Default: false</li>
|
||||
<li>Type: Boolean</li>
|
||||
</ul>
|
||||
<p>Install <code>dev-dependencies</code> along with packages.</p>
|
||||
<p>Note that <code>dev-dependencies</code> are also installed if the <code>npat</code> flag is
|
||||
set.</p>
|
||||
<h3 id="editor">editor</h3>
|
||||
<ul>
|
||||
<li>Default: <code>EDITOR</code> environment variable if set, or <code>"vi"</code> on Posix,
|
||||
or <code>"notepad"</code> on Windows.</li>
|
||||
<li>Type: path</li>
|
||||
</ul>
|
||||
<p>The command to run for <code>npm edit</code> or <code>npm config edit</code>.</p>
|
||||
<h3 id="engine-strict">engine-strict</h3>
|
||||
<ul>
|
||||
<li>Default: false</li>
|
||||
<li>Type: Boolean</li>
|
||||
</ul>
|
||||
<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.</p>
|
||||
<h3 id="force">force</h3>
|
||||
<ul>
|
||||
<li>Default: false</li>
|
||||
<li>Type: Boolean</li>
|
||||
</ul>
|
||||
<p>Makes various commands more forceful.</p>
|
||||
<ul>
|
||||
<li>lifecycle script failure does not block progress.</li>
|
||||
<li>publishing clobbers previously published versions.</li>
|
||||
<li>skips cache when requesting from the registry.</li>
|
||||
<li>prevents checks against clobbering non-npm files.</li>
|
||||
</ul>
|
||||
<h3 id="fetch-retries">fetch-retries</h3>
|
||||
<ul>
|
||||
<li>Default: 2</li>
|
||||
<li>Type: Number</li>
|
||||
</ul>
|
||||
<p>The "retries" config for the <code>retry</code> module to use when fetching
|
||||
packages from the registry.</p>
|
||||
<h3 id="fetch-retry-factor">fetch-retry-factor</h3>
|
||||
<ul>
|
||||
<li>Default: 10</li>
|
||||
<li>Type: Number</li>
|
||||
</ul>
|
||||
<p>The "factor" config for the <code>retry</code> module to use when fetching
|
||||
packages.</p>
|
||||
<h3 id="fetch-retry-mintimeout">fetch-retry-mintimeout</h3>
|
||||
<ul>
|
||||
<li>Default: 10000 (10 seconds)</li>
|
||||
<li>Type: Number</li>
|
||||
</ul>
|
||||
<p>The "minTimeout" config for the <code>retry</code> module to use when fetching
|
||||
packages.</p>
|
||||
<h3 id="fetch-retry-maxtimeout">fetch-retry-maxtimeout</h3>
|
||||
<ul>
|
||||
<li>Default: 60000 (1 minute)</li>
|
||||
<li>Type: Number</li>
|
||||
</ul>
|
||||
<p>The "maxTimeout" config for the <code>retry</code> module to use when fetching
|
||||
packages.</p>
|
||||
<h3 id="git">git</h3>
|
||||
<ul>
|
||||
<li>Default: <code>"git"</code></li>
|
||||
<li>Type: String</li>
|
||||
</ul>
|
||||
<p>The command to use for git commands. If git is installed on the
|
||||
computer, but is not in the <code>PATH</code>, then set this to the full path to
|
||||
the git binary.</p>
|
||||
<h3 id="git-tag-version">git-tag-version</h3>
|
||||
<ul>
|
||||
<li>Default: <code>true</code></li>
|
||||
<li>Type: Boolean</li>
|
||||
</ul>
|
||||
<p>Tag the commit when using the <code>npm version</code> command.</p>
|
||||
<h3 id="global">global</h3>
|
||||
<ul>
|
||||
<li>Default: false</li>
|
||||
<li>Type: Boolean</li>
|
||||
</ul>
|
||||
<p>Operates in "global" mode, so that packages are installed into the
|
||||
<code>prefix</code> folder instead of the current working directory. See
|
||||
<code><a href="../files/npm-folders.html">npm-folders(5)</a></code> for more on the differences in behavior.</p>
|
||||
<ul>
|
||||
<li>packages are installed into the <code>{prefix}/lib/node_modules</code> folder, instead of the
|
||||
current working directory.</li>
|
||||
<li>bin files are linked to <code>{prefix}/bin</code></li>
|
||||
<li>man pages are linked to <code>{prefix}/share/man</code></li>
|
||||
</ul>
|
||||
<h3 id="globalconfig">globalconfig</h3>
|
||||
<ul>
|
||||
<li>Default: {prefix}/etc/npmrc</li>
|
||||
<li>Type: path</li>
|
||||
</ul>
|
||||
<p>The config file to read for global config options.</p>
|
||||
<h3 id="group">group</h3>
|
||||
<ul>
|
||||
<li>Default: GID of the current process</li>
|
||||
<li>Type: String or Number</li>
|
||||
</ul>
|
||||
<p>The group to use when running package scripts in global mode as the root
|
||||
user.</p>
|
||||
<h3 id="heading">heading</h3>
|
||||
<ul>
|
||||
<li>Default: <code>"npm"</code></li>
|
||||
<li>Type: String</li>
|
||||
</ul>
|
||||
<p>The string that starts all the debugging log output.</p>
|
||||
<h3 id="https-proxy">https-proxy</h3>
|
||||
<ul>
|
||||
<li>Default: null</li>
|
||||
<li>Type: url</li>
|
||||
</ul>
|
||||
<p>A proxy to use for outgoing https requests. If the <code>HTTPS_PROXY</code> or
|
||||
<code>https_proxy</code> or <code>HTTP_PROXY</code> or <code>http_proxy</code> environment variables are set,
|
||||
proxy settings will be honored by the underlying <code>request</code> library.</p>
|
||||
<h3 id="if-present">if-present</h3>
|
||||
<ul>
|
||||
<li>Default: false</li>
|
||||
<li>Type: Boolean</li>
|
||||
</ul>
|
||||
<p>If true, npm will not exit with an error code when <code>run-script</code> is invoked for
|
||||
a script that isn't defined in the <code>scripts</code> section of <code>package.json</code>. This
|
||||
option can be used when it's desirable to optionally run a script when it's
|
||||
present and fail if the script fails. This is useful, for example, when running
|
||||
scripts that may only apply for some builds in an otherwise generic CI setup.</p>
|
||||
<h3 id="ignore-scripts">ignore-scripts</h3>
|
||||
<ul>
|
||||
<li>Default: false</li>
|
||||
<li>Type: Boolean</li>
|
||||
</ul>
|
||||
<p>If true, npm does not run scripts specified in package.json files.</p>
|
||||
<h3 id="init-module">init-module</h3>
|
||||
<ul>
|
||||
<li>Default: ~/.npm-init.js</li>
|
||||
<li>Type: path</li>
|
||||
</ul>
|
||||
<p>A module that will be loaded by the <code>npm init</code> command. See the
|
||||
documentation for the
|
||||
<a href="https://github.com/isaacs/init-package-json">init-package-json</a> module
|
||||
for more information, or <a href="../cli/npm-init.html">npm-init(1)</a>.</p>
|
||||
<h3 id="init-author-name">init-author-name</h3>
|
||||
<ul>
|
||||
<li>Default: ""</li>
|
||||
<li>Type: String</li>
|
||||
</ul>
|
||||
<p>The value <code>npm init</code> should use by default for the package author's name.</p>
|
||||
<h3 id="init-author-email">init-author-email</h3>
|
||||
<ul>
|
||||
<li>Default: ""</li>
|
||||
<li>Type: String</li>
|
||||
</ul>
|
||||
<p>The value <code>npm init</code> should use by default for the package author's email.</p>
|
||||
<h3 id="init-author-url">init-author-url</h3>
|
||||
<ul>
|
||||
<li>Default: ""</li>
|
||||
<li>Type: String</li>
|
||||
</ul>
|
||||
<p>The value <code>npm init</code> should use by default for the package author's homepage.</p>
|
||||
<h3 id="init-license">init-license</h3>
|
||||
<ul>
|
||||
<li>Default: "ISC"</li>
|
||||
<li>Type: String</li>
|
||||
</ul>
|
||||
<p>The value <code>npm init</code> should use by default for the package license.</p>
|
||||
<h3 id="init-version">init-version</h3>
|
||||
<ul>
|
||||
<li>Default: "1.0.0"</li>
|
||||
<li>Type: semver</li>
|
||||
</ul>
|
||||
<p>The value that <code>npm init</code> should use by default for the package
|
||||
version number, if not already set in package.json.</p>
|
||||
<h3 id="json">json</h3>
|
||||
<ul>
|
||||
<li>Default: false</li>
|
||||
<li>Type: Boolean</li>
|
||||
</ul>
|
||||
<p>Whether or not to output JSON data, rather than the normal output.</p>
|
||||
<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 <code>npm ls --json</code> is currently valid.</p>
|
||||
<h3 id="key">key</h3>
|
||||
<ul>
|
||||
<li>Default: <code>null</code></li>
|
||||
<li>Type: String</li>
|
||||
</ul>
|
||||
<p>A client key to pass when accessing the registry. Values should be in PEM
|
||||
format with newlines replaced by the string "\n". For example:</p>
|
||||
<pre><code>key="-----BEGIN PRIVATE KEY-----\nXXXX\nXXXX\n-----END PRIVATE KEY-----"
|
||||
</code></pre><p>It is <em>not</em> the path to a key file (and there is no "keyfile" option).</p>
|
||||
<h3 id="link">link</h3>
|
||||
<ul>
|
||||
<li>Default: false</li>
|
||||
<li>Type: Boolean</li>
|
||||
</ul>
|
||||
<p>If true, then local installs will link if there is a suitable globally
|
||||
installed package.</p>
|
||||
<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:</p>
|
||||
<ul>
|
||||
<li>The package is not already installed globally, or</li>
|
||||
<li>the globally installed version is identical to the version that is
|
||||
being installed locally.</li>
|
||||
</ul>
|
||||
<h3 id="local-address">local-address</h3>
|
||||
<ul>
|
||||
<li>Default: undefined</li>
|
||||
<li>Type: IP Address</li>
|
||||
</ul>
|
||||
<p>The IP address of the local interface to use when making connections
|
||||
to the npm registry. Must be IPv4 in versions of Node prior to 0.12.</p>
|
||||
<h3 id="loglevel">loglevel</h3>
|
||||
<ul>
|
||||
<li>Default: "warn"</li>
|
||||
<li>Type: String</li>
|
||||
<li>Values: "silent", "error", "warn", "http", "info", "verbose", "silly"</li>
|
||||
</ul>
|
||||
<p>What level of logs to report. On failure, <em>all</em> logs are written to
|
||||
<code>npm-debug.log</code> in the current working directory.</p>
|
||||
<p>Any logs of a higher level than the setting are shown.
|
||||
The default is "warn", which shows warn and error output.</p>
|
||||
<h3 id="logstream">logstream</h3>
|
||||
<ul>
|
||||
<li>Default: process.stderr</li>
|
||||
<li>Type: Stream</li>
|
||||
</ul>
|
||||
<p>This is the stream that is passed to the
|
||||
<a href="https://github.com/npm/npmlog">npmlog</a> module at run time.</p>
|
||||
<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>
|
||||
<p>If the <code>color</code> config is set to true, then this stream will receive
|
||||
colored output if it is a TTY.</p>
|
||||
<h3 id="long">long</h3>
|
||||
<ul>
|
||||
<li>Default: false</li>
|
||||
<li>Type: Boolean</li>
|
||||
</ul>
|
||||
<p>Show extended information in <code>npm ls</code> and <code>npm search</code>.</p>
|
||||
<h3 id="maxsockets">maxsockets</h3>
|
||||
<ul>
|
||||
<li>Default: 50</li>
|
||||
<li>Type: Number</li>
|
||||
</ul>
|
||||
<p>The maximum number of connections to use per origin (protocol/host/port
|
||||
combination). Passed to the <code>http</code> <code>Agent</code> used to make the request.</p>
|
||||
<h3 id="message">message</h3>
|
||||
<ul>
|
||||
<li>Default: "%s"</li>
|
||||
<li>Type: String</li>
|
||||
</ul>
|
||||
<p>Commit message which is used by <code>npm version</code> when creating version commit.</p>
|
||||
<p>Any "%s" in the message will be replaced with the version number.</p>
|
||||
<h3 id="node-version">node-version</h3>
|
||||
<ul>
|
||||
<li>Default: process.version</li>
|
||||
<li>Type: semver or false</li>
|
||||
</ul>
|
||||
<p>The node version to use when checking a package's <code>engines</code> map.</p>
|
||||
<h3 id="npat">npat</h3>
|
||||
<ul>
|
||||
<li>Default: false</li>
|
||||
<li>Type: Boolean</li>
|
||||
</ul>
|
||||
<p>Run tests on installation.</p>
|
||||
<h3 id="onload-script">onload-script</h3>
|
||||
<ul>
|
||||
<li>Default: false</li>
|
||||
<li>Type: path</li>
|
||||
</ul>
|
||||
<p>A node module to <code>require()</code> when npm loads. Useful for programmatic
|
||||
usage.</p>
|
||||
<h3 id="optional">optional</h3>
|
||||
<ul>
|
||||
<li>Default: true</li>
|
||||
<li>Type: Boolean</li>
|
||||
</ul>
|
||||
<p>Attempt to install packages in the <code>optionalDependencies</code> object. Note
|
||||
that if these packages fail to install, the overall installation
|
||||
process is not aborted.</p>
|
||||
<h3 id="parseable">parseable</h3>
|
||||
<ul>
|
||||
<li>Default: false</li>
|
||||
<li>Type: Boolean</li>
|
||||
</ul>
|
||||
<p>Output parseable results from commands that write to
|
||||
standard output.</p>
|
||||
<h3 id="prefix">prefix</h3>
|
||||
<ul>
|
||||
<li>Default: see <a href="../files/npm-folders.html">npm-folders(5)</a></li>
|
||||
<li>Type: path</li>
|
||||
</ul>
|
||||
<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.</p>
|
||||
<h3 id="production">production</h3>
|
||||
<ul>
|
||||
<li>Default: false</li>
|
||||
<li>Type: Boolean</li>
|
||||
</ul>
|
||||
<p>Set to true to run in "production" mode.</p>
|
||||
<ol>
|
||||
<li>devDependencies are not installed at the topmost level when running
|
||||
local <code>npm install</code> without any arguments.</li>
|
||||
<li>Set the NODE_ENV="production" for lifecycle scripts.</li>
|
||||
</ol>
|
||||
<h3 id="proprietary-attribs">proprietary-attribs</h3>
|
||||
<ul>
|
||||
<li>Default: true</li>
|
||||
<li>Type: Boolean</li>
|
||||
</ul>
|
||||
<p>Whether or not to include proprietary extended attributes in the
|
||||
tarballs created by npm.</p>
|
||||
<p>Unless you are expecting to unpack package tarballs with something other
|
||||
than npm -- particularly a very outdated tar implementation -- leave
|
||||
this as true.</p>
|
||||
<h3 id="proxy">proxy</h3>
|
||||
<ul>
|
||||
<li>Default: null</li>
|
||||
<li>Type: url</li>
|
||||
</ul>
|
||||
<p>A proxy to use for outgoing http requests. If the <code>HTTP_PROXY</code> or
|
||||
<code>http_proxy</code> environment variables are set, proxy settings will be
|
||||
honored by the underlying <code>request</code> library.</p>
|
||||
<h3 id="rebuild-bundle">rebuild-bundle</h3>
|
||||
<ul>
|
||||
<li>Default: true</li>
|
||||
<li>Type: Boolean</li>
|
||||
</ul>
|
||||
<p>Rebuild bundled dependencies after installation.</p>
|
||||
<h3 id="registry">registry</h3>
|
||||
<ul>
|
||||
<li>Default: <a href="https://registry.npmjs.org/">https://registry.npmjs.org/</a></li>
|
||||
<li>Type: url</li>
|
||||
</ul>
|
||||
<p>The base URL of the npm package registry.</p>
|
||||
<h3 id="rollback">rollback</h3>
|
||||
<ul>
|
||||
<li>Default: true</li>
|
||||
<li>Type: Boolean</li>
|
||||
</ul>
|
||||
<p>Remove failed installs.</p>
|
||||
<h3 id="save">save</h3>
|
||||
<ul>
|
||||
<li>Default: false</li>
|
||||
<li>Type: Boolean</li>
|
||||
</ul>
|
||||
<p>Save installed packages to a package.json file as dependencies.</p>
|
||||
<p>When used with the <code>npm rm</code> command, it removes it from the <code>dependencies</code>
|
||||
object.</p>
|
||||
<p>Only works if there is already a package.json file present.</p>
|
||||
<h3 id="save-bundle">save-bundle</h3>
|
||||
<ul>
|
||||
<li>Default: false</li>
|
||||
<li>Type: Boolean</li>
|
||||
</ul>
|
||||
<p>If a package would be saved at install time by the use of <code>--save</code>,
|
||||
<code>--save-dev</code>, or <code>--save-optional</code>, then also put it in the
|
||||
<code>bundleDependencies</code> list.</p>
|
||||
<p>When used with the <code>npm rm</code> command, it removes it from the
|
||||
bundledDependencies list.</p>
|
||||
<h3 id="save-dev">save-dev</h3>
|
||||
<ul>
|
||||
<li>Default: false</li>
|
||||
<li>Type: Boolean</li>
|
||||
</ul>
|
||||
<p>Save installed packages to a package.json file as <code>devDependencies</code>.</p>
|
||||
<p>When used with the <code>npm rm</code> command, it removes it from the
|
||||
<code>devDependencies</code> object.</p>
|
||||
<p>Only works if there is already a package.json file present.</p>
|
||||
<h3 id="save-exact">save-exact</h3>
|
||||
<ul>
|
||||
<li>Default: false</li>
|
||||
<li>Type: Boolean</li>
|
||||
</ul>
|
||||
<p>Dependencies saved to package.json using <code>--save</code>, <code>--save-dev</code> or
|
||||
<code>--save-optional</code> will be configured with an exact version rather than
|
||||
using npm's default semver range operator.</p>
|
||||
<h3 id="save-optional">save-optional</h3>
|
||||
<ul>
|
||||
<li>Default: false</li>
|
||||
<li>Type: Boolean</li>
|
||||
</ul>
|
||||
<p>Save installed packages to a package.json file as
|
||||
optionalDependencies.</p>
|
||||
<p>When used with the <code>npm rm</code> command, it removes it from the
|
||||
<code>devDependencies</code> object.</p>
|
||||
<p>Only works if there is already a package.json file present.</p>
|
||||
<h3 id="save-prefix">save-prefix</h3>
|
||||
<ul>
|
||||
<li>Default: '^'</li>
|
||||
<li>Type: String</li>
|
||||
</ul>
|
||||
<p>Configure how versions of packages installed to a package.json file via
|
||||
<code>--save</code> or <code>--save-dev</code> get prefixed.</p>
|
||||
<p>For example if a package has version <code>1.2.3</code>, by default its version is
|
||||
set to <code>^1.2.3</code> which allows minor upgrades for that package, but after
|
||||
<code>npm config set save-prefix='~'</code> it would be set to <code>~1.2.3</code> which only allows
|
||||
patch upgrades.</p>
|
||||
<h3 id="scope">scope</h3>
|
||||
<ul>
|
||||
<li>Default: ""</li>
|
||||
<li>Type: String</li>
|
||||
</ul>
|
||||
<p>Associate an operation with a scope for a scoped registry. Useful when logging
|
||||
in to a private registry for the first time:
|
||||
<code>npm login --scope=@organization --registry=registry.organization.com</code>, which
|
||||
will cause <code>@organization</code> to be mapped to the registry for future installation
|
||||
of packages specified according to the pattern <code>@organization/package</code>.</p>
|
||||
<h3 id="searchopts">searchopts</h3>
|
||||
<ul>
|
||||
<li>Default: ""</li>
|
||||
<li>Type: String</li>
|
||||
</ul>
|
||||
<p>Space-separated options that are always passed to search.</p>
|
||||
<h3 id="searchexclude">searchexclude</h3>
|
||||
<ul>
|
||||
<li>Default: ""</li>
|
||||
<li>Type: String</li>
|
||||
</ul>
|
||||
<p>Space-separated options that limit the results from search.</p>
|
||||
<h3 id="searchsort">searchsort</h3>
|
||||
<ul>
|
||||
<li>Default: "name"</li>
|
||||
<li>Type: String</li>
|
||||
<li>Values: "name", "-name", "date", "-date", "description",
|
||||
"-description", "keywords", "-keywords"</li>
|
||||
</ul>
|
||||
<p>Indication of which field to sort search results by. Prefix with a <code>-</code>
|
||||
character to indicate reverse sort.</p>
|
||||
<h3 id="shell">shell</h3>
|
||||
<ul>
|
||||
<li>Default: SHELL environment variable, or "bash" on Posix, or "cmd" on
|
||||
Windows</li>
|
||||
<li>Type: path</li>
|
||||
</ul>
|
||||
<p>The shell to run for the <code>npm explore</code> command.</p>
|
||||
<h3 id="shrinkwrap">shrinkwrap</h3>
|
||||
<ul>
|
||||
<li>Default: true</li>
|
||||
<li>Type: Boolean</li>
|
||||
</ul>
|
||||
<p>If set to false, then ignore <code>npm-shrinkwrap.json</code> files when
|
||||
installing.</p>
|
||||
<h3 id="sign-git-tag">sign-git-tag</h3>
|
||||
<ul>
|
||||
<li>Default: false</li>
|
||||
<li>Type: Boolean</li>
|
||||
</ul>
|
||||
<p>If set to true, then the <code>npm version</code> command will tag the version
|
||||
using <code>-s</code> to add a signature.</p>
|
||||
<p>Note that git requires you to have set up GPG keys in your git configs
|
||||
for this to work properly.</p>
|
||||
<h3 id="spin">spin</h3>
|
||||
<ul>
|
||||
<li>Default: true</li>
|
||||
<li>Type: Boolean or <code>"always"</code></li>
|
||||
</ul>
|
||||
<p>When set to <code>true</code>, npm will display an ascii spinner while it is doing
|
||||
things, if <code>process.stderr</code> is a TTY.</p>
|
||||
<p>Set to <code>false</code> to suppress the spinner, or set to <code>always</code> to output
|
||||
the spinner even for non-TTY outputs.</p>
|
||||
<h3 id="strict-ssl">strict-ssl</h3>
|
||||
<ul>
|
||||
<li>Default: true</li>
|
||||
<li>Type: Boolean</li>
|
||||
</ul>
|
||||
<p>Whether or not to do SSL key validation when making requests to the
|
||||
registry via https.</p>
|
||||
<p>See also the <code>ca</code> config.</p>
|
||||
<h3 id="tag">tag</h3>
|
||||
<ul>
|
||||
<li>Default: latest</li>
|
||||
<li>Type: String</li>
|
||||
</ul>
|
||||
<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>
|
||||
<p>Also the tag that is added to the package@version specified by the <code>npm
|
||||
tag</code> command, if no explicit tag is given.</p>
|
||||
<h3 id="tag-version-prefix">tag-version-prefix</h3>
|
||||
<ul>
|
||||
<li>Default: <code>"v"</code></li>
|
||||
<li>Type: String</li>
|
||||
</ul>
|
||||
<p>If set, alters the prefix used when tagging a new version when performing a
|
||||
version increment using <code>npm-version</code>. To remove the prefix altogether, set it
|
||||
to the empty string: <code>""</code>.</p>
|
||||
<p>Because other tools may rely on the convention that npm version tags look like
|
||||
<code>v1.0.0</code>, <em>only use this property if it is absolutely necessary</em>. In
|
||||
particular, use care when overriding this setting for public packages.</p>
|
||||
<h3 id="tmp">tmp</h3>
|
||||
<ul>
|
||||
<li>Default: TMPDIR environment variable, or "/tmp"</li>
|
||||
<li>Type: path</li>
|
||||
</ul>
|
||||
<p>Where to store temporary files and folders. All temp files are deleted
|
||||
on success, but left behind on failure for forensic purposes.</p>
|
||||
<h3 id="unicode">unicode</h3>
|
||||
<ul>
|
||||
<li>Default: true</li>
|
||||
<li>Type: Boolean</li>
|
||||
</ul>
|
||||
<p>When set to true, npm uses unicode characters in the tree output. When
|
||||
false, it uses ascii characters to draw trees.</p>
|
||||
<h3 id="unsafe-perm">unsafe-perm</h3>
|
||||
<ul>
|
||||
<li>Default: false if running as root, true otherwise</li>
|
||||
<li>Type: Boolean</li>
|
||||
</ul>
|
||||
<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.</p>
|
||||
<h3 id="usage">usage</h3>
|
||||
<ul>
|
||||
<li>Default: false</li>
|
||||
<li>Type: Boolean</li>
|
||||
</ul>
|
||||
<p>Set to show short usage output (like the -H output)
|
||||
instead of complete help when doing <code><a href="../cli/npm-help.html">npm-help(1)</a></code>.</p>
|
||||
<h3 id="user">user</h3>
|
||||
<ul>
|
||||
<li>Default: "nobody"</li>
|
||||
<li>Type: String or Number</li>
|
||||
</ul>
|
||||
<p>The UID to set to when running package scripts as root.</p>
|
||||
<h3 id="userconfig">userconfig</h3>
|
||||
<ul>
|
||||
<li>Default: ~/.npmrc</li>
|
||||
<li>Type: path</li>
|
||||
</ul>
|
||||
<p>The location of user-level configuration settings.</p>
|
||||
<h3 id="umask">umask</h3>
|
||||
<ul>
|
||||
<li>Default: 022</li>
|
||||
<li>Type: Octal numeric string in range 0000..0777 (0..511)</li>
|
||||
</ul>
|
||||
<p>The "umask" value to use when setting the file creation mode on files
|
||||
and folders.</p>
|
||||
<p>Folders and executables are given a mode which is <code>0777</code> masked against
|
||||
this value. Other files are given a mode which is <code>0666</code> masked against
|
||||
this value. Thus, the defaults are <code>0755</code> and <code>0644</code> respectively.</p>
|
||||
<h3 id="user-agent">user-agent</h3>
|
||||
<ul>
|
||||
<li>Default: node/{process.version} {process.platform} {process.arch}</li>
|
||||
<li>Type: String</li>
|
||||
</ul>
|
||||
<p>Sets a User-Agent to the request header</p>
|
||||
<h3 id="version">version</h3>
|
||||
<ul>
|
||||
<li>Default: false</li>
|
||||
<li>Type: boolean</li>
|
||||
</ul>
|
||||
<p>If true, output the npm version and exit successfully.</p>
|
||||
<p>Only relevant when specified explicitly on the command line.</p>
|
||||
<h3 id="versions">versions</h3>
|
||||
<ul>
|
||||
<li>Default: false</li>
|
||||
<li>Type: boolean</li>
|
||||
</ul>
|
||||
<p>If true, output the npm version as well as node's <code>process.versions</code> map, and
|
||||
exit successfully.</p>
|
||||
<p>Only relevant when specified explicitly on the command line.</p>
|
||||
<h3 id="viewer">viewer</h3>
|
||||
<ul>
|
||||
<li>Default: "man" on Posix, "browser" on Windows</li>
|
||||
<li>Type: path</li>
|
||||
</ul>
|
||||
<p>The program to use to view help content.</p>
|
||||
<p>Set to <code>"browser"</code> to view html help content in the default web browser.</p>
|
||||
<h2 id="see-also">SEE ALSO</h2>
|
||||
<ul>
|
||||
<li><a href="../cli/npm-config.html">npm-config(1)</a></li>
|
||||
<li><a href="../files/npmrc.html">npmrc(5)</a></li>
|
||||
<li><a href="../misc/npm-scripts.html">npm-scripts(7)</a></li>
|
||||
<li><a href="../files/npm-folders.html">npm-folders(5)</a></li>
|
||||
<li><a href="../cli/npm.html">npm(1)</a></li>
|
||||
</ul>
|
||||
|
||||
</div>
|
||||
|
||||
<table border=0 cellspacing=0 cellpadding=0 id=npmlogo>
|
||||
<tr><td style="width:180px;height:10px;background:rgb(237,127,127)" colspan=18> </td></tr>
|
||||
<tr><td rowspan=4 style="width:10px;height:10px;background:rgb(237,127,127)"> </td><td style="width:40px;height:10px;background:#fff" colspan=4> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=4> </td><td style="width:40px;height:10px;background:#fff" colspan=4> </td><td rowspan=4 style="width:10px;height:10px;background:rgb(237,127,127)"> </td><td colspan=6 style="width:60px;height:10px;background:#fff"> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=4> </td></tr>
|
||||
<tr><td colspan=2 style="width:20px;height:30px;background:#fff" rowspan=3> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:20px;height:10px;background:#fff" rowspan=4 colspan=2> </td><td style="width:10px;height:20px;background:rgb(237,127,127)" rowspan=2> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:20px;height:10px;background:#fff" rowspan=3 colspan=2> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td></tr>
|
||||
<tr><td style="width:10px;height:10px;background:#fff" rowspan=2> </td></tr>
|
||||
<tr><td style="width:10px;height:10px;background:#fff"> </td></tr>
|
||||
<tr><td style="width:60px;height:10px;background:rgb(237,127,127)" colspan=6> </td><td colspan=10 style="width:10px;height:10px;background:rgb(237,127,127)"> </td></tr>
|
||||
<tr><td colspan=5 style="width:50px;height:10px;background:#fff"> </td><td style="width:40px;height:10px;background:rgb(237,127,127)" colspan=4> </td><td style="width:90px;height:10px;background:#fff" colspan=9> </td></tr>
|
||||
</table>
|
||||
<p id="footer">npm-config — npm@2.15.12</p>
|
||||
|
||||
199
node_modules/npm/html/doc/misc/npm-developers.html
generated
vendored
Normal file
199
node_modules/npm/html/doc/misc/npm-developers.html
generated
vendored
Normal file
@@ -0,0 +1,199 @@
|
||||
<!doctype html>
|
||||
<html>
|
||||
<title>npm-developers</title>
|
||||
<meta charset="utf-8">
|
||||
<link rel="stylesheet" type="text/css" href="../../static/style.css">
|
||||
<link rel="canonical" href="https://www.npmjs.org/doc/misc/npm-developers.html">
|
||||
<script async=true src="../../static/toc.js"></script>
|
||||
|
||||
<body>
|
||||
<div id="wrapper">
|
||||
|
||||
<h1><a href="../misc/npm-developers.html">npm-developers</a></h1> <p>Developer Guide</p>
|
||||
<h2 id="description">DESCRIPTION</h2>
|
||||
<p>So, you've decided to use npm to develop (and maybe publish/deploy)
|
||||
your project.</p>
|
||||
<p>Fantastic!</p>
|
||||
<p>There are a few things that you need to do above the simple steps
|
||||
that your users will do to install your program.</p>
|
||||
<h2 id="about-these-documents">About These Documents</h2>
|
||||
<p>These are man pages. If you install npm, you should be able to
|
||||
then do <code>man npm-thing</code> to get the documentation on a particular
|
||||
topic, or <code>npm help thing</code> to see the same information.</p>
|
||||
<h2 id="what-is-a-package-">What is a <code>package</code></h2>
|
||||
<p>A package is:</p>
|
||||
<ul>
|
||||
<li>a) a folder containing a program described by a package.json file</li>
|
||||
<li>b) a gzipped tarball containing (a)</li>
|
||||
<li>c) a url that resolves to (b)</li>
|
||||
<li>d) a <code><name>@<version></code> that is published on the registry with (c)</li>
|
||||
<li>e) a <code><name>@<tag></code> that points to (d)</li>
|
||||
<li>f) a <code><name></code> that has a "latest" tag satisfying (e)</li>
|
||||
<li>g) a <code>git</code> url that, when cloned, results in (a).</li>
|
||||
</ul>
|
||||
<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>
|
||||
<p>Git urls can be of the form:</p>
|
||||
<pre><code>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
|
||||
</code></pre><p>The <code>commit-ish</code> can be any tag, sha, or branch which can be supplied as
|
||||
an argument to <code>git checkout</code>. The default is <code>master</code>.</p>
|
||||
<h2 id="the-package-json-file">The package.json File</h2>
|
||||
<p>You need to have a <code>package.json</code> file in the root of your project to do
|
||||
much of anything with npm. That is basically the whole interface.</p>
|
||||
<p>See <code><a href="../files/package.json.html">package.json(5)</a></code> for details about what goes in that file. At the very
|
||||
least, you need:</p>
|
||||
<ul>
|
||||
<li><p>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.</p>
|
||||
<p>It does not necessarily need to match your github repository name.</p>
|
||||
<p>So, <code>node-foo</code> and <code>bar-js</code> are bad names. <code>foo</code> or <code>bar</code> are better.</p>
|
||||
</li>
|
||||
<li><p>version:
|
||||
A semver-compatible version.</p>
|
||||
</li>
|
||||
<li><p>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.</p>
|
||||
</li>
|
||||
<li><p>author:
|
||||
Take some credit.</p>
|
||||
</li>
|
||||
<li><p>scripts:
|
||||
If you have a special compilation or installation script, then you
|
||||
should put it in the <code>scripts</code> object. You should definitely have at
|
||||
least a basic smoke-test command as the "scripts.test" field.
|
||||
See <a href="../misc/npm-scripts.html">npm-scripts(7)</a>.</p>
|
||||
</li>
|
||||
<li><p>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.</p>
|
||||
</li>
|
||||
<li><p>directories:
|
||||
This is an object mapping names to folders. The best ones to include are
|
||||
"lib" and "doc", but if you use "man" to specify a folder full of man pages,
|
||||
they'll get installed just like these ones.</p>
|
||||
</li>
|
||||
</ul>
|
||||
<p>You can use <code>npm init</code> in the root of your package in order to get you
|
||||
started with a pretty basic package.json file. See <code><a href="../cli/npm-init.html">npm-init(1)</a></code> for
|
||||
more info.</p>
|
||||
<h2 id="keeping-files-out-of-your-package">Keeping files <em>out</em> of your package</h2>
|
||||
<p>Use a <code>.npmignore</code> file to keep stuff out of your package. If there's
|
||||
no <code>.npmignore</code> file, but there <em>is</em> a <code>.gitignore</code> file, then npm will
|
||||
ignore the stuff matched by the <code>.gitignore</code> file. If you <em>want</em> to
|
||||
include something that is excluded by your <code>.gitignore</code> file, you can
|
||||
create an empty <code>.npmignore</code> file to override it. Like <code>git</code>, <code>npm</code> looks
|
||||
for <code>.npmignore</code> and <code>.gitignore</code> files in all subdirectories of your
|
||||
package, not only the root directory.</p>
|
||||
<p><code>.npmignore</code> files follow the <a href="https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository#Ignoring-Files">same pattern rules</a>
|
||||
as <code>.gitignore</code> files:</p>
|
||||
<ul>
|
||||
<li>Blank lines or lines starting with <code>#</code> are ignored.</li>
|
||||
<li>Standard glob patterns work.</li>
|
||||
<li>You can end patterns with a forward slash <code>/</code> to specify a directory.</li>
|
||||
<li>You can negate a pattern by starting it with an exclamation point <code>!</code>.</li>
|
||||
</ul>
|
||||
<p>By default, the following paths and files are ignored, so there's no
|
||||
need to add them to <code>.npmignore</code> explicitly:</p>
|
||||
<ul>
|
||||
<li><code>.*.swp</code></li>
|
||||
<li><code>._*</code></li>
|
||||
<li><code>.DS_Store</code></li>
|
||||
<li><code>.git</code></li>
|
||||
<li><code>.hg</code></li>
|
||||
<li><code>.npmrc</code></li>
|
||||
<li><code>.lock-wscript</code></li>
|
||||
<li><code>.svn</code></li>
|
||||
<li><code>.wafpickle-*</code></li>
|
||||
<li><code>config.gypi</code></li>
|
||||
<li><code>CVS</code></li>
|
||||
<li><code>npm-debug.log</code></li>
|
||||
</ul>
|
||||
<p>Additionally, everything in <code>node_modules</code> is ignored, except for
|
||||
bundled dependencies. npm automatically handles this for you, so don't
|
||||
bother adding <code>node_modules</code> to <code>.npmignore</code>.</p>
|
||||
<p>The following paths and files are never ignored, so adding them to
|
||||
<code>.npmignore</code> is pointless:</p>
|
||||
<ul>
|
||||
<li><code>package.json</code></li>
|
||||
<li><code><a href="../../doc/README.html">README</a></code> (and its variants)</li>
|
||||
<li><code>CHANGELOG</code> (and its variants)</li>
|
||||
<li><code>LICENSE</code> / <code>LICENCE</code></li>
|
||||
</ul>
|
||||
<h2 id="link-packages">Link Packages</h2>
|
||||
<p><code>npm link</code> 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 <code>npm rebuild -g</code> to update compiled packages,
|
||||
of course.)</p>
|
||||
<p>More info at <code><a href="../cli/npm-link.html">npm-link(1)</a></code>.</p>
|
||||
<h2 id="before-publishing-make-sure-your-package-installs-and-works">Before Publishing: Make Sure Your Package Installs and Works</h2>
|
||||
<p><strong>This is important.</strong></p>
|
||||
<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>
|
||||
<p>In the root of your package, do this:</p>
|
||||
<pre><code>npm install . -g
|
||||
</code></pre><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:</p>
|
||||
<pre><code>npm link
|
||||
</code></pre><p>Use <code>npm ls -g</code> to see if it's there.</p>
|
||||
<p>To test a local install, go into some other folder, and then do:</p>
|
||||
<pre><code>cd ../some-other-folder
|
||||
npm install ../my-package
|
||||
</code></pre><p>to install it locally into the node_modules folder in that other place.</p>
|
||||
<p>Then go into the node-repl, and try using require("my-thing") to
|
||||
bring in your module's main module.</p>
|
||||
<h2 id="create-a-user-account">Create a User Account</h2>
|
||||
<p>Create a user with the adduser command. It works like this:</p>
|
||||
<pre><code>npm adduser
|
||||
</code></pre><p>and then follow the prompts.</p>
|
||||
<p>This is documented better in <a href="../cli/npm-adduser.html">npm-adduser(1)</a>.</p>
|
||||
<h2 id="publish-your-package">Publish your package</h2>
|
||||
<p>This part's easy. In the root of your folder, do this:</p>
|
||||
<pre><code>npm publish
|
||||
</code></pre><p>You can give publish a url to a tarball, or a filename of a tarball,
|
||||
or a path to a folder.</p>
|
||||
<p>Note that pretty much <strong>everything in that folder will be exposed</strong>
|
||||
by default. So, if you have secret stuff in there, use a
|
||||
<code>.npmignore</code> file to list out the globs to ignore, or publish
|
||||
from a fresh checkout.</p>
|
||||
<h2 id="brag-about-it">Brag about it</h2>
|
||||
<p>Send emails, write blogs, blab in IRC.</p>
|
||||
<p>Tell the world how easy it is to install your program!</p>
|
||||
<h2 id="see-also">SEE ALSO</h2>
|
||||
<ul>
|
||||
<li><a href="../misc/npm-faq.html">npm-faq(7)</a></li>
|
||||
<li><a href="../cli/npm.html">npm(1)</a></li>
|
||||
<li><a href="../cli/npm-init.html">npm-init(1)</a></li>
|
||||
<li><a href="../files/package.json.html">package.json(5)</a></li>
|
||||
<li><a href="../misc/npm-scripts.html">npm-scripts(7)</a></li>
|
||||
<li><a href="../cli/npm-publish.html">npm-publish(1)</a></li>
|
||||
<li><a href="../cli/npm-adduser.html">npm-adduser(1)</a></li>
|
||||
<li><a href="../misc/npm-registry.html">npm-registry(7)</a></li>
|
||||
</ul>
|
||||
|
||||
</div>
|
||||
|
||||
<table border=0 cellspacing=0 cellpadding=0 id=npmlogo>
|
||||
<tr><td style="width:180px;height:10px;background:rgb(237,127,127)" colspan=18> </td></tr>
|
||||
<tr><td rowspan=4 style="width:10px;height:10px;background:rgb(237,127,127)"> </td><td style="width:40px;height:10px;background:#fff" colspan=4> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=4> </td><td style="width:40px;height:10px;background:#fff" colspan=4> </td><td rowspan=4 style="width:10px;height:10px;background:rgb(237,127,127)"> </td><td colspan=6 style="width:60px;height:10px;background:#fff"> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=4> </td></tr>
|
||||
<tr><td colspan=2 style="width:20px;height:30px;background:#fff" rowspan=3> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:20px;height:10px;background:#fff" rowspan=4 colspan=2> </td><td style="width:10px;height:20px;background:rgb(237,127,127)" rowspan=2> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:20px;height:10px;background:#fff" rowspan=3 colspan=2> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td></tr>
|
||||
<tr><td style="width:10px;height:10px;background:#fff" rowspan=2> </td></tr>
|
||||
<tr><td style="width:10px;height:10px;background:#fff"> </td></tr>
|
||||
<tr><td style="width:60px;height:10px;background:rgb(237,127,127)" colspan=6> </td><td colspan=10 style="width:10px;height:10px;background:rgb(237,127,127)"> </td></tr>
|
||||
<tr><td colspan=5 style="width:50px;height:10px;background:#fff"> </td><td style="width:40px;height:10px;background:rgb(237,127,127)" colspan=4> </td><td style="width:90px;height:10px;background:#fff" colspan=9> </td></tr>
|
||||
</table>
|
||||
<p id="footer">npm-developers — npm@2.15.12</p>
|
||||
|
||||
116
node_modules/npm/html/doc/misc/npm-disputes.html
generated
vendored
Normal file
116
node_modules/npm/html/doc/misc/npm-disputes.html
generated
vendored
Normal file
@@ -0,0 +1,116 @@
|
||||
<!doctype html>
|
||||
<html>
|
||||
<title>npm-disputes</title>
|
||||
<meta charset="utf-8">
|
||||
<link rel="stylesheet" type="text/css" href="../../static/style.css">
|
||||
<link rel="canonical" href="https://www.npmjs.org/doc/misc/npm-disputes.html">
|
||||
<script async=true src="../../static/toc.js"></script>
|
||||
|
||||
<body>
|
||||
<div id="wrapper">
|
||||
|
||||
<h1><a href="../misc/npm-disputes.html">npm-disputes</a></h1> <p>Handling Module Name Disputes</p>
|
||||
<h2 id="synopsis">SYNOPSIS</h2>
|
||||
<ol>
|
||||
<li>Get the author email with <code>npm owner ls <pkgname></code></li>
|
||||
<li>Email the author, CC <a href="mailto:support@npmjs.com">support@npmjs.com</a></li>
|
||||
<li>After a few weeks, if there's no resolution, we'll sort it out.</li>
|
||||
</ol>
|
||||
<p>Don't squat on package names. Publish code or move out of the way.</p>
|
||||
<h2 id="description">DESCRIPTION</h2>
|
||||
<p>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.)</p>
|
||||
<ol>
|
||||
<li>Joe writes a JavaScript module <code>foo</code>, which is not node-specific.
|
||||
Joe doesn't use node at all. Bob wants to use <code>foo</code> 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.</li>
|
||||
<li>Bob writes an npm module <code>foo</code>, and publishes it. Perhaps much
|
||||
later, Joe finds a bug in <code>foo</code>, 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 <code>foo</code>, but can't, because the name is
|
||||
taken.</li>
|
||||
<li>Bob writes a 10-line flow-control library, and calls it <code>foo</code>, 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 <code>foo</code> JavaScript
|
||||
toolkit framework. They publish it to npm as <code>foojs</code>, but people are
|
||||
routinely confused when <code>npm install foo</code> is some different thing.</li>
|
||||
<li>Bob writes a parser for the widely-known <code>foo</code> 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 <code>foo</code> parser,
|
||||
but can't publish, because Bob's <code>foo</code> is in the way.</li>
|
||||
</ol>
|
||||
<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.</p>
|
||||
<ol>
|
||||
<li><code>npm owner ls foo</code>. This will tell Joe the email address of the
|
||||
owner (Bob).</li>
|
||||
<li>Joe emails Bob, explaining the situation <strong>as respectfully as
|
||||
possible</strong>, and what he would like to do with the module name. He
|
||||
adds the npm support staff <a href="mailto:support@npmjs.com">support@npmjs.com</a> to the CC list of
|
||||
the email. Mention in the email that Bob can run <code>npm owner add
|
||||
joe foo</code> to add Joe as an owner of the <code>foo</code> package.</li>
|
||||
<li>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 support
|
||||
<a href="mailto:support@npmjs.com">support@npmjs.com</a> and we'll sort it out. ("Reasonable" is
|
||||
usually at least 4 weeks, but extra time is allowed around common
|
||||
holidays.)</li>
|
||||
</ol>
|
||||
<h2 id="reasoning">REASONING</h2>
|
||||
<p>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>
|
||||
<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.</p>
|
||||
<h2 id="exceptions">EXCEPTIONS</h2>
|
||||
<p>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:</p>
|
||||
<ol>
|
||||
<li>Malware (that is, a package designed to exploit or harm the machine on
|
||||
which it is installed).</li>
|
||||
<li>Violations of copyright or licenses (for example, cloning an
|
||||
MIT-licensed program, and then removing or changing the copyright and
|
||||
license statement).</li>
|
||||
<li>Illegal content.</li>
|
||||
<li>"Squatting" on a package name that you <em>plan</em> 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.</li>
|
||||
<li>Putting empty packages in the registry. Packages must have SOME
|
||||
functionality. It can be silly, but it can't be <em>nothing</em>. (See
|
||||
also: squatting.)</li>
|
||||
<li>Doing weird things with the registry, like using it as your own
|
||||
personal application database or otherwise putting non-packagey
|
||||
things into it.</li>
|
||||
</ol>
|
||||
<p>If you see bad behavior like this, please report it right away.</p>
|
||||
<h2 id="see-also">SEE ALSO</h2>
|
||||
<ul>
|
||||
<li><a href="../misc/npm-registry.html">npm-registry(7)</a></li>
|
||||
<li><a href="../cli/npm-owner.html">npm-owner(1)</a></li>
|
||||
</ul>
|
||||
|
||||
</div>
|
||||
|
||||
<table border=0 cellspacing=0 cellpadding=0 id=npmlogo>
|
||||
<tr><td style="width:180px;height:10px;background:rgb(237,127,127)" colspan=18> </td></tr>
|
||||
<tr><td rowspan=4 style="width:10px;height:10px;background:rgb(237,127,127)"> </td><td style="width:40px;height:10px;background:#fff" colspan=4> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=4> </td><td style="width:40px;height:10px;background:#fff" colspan=4> </td><td rowspan=4 style="width:10px;height:10px;background:rgb(237,127,127)"> </td><td colspan=6 style="width:60px;height:10px;background:#fff"> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=4> </td></tr>
|
||||
<tr><td colspan=2 style="width:20px;height:30px;background:#fff" rowspan=3> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:20px;height:10px;background:#fff" rowspan=4 colspan=2> </td><td style="width:10px;height:20px;background:rgb(237,127,127)" rowspan=2> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:20px;height:10px;background:#fff" rowspan=3 colspan=2> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td></tr>
|
||||
<tr><td style="width:10px;height:10px;background:#fff" rowspan=2> </td></tr>
|
||||
<tr><td style="width:10px;height:10px;background:#fff"> </td></tr>
|
||||
<tr><td style="width:60px;height:10px;background:rgb(237,127,127)" colspan=6> </td><td colspan=10 style="width:10px;height:10px;background:rgb(237,127,127)"> </td></tr>
|
||||
<tr><td colspan=5 style="width:50px;height:10px;background:#fff"> </td><td style="width:40px;height:10px;background:rgb(237,127,127)" colspan=4> </td><td style="width:90px;height:10px;background:#fff" colspan=9> </td></tr>
|
||||
</table>
|
||||
<p id="footer">npm-disputes — npm@2.15.12</p>
|
||||
|
||||
246
node_modules/npm/html/doc/misc/npm-index.html
generated
vendored
Normal file
246
node_modules/npm/html/doc/misc/npm-index.html
generated
vendored
Normal file
@@ -0,0 +1,246 @@
|
||||
<!doctype html>
|
||||
<html>
|
||||
<title>npm-index</title>
|
||||
<meta charset="utf-8">
|
||||
<link rel="stylesheet" type="text/css" href="../../static/style.css">
|
||||
<link rel="canonical" href="https://www.npmjs.org/doc/misc/npm-index.html">
|
||||
<script async=true src="../../static/toc.js"></script>
|
||||
|
||||
<body>
|
||||
<div id="wrapper">
|
||||
|
||||
<h1><a href="../misc/npm-index.html">npm-index</a></h1> <p>Index of all npm documentation</p>
|
||||
<h3 id="readme-1-"><a href="../../doc/README.html">README</a></h3>
|
||||
<p>a JavaScript package manager</p>
|
||||
<h2 id="command-line-documentation">Command Line Documentation</h2>
|
||||
<p>Using npm on the command line</p>
|
||||
<h3 id="npm-1-"><a href="../cli/npm.html">npm(1)</a></h3>
|
||||
<p>javascript package manager</p>
|
||||
<h3 id="npm-access-1-"><a href="../cli/npm-access.html">npm-access(1)</a></h3>
|
||||
<p>Set access level on published packages</p>
|
||||
<h3 id="npm-adduser-1-"><a href="../cli/npm-adduser.html">npm-adduser(1)</a></h3>
|
||||
<p>Add a registry user account</p>
|
||||
<h3 id="npm-bin-1-"><a href="../cli/npm-bin.html">npm-bin(1)</a></h3>
|
||||
<p>Display npm bin folder</p>
|
||||
<h3 id="npm-bugs-1-"><a href="../cli/npm-bugs.html">npm-bugs(1)</a></h3>
|
||||
<p>Bugs for a package in a web browser maybe</p>
|
||||
<h3 id="npm-build-1-"><a href="../cli/npm-build.html">npm-build(1)</a></h3>
|
||||
<p>Build a package</p>
|
||||
<h3 id="npm-bundle-1-"><a href="../cli/npm-bundle.html">npm-bundle(1)</a></h3>
|
||||
<p>REMOVED</p>
|
||||
<h3 id="npm-cache-1-"><a href="../cli/npm-cache.html">npm-cache(1)</a></h3>
|
||||
<p>Manipulates packages cache</p>
|
||||
<h3 id="npm-completion-1-"><a href="../cli/npm-completion.html">npm-completion(1)</a></h3>
|
||||
<p>Tab Completion for npm</p>
|
||||
<h3 id="npm-config-1-"><a href="../cli/npm-config.html">npm-config(1)</a></h3>
|
||||
<p>Manage the npm configuration files</p>
|
||||
<h3 id="npm-dedupe-1-"><a href="../cli/npm-dedupe.html">npm-dedupe(1)</a></h3>
|
||||
<p>Reduce duplication</p>
|
||||
<h3 id="npm-deprecate-1-"><a href="../cli/npm-deprecate.html">npm-deprecate(1)</a></h3>
|
||||
<p>Deprecate a version of a package</p>
|
||||
<h3 id="npm-dist-tag-1-"><a href="../cli/npm-dist-tag.html">npm-dist-tag(1)</a></h3>
|
||||
<p>Modify package distribution tags</p>
|
||||
<h3 id="npm-docs-1-"><a href="../cli/npm-docs.html">npm-docs(1)</a></h3>
|
||||
<p>Docs for a package in a web browser maybe</p>
|
||||
<h3 id="npm-edit-1-"><a href="../cli/npm-edit.html">npm-edit(1)</a></h3>
|
||||
<p>Edit an installed package</p>
|
||||
<h3 id="npm-explore-1-"><a href="../cli/npm-explore.html">npm-explore(1)</a></h3>
|
||||
<p>Browse an installed package</p>
|
||||
<h3 id="npm-help-search-1-"><a href="../cli/npm-help-search.html">npm-help-search(1)</a></h3>
|
||||
<p>Search npm help documentation</p>
|
||||
<h3 id="npm-help-1-"><a href="../cli/npm-help.html">npm-help(1)</a></h3>
|
||||
<p>Get help on npm</p>
|
||||
<h3 id="npm-init-1-"><a href="../cli/npm-init.html">npm-init(1)</a></h3>
|
||||
<p>Interactively create a package.json file</p>
|
||||
<h3 id="npm-install-1-"><a href="../cli/npm-install.html">npm-install(1)</a></h3>
|
||||
<p>Install a package</p>
|
||||
<h3 id="npm-link-1-"><a href="../cli/npm-link.html">npm-link(1)</a></h3>
|
||||
<p>Symlink a package folder</p>
|
||||
<h3 id="npm-logout-1-"><a href="../cli/npm-logout.html">npm-logout(1)</a></h3>
|
||||
<p>Log out of the registry</p>
|
||||
<h3 id="npm-ls-1-"><a href="../cli/npm-ls.html">npm-ls(1)</a></h3>
|
||||
<p>List installed packages</p>
|
||||
<h3 id="npm-outdated-1-"><a href="../cli/npm-outdated.html">npm-outdated(1)</a></h3>
|
||||
<p>Check for outdated packages</p>
|
||||
<h3 id="npm-owner-1-"><a href="../cli/npm-owner.html">npm-owner(1)</a></h3>
|
||||
<p>Manage package owners</p>
|
||||
<h3 id="npm-pack-1-"><a href="../cli/npm-pack.html">npm-pack(1)</a></h3>
|
||||
<p>Create a tarball from a package</p>
|
||||
<h3 id="npm-ping-1-"><a href="../cli/npm-ping.html">npm-ping(1)</a></h3>
|
||||
<p>Ping npm registry</p>
|
||||
<h3 id="npm-prefix-1-"><a href="../cli/npm-prefix.html">npm-prefix(1)</a></h3>
|
||||
<p>Display prefix</p>
|
||||
<h3 id="npm-prune-1-"><a href="../cli/npm-prune.html">npm-prune(1)</a></h3>
|
||||
<p>Remove extraneous packages</p>
|
||||
<h3 id="npm-publish-1-"><a href="../cli/npm-publish.html">npm-publish(1)</a></h3>
|
||||
<p>Publish a package</p>
|
||||
<h3 id="npm-rebuild-1-"><a href="../cli/npm-rebuild.html">npm-rebuild(1)</a></h3>
|
||||
<p>Rebuild a package</p>
|
||||
<h3 id="npm-repo-1-"><a href="../cli/npm-repo.html">npm-repo(1)</a></h3>
|
||||
<p>Open package repository page in the browser</p>
|
||||
<h3 id="npm-restart-1-"><a href="../cli/npm-restart.html">npm-restart(1)</a></h3>
|
||||
<p>Restart a package</p>
|
||||
<h3 id="npm-rm-1-"><a href="../cli/npm-rm.html">npm-rm(1)</a></h3>
|
||||
<p>Remove a package</p>
|
||||
<h3 id="npm-root-1-"><a href="../cli/npm-root.html">npm-root(1)</a></h3>
|
||||
<p>Display npm root</p>
|
||||
<h3 id="npm-run-script-1-"><a href="../cli/npm-run-script.html">npm-run-script(1)</a></h3>
|
||||
<p>Run arbitrary package scripts</p>
|
||||
<h3 id="npm-search-1-"><a href="../cli/npm-search.html">npm-search(1)</a></h3>
|
||||
<p>Search for packages</p>
|
||||
<h3 id="npm-shrinkwrap-1-"><a href="../cli/npm-shrinkwrap.html">npm-shrinkwrap(1)</a></h3>
|
||||
<p>Lock down dependency versions</p>
|
||||
<h3 id="npm-star-1-"><a href="../cli/npm-star.html">npm-star(1)</a></h3>
|
||||
<p>Mark your favorite packages</p>
|
||||
<h3 id="npm-stars-1-"><a href="../cli/npm-stars.html">npm-stars(1)</a></h3>
|
||||
<p>View packages marked as favorites</p>
|
||||
<h3 id="npm-start-1-"><a href="../cli/npm-start.html">npm-start(1)</a></h3>
|
||||
<p>Start a package</p>
|
||||
<h3 id="npm-stop-1-"><a href="../cli/npm-stop.html">npm-stop(1)</a></h3>
|
||||
<p>Stop a package</p>
|
||||
<h3 id="npm-tag-1-"><a href="../cli/npm-tag.html">npm-tag(1)</a></h3>
|
||||
<p>Tag a published version</p>
|
||||
<h3 id="npm-team-1-"><a href="../cli/npm-team.html">npm-team(1)</a></h3>
|
||||
<p>Manage organization teams and team memberships</p>
|
||||
<h3 id="npm-test-1-"><a href="../cli/npm-test.html">npm-test(1)</a></h3>
|
||||
<p>Test a package</p>
|
||||
<h3 id="npm-uninstall-1-"><a href="../cli/npm-uninstall.html">npm-uninstall(1)</a></h3>
|
||||
<p>Remove a package</p>
|
||||
<h3 id="npm-unpublish-1-"><a href="../cli/npm-unpublish.html">npm-unpublish(1)</a></h3>
|
||||
<p>Remove a package from the registry</p>
|
||||
<h3 id="npm-update-1-"><a href="../cli/npm-update.html">npm-update(1)</a></h3>
|
||||
<p>Update a package</p>
|
||||
<h3 id="npm-version-1-"><a href="../cli/npm-version.html">npm-version(1)</a></h3>
|
||||
<p>Bump a package version</p>
|
||||
<h3 id="npm-view-1-"><a href="../cli/npm-view.html">npm-view(1)</a></h3>
|
||||
<p>View registry info</p>
|
||||
<h3 id="npm-whoami-1-"><a href="../cli/npm-whoami.html">npm-whoami(1)</a></h3>
|
||||
<p>Display npm username</p>
|
||||
<h2 id="api-documentation">API Documentation</h2>
|
||||
<p>Using npm in your Node programs</p>
|
||||
<h3 id="npm-3-"><a href="../api/npm.html">npm(3)</a></h3>
|
||||
<p>javascript package manager</p>
|
||||
<h3 id="npm-bin-3-"><a href="../api/npm-bin.html">npm-bin(3)</a></h3>
|
||||
<p>Display npm bin folder</p>
|
||||
<h3 id="npm-bugs-3-"><a href="../api/npm-bugs.html">npm-bugs(3)</a></h3>
|
||||
<p>Bugs for a package in a web browser maybe</p>
|
||||
<h3 id="npm-cache-3-"><a href="../api/npm-cache.html">npm-cache(3)</a></h3>
|
||||
<p>manage the npm cache programmatically</p>
|
||||
<h3 id="npm-commands-3-"><a href="../api/npm-commands.html">npm-commands(3)</a></h3>
|
||||
<p>npm commands</p>
|
||||
<h3 id="npm-config-3-"><a href="../api/npm-config.html">npm-config(3)</a></h3>
|
||||
<p>Manage the npm configuration files</p>
|
||||
<h3 id="npm-deprecate-3-"><a href="../api/npm-deprecate.html">npm-deprecate(3)</a></h3>
|
||||
<p>Deprecate a version of a package</p>
|
||||
<h3 id="npm-docs-3-"><a href="../api/npm-docs.html">npm-docs(3)</a></h3>
|
||||
<p>Docs for a package in a web browser maybe</p>
|
||||
<h3 id="npm-edit-3-"><a href="../api/npm-edit.html">npm-edit(3)</a></h3>
|
||||
<p>Edit an installed package</p>
|
||||
<h3 id="npm-explore-3-"><a href="../api/npm-explore.html">npm-explore(3)</a></h3>
|
||||
<p>Browse an installed package</p>
|
||||
<h3 id="npm-help-search-3-"><a href="../api/npm-help-search.html">npm-help-search(3)</a></h3>
|
||||
<p>Search the help pages</p>
|
||||
<h3 id="npm-init-3-"><a href="../api/npm-init.html">npm-init(3)</a></h3>
|
||||
<p>Interactively create a package.json file</p>
|
||||
<h3 id="npm-install-3-"><a href="../api/npm-install.html">npm-install(3)</a></h3>
|
||||
<p>install a package programmatically</p>
|
||||
<h3 id="npm-link-3-"><a href="../api/npm-link.html">npm-link(3)</a></h3>
|
||||
<p>Symlink a package folder</p>
|
||||
<h3 id="npm-load-3-"><a href="../api/npm-load.html">npm-load(3)</a></h3>
|
||||
<p>Load config settings</p>
|
||||
<h3 id="npm-ls-3-"><a href="../api/npm-ls.html">npm-ls(3)</a></h3>
|
||||
<p>List installed packages</p>
|
||||
<h3 id="npm-outdated-3-"><a href="../api/npm-outdated.html">npm-outdated(3)</a></h3>
|
||||
<p>Check for outdated packages</p>
|
||||
<h3 id="npm-owner-3-"><a href="../api/npm-owner.html">npm-owner(3)</a></h3>
|
||||
<p>Manage package owners</p>
|
||||
<h3 id="npm-pack-3-"><a href="../api/npm-pack.html">npm-pack(3)</a></h3>
|
||||
<p>Create a tarball from a package</p>
|
||||
<h3 id="npm-ping-3-"><a href="../api/npm-ping.html">npm-ping(3)</a></h3>
|
||||
<p>Ping npm registry</p>
|
||||
<h3 id="npm-prefix-3-"><a href="../api/npm-prefix.html">npm-prefix(3)</a></h3>
|
||||
<p>Display prefix</p>
|
||||
<h3 id="npm-prune-3-"><a href="../api/npm-prune.html">npm-prune(3)</a></h3>
|
||||
<p>Remove extraneous packages</p>
|
||||
<h3 id="npm-publish-3-"><a href="../api/npm-publish.html">npm-publish(3)</a></h3>
|
||||
<p>Publish a package</p>
|
||||
<h3 id="npm-rebuild-3-"><a href="../api/npm-rebuild.html">npm-rebuild(3)</a></h3>
|
||||
<p>Rebuild a package</p>
|
||||
<h3 id="npm-repo-3-"><a href="../api/npm-repo.html">npm-repo(3)</a></h3>
|
||||
<p>Open package repository page in the browser</p>
|
||||
<h3 id="npm-restart-3-"><a href="../api/npm-restart.html">npm-restart(3)</a></h3>
|
||||
<p>Restart a package</p>
|
||||
<h3 id="npm-root-3-"><a href="../api/npm-root.html">npm-root(3)</a></h3>
|
||||
<p>Display npm root</p>
|
||||
<h3 id="npm-run-script-3-"><a href="../api/npm-run-script.html">npm-run-script(3)</a></h3>
|
||||
<p>Run arbitrary package scripts</p>
|
||||
<h3 id="npm-search-3-"><a href="../api/npm-search.html">npm-search(3)</a></h3>
|
||||
<p>Search for packages</p>
|
||||
<h3 id="npm-shrinkwrap-3-"><a href="../api/npm-shrinkwrap.html">npm-shrinkwrap(3)</a></h3>
|
||||
<p>programmatically generate package shrinkwrap file</p>
|
||||
<h3 id="npm-start-3-"><a href="../api/npm-start.html">npm-start(3)</a></h3>
|
||||
<p>Start a package</p>
|
||||
<h3 id="npm-stop-3-"><a href="../api/npm-stop.html">npm-stop(3)</a></h3>
|
||||
<p>Stop a package</p>
|
||||
<h3 id="npm-tag-3-"><a href="../api/npm-tag.html">npm-tag(3)</a></h3>
|
||||
<p>Tag a published version</p>
|
||||
<h3 id="npm-test-3-"><a href="../api/npm-test.html">npm-test(3)</a></h3>
|
||||
<p>Test a package</p>
|
||||
<h3 id="npm-uninstall-3-"><a href="../api/npm-uninstall.html">npm-uninstall(3)</a></h3>
|
||||
<p>uninstall a package programmatically</p>
|
||||
<h3 id="npm-unpublish-3-"><a href="../api/npm-unpublish.html">npm-unpublish(3)</a></h3>
|
||||
<p>Remove a package from the registry</p>
|
||||
<h3 id="npm-update-3-"><a href="../api/npm-update.html">npm-update(3)</a></h3>
|
||||
<p>Update a package</p>
|
||||
<h3 id="npm-version-3-"><a href="../api/npm-version.html">npm-version(3)</a></h3>
|
||||
<p>Bump a package version</p>
|
||||
<h3 id="npm-view-3-"><a href="../api/npm-view.html">npm-view(3)</a></h3>
|
||||
<p>View registry info</p>
|
||||
<h3 id="npm-whoami-3-"><a href="../api/npm-whoami.html">npm-whoami(3)</a></h3>
|
||||
<p>Display npm username</p>
|
||||
<h2 id="files">Files</h2>
|
||||
<p>File system structures npm uses</p>
|
||||
<h3 id="npm-folders-5-"><a href="../files/npm-folders.html">npm-folders(5)</a></h3>
|
||||
<p>Folder Structures Used by npm</p>
|
||||
<h3 id="npmrc-5-"><a href="../files/npmrc.html">npmrc(5)</a></h3>
|
||||
<p>The npm config files</p>
|
||||
<h3 id="package-json-5-"><a href="../files/package.json.html">package.json(5)</a></h3>
|
||||
<p>Specifics of npm's package.json handling</p>
|
||||
<h2 id="misc">Misc</h2>
|
||||
<p>Various other bits and bobs</p>
|
||||
<h3 id="npm-coding-style-7-"><a href="../misc/npm-coding-style.html">npm-coding-style(7)</a></h3>
|
||||
<p>npm's "funny" coding style</p>
|
||||
<h3 id="npm-config-7-"><a href="../misc/npm-config.html">npm-config(7)</a></h3>
|
||||
<p>More than you probably want to know about npm configuration</p>
|
||||
<h3 id="npm-developers-7-"><a href="../misc/npm-developers.html">npm-developers(7)</a></h3>
|
||||
<p>Developer Guide</p>
|
||||
<h3 id="npm-disputes-7-"><a href="../misc/npm-disputes.html">npm-disputes(7)</a></h3>
|
||||
<p>Handling Module Name Disputes</p>
|
||||
<h3 id="npm-index-7-"><a href="../misc/npm-index.html">npm-index(7)</a></h3>
|
||||
<p>Index of all npm documentation</p>
|
||||
<h3 id="npm-orgs-7-"><a href="../misc/npm-orgs.html">npm-orgs(7)</a></h3>
|
||||
<p>Working with Teams & Orgs</p>
|
||||
<h3 id="npm-registry-7-"><a href="../misc/npm-registry.html">npm-registry(7)</a></h3>
|
||||
<p>The JavaScript Package Registry</p>
|
||||
<h3 id="npm-scope-7-"><a href="../misc/npm-scope.html">npm-scope(7)</a></h3>
|
||||
<p>Scoped packages</p>
|
||||
<h3 id="npm-scripts-7-"><a href="../misc/npm-scripts.html">npm-scripts(7)</a></h3>
|
||||
<p>How npm handles the "scripts" field</p>
|
||||
<h3 id="removing-npm-7-"><a href="../misc/removing-npm.html">removing-npm(7)</a></h3>
|
||||
<p>Cleaning the Slate</p>
|
||||
<h3 id="semver-7-"><a href="../misc/semver.html">semver(7)</a></h3>
|
||||
<p>The semantic versioner for npm</p>
|
||||
|
||||
</div>
|
||||
|
||||
<table border=0 cellspacing=0 cellpadding=0 id=npmlogo>
|
||||
<tr><td style="width:180px;height:10px;background:rgb(237,127,127)" colspan=18> </td></tr>
|
||||
<tr><td rowspan=4 style="width:10px;height:10px;background:rgb(237,127,127)"> </td><td style="width:40px;height:10px;background:#fff" colspan=4> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=4> </td><td style="width:40px;height:10px;background:#fff" colspan=4> </td><td rowspan=4 style="width:10px;height:10px;background:rgb(237,127,127)"> </td><td colspan=6 style="width:60px;height:10px;background:#fff"> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=4> </td></tr>
|
||||
<tr><td colspan=2 style="width:20px;height:30px;background:#fff" rowspan=3> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:20px;height:10px;background:#fff" rowspan=4 colspan=2> </td><td style="width:10px;height:20px;background:rgb(237,127,127)" rowspan=2> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:20px;height:10px;background:#fff" rowspan=3 colspan=2> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td></tr>
|
||||
<tr><td style="width:10px;height:10px;background:#fff" rowspan=2> </td></tr>
|
||||
<tr><td style="width:10px;height:10px;background:#fff"> </td></tr>
|
||||
<tr><td style="width:60px;height:10px;background:rgb(237,127,127)" colspan=6> </td><td colspan=10 style="width:10px;height:10px;background:rgb(237,127,127)"> </td></tr>
|
||||
<tr><td colspan=5 style="width:50px;height:10px;background:#fff"> </td><td style="width:40px;height:10px;background:rgb(237,127,127)" colspan=4> </td><td style="width:90px;height:10px;background:#fff" colspan=9> </td></tr>
|
||||
</table>
|
||||
<p id="footer">npm-index — npm@2.15.12</p>
|
||||
|
||||
90
node_modules/npm/html/doc/misc/npm-orgs.html
generated
vendored
Normal file
90
node_modules/npm/html/doc/misc/npm-orgs.html
generated
vendored
Normal file
@@ -0,0 +1,90 @@
|
||||
<!doctype html>
|
||||
<html>
|
||||
<title>npm-orgs</title>
|
||||
<meta charset="utf-8">
|
||||
<link rel="stylesheet" type="text/css" href="../../static/style.css">
|
||||
<link rel="canonical" href="https://www.npmjs.org/doc/misc/npm-orgs.html">
|
||||
<script async=true src="../../static/toc.js"></script>
|
||||
|
||||
<body>
|
||||
<div id="wrapper">
|
||||
|
||||
<h1><a href="../misc/npm-orgs.html">npm-orgs</a></h1> <p>Working with Teams & Orgs</p>
|
||||
<h2 id="description">DESCRIPTION</h2>
|
||||
<p>There are three levels of org users:</p>
|
||||
<ol>
|
||||
<li>Super admin, controls billing & adding people to the org.</li>
|
||||
<li>Team admin, manages team membership & package access.</li>
|
||||
<li>Developer, works on packages they are given access to. </li>
|
||||
</ol>
|
||||
<p>The super admin is the only person who can add users to the org because it impacts the monthly bill. The super admin will use the website to manage membership. Every org has a <code>developers</code> team that all users are automatically added to.</p>
|
||||
<p>The team admin is the person who manages team creation, team membership, and package access for teams. The team admin grants package access to teams, not individuals.</p>
|
||||
<p>The developer will be able to access packages based on the teams they are on. Access is either read-write or read-only.</p>
|
||||
<p>There are two main commands:</p>
|
||||
<ol>
|
||||
<li><code>npm team</code> see <a href="../cli/npm-team.html">npm-team(1)</a> for more details</li>
|
||||
<li><code>npm access</code> see <a href="../cli/npm-access.html">npm-access(1)</a> for more details</li>
|
||||
</ol>
|
||||
<h2 id="team-admins-create-teams">Team Admins create teams</h2>
|
||||
<ul>
|
||||
<li>Check who you’ve added to your org:</li>
|
||||
</ul>
|
||||
<pre><code>npm team ls <org>:developers
|
||||
</code></pre><ul>
|
||||
<li><p>Each org is automatically given a <code>developers</code> team, so you can see the whole list of team members in your org. This team automatically gets read-write access to all packages, but you can change that with the <code>access</code> command.</p>
|
||||
</li>
|
||||
<li><p>Create a new team:</p>
|
||||
</li>
|
||||
</ul>
|
||||
<pre><code>npm team create <org:team>
|
||||
</code></pre><ul>
|
||||
<li>Add members to that team:</li>
|
||||
</ul>
|
||||
<pre><code>npm team add <org:team> <user>
|
||||
</code></pre><h2 id="publish-a-package-and-adjust-package-access">Publish a package and adjust package access</h2>
|
||||
<ul>
|
||||
<li>In package directory, run</li>
|
||||
</ul>
|
||||
<pre><code>npm init --scope=<org>
|
||||
</code></pre><p>to scope it for your org & publish as usual</p>
|
||||
<ul>
|
||||
<li>Grant access: </li>
|
||||
</ul>
|
||||
<pre><code>npm access grant <read-only|read-write> <org:team> [<package>]
|
||||
</code></pre><ul>
|
||||
<li>Revoke access:</li>
|
||||
</ul>
|
||||
<pre><code>npm access revoke <org:team> [<package>]
|
||||
</code></pre><h2 id="monitor-your-package-access">Monitor your package access</h2>
|
||||
<ul>
|
||||
<li>See what org packages a team member can access:</li>
|
||||
</ul>
|
||||
<pre><code>npm access ls-packages <org> <user>
|
||||
</code></pre><ul>
|
||||
<li>See packages available to a specific team:</li>
|
||||
</ul>
|
||||
<pre><code>npm access ls-packages <org:team>
|
||||
</code></pre><ul>
|
||||
<li>Check which teams are collaborating on a package:</li>
|
||||
</ul>
|
||||
<pre><code>npm access ls-collaborators <pkg>
|
||||
</code></pre><h2 id="see-also">SEE ALSO</h2>
|
||||
<ul>
|
||||
<li><a href="../cli/npm-team.html">npm-team(1)</a></li>
|
||||
<li><a href="../cli/npm-access.html">npm-access(1)</a></li>
|
||||
<li><a href="../misc/npm-scope.html">npm-scope(7)</a></li>
|
||||
</ul>
|
||||
|
||||
</div>
|
||||
|
||||
<table border=0 cellspacing=0 cellpadding=0 id=npmlogo>
|
||||
<tr><td style="width:180px;height:10px;background:rgb(237,127,127)" colspan=18> </td></tr>
|
||||
<tr><td rowspan=4 style="width:10px;height:10px;background:rgb(237,127,127)"> </td><td style="width:40px;height:10px;background:#fff" colspan=4> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=4> </td><td style="width:40px;height:10px;background:#fff" colspan=4> </td><td rowspan=4 style="width:10px;height:10px;background:rgb(237,127,127)"> </td><td colspan=6 style="width:60px;height:10px;background:#fff"> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=4> </td></tr>
|
||||
<tr><td colspan=2 style="width:20px;height:30px;background:#fff" rowspan=3> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:20px;height:10px;background:#fff" rowspan=4 colspan=2> </td><td style="width:10px;height:20px;background:rgb(237,127,127)" rowspan=2> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:20px;height:10px;background:#fff" rowspan=3 colspan=2> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td></tr>
|
||||
<tr><td style="width:10px;height:10px;background:#fff" rowspan=2> </td></tr>
|
||||
<tr><td style="width:10px;height:10px;background:#fff"> </td></tr>
|
||||
<tr><td style="width:60px;height:10px;background:rgb(237,127,127)" colspan=6> </td><td colspan=10 style="width:10px;height:10px;background:rgb(237,127,127)"> </td></tr>
|
||||
<tr><td colspan=5 style="width:50px;height:10px;background:#fff"> </td><td style="width:40px;height:10px;background:rgb(237,127,127)" colspan=4> </td><td style="width:90px;height:10px;background:#fff" colspan=9> </td></tr>
|
||||
</table>
|
||||
<p id="footer">npm-orgs — npm@2.15.12</p>
|
||||
|
||||
74
node_modules/npm/html/doc/misc/npm-registry.html
generated
vendored
Normal file
74
node_modules/npm/html/doc/misc/npm-registry.html
generated
vendored
Normal file
@@ -0,0 +1,74 @@
|
||||
<!doctype html>
|
||||
<html>
|
||||
<title>npm-registry</title>
|
||||
<meta charset="utf-8">
|
||||
<link rel="stylesheet" type="text/css" href="../../static/style.css">
|
||||
<link rel="canonical" href="https://www.npmjs.org/doc/misc/npm-registry.html">
|
||||
<script async=true src="../../static/toc.js"></script>
|
||||
|
||||
<body>
|
||||
<div id="wrapper">
|
||||
|
||||
<h1><a href="../misc/npm-registry.html">npm-registry</a></h1> <p>The JavaScript Package Registry</p>
|
||||
<h2 id="description">DESCRIPTION</h2>
|
||||
<p>To resolve packages by name and version, npm talks to a registry website
|
||||
that implements the CommonJS Package Registry specification for reading
|
||||
package info.</p>
|
||||
<p>Additionally, npm's package registry implementation supports several
|
||||
write APIs as well, to allow for publishing packages and managing user
|
||||
account information.</p>
|
||||
<p>The official public npm registry is at <a href="https://registry.npmjs.org/">https://registry.npmjs.org/</a>. It
|
||||
is powered by a CouchDB database, of which there is a public mirror at
|
||||
<a href="https://skimdb.npmjs.com/registry">https://skimdb.npmjs.com/registry</a>. The code for the couchapp is
|
||||
available at <a href="https://github.com/npm/npm-registry-couchapp">https://github.com/npm/npm-registry-couchapp</a>.</p>
|
||||
<p>The registry URL used is determined by the scope of the package (see
|
||||
<code><a href="../misc/npm-scope.html">npm-scope(7)</a></code>). If no scope is specified, the default registry is used, which is
|
||||
supplied by the <code>registry</code> config parameter. See <code><a href="../cli/npm-config.html">npm-config(1)</a></code>,
|
||||
<code><a href="../files/npmrc.html">npmrc(5)</a></code>, and <code><a href="../misc/npm-config.html">npm-config(7)</a></code> for more on managing npm's configuration.</p>
|
||||
<h2 id="can-i-run-my-own-private-registry-">Can I run my own private registry?</h2>
|
||||
<p>Yes!</p>
|
||||
<p>The easiest way is to replicate the couch database, and use the same (or
|
||||
similar) design doc to implement the APIs.</p>
|
||||
<p>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. </p>
|
||||
<p>If you then want to publish a package for the whole world to see, you can
|
||||
simply override the <code>--registry</code> option for that <code>publish</code> command.</p>
|
||||
<h2 id="i-don-t-want-my-package-published-in-the-official-registry-it-s-private-">I don't want my package published in the official registry. It's private.</h2>
|
||||
<p>Set <code>"private": true</code> in your package.json to prevent it from being
|
||||
published at all, or
|
||||
<code>"publishConfig":{"registry":"http://my-internal-registry.local"}</code>
|
||||
to force it to be published only to your internal registry.</p>
|
||||
<p>See <code><a href="../files/package.json.html">package.json(5)</a></code> for more info on what goes in the package.json file.</p>
|
||||
<h2 id="will-you-replicate-from-my-registry-into-the-public-one-">Will you replicate from my registry into the public one?</h2>
|
||||
<p>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.</p>
|
||||
<h2 id="do-i-have-to-use-couchdb-to-build-a-registry-that-npm-can-talk-to-">Do I have to use couchdb to build a registry that npm can talk to?</h2>
|
||||
<p>No, but it's way easier. Basically, yes, you do, or you have to
|
||||
effectively implement the entire CouchDB API anyway.</p>
|
||||
<h2 id="is-there-a-website-or-something-to-see-package-docs-and-such-">Is there a website or something to see package docs and such?</h2>
|
||||
<p>Yes, head over to <a href="https://npmjs.com/">https://npmjs.com/</a></p>
|
||||
<h2 id="see-also">SEE ALSO</h2>
|
||||
<ul>
|
||||
<li><a href="../cli/npm-config.html">npm-config(1)</a></li>
|
||||
<li><a href="../misc/npm-config.html">npm-config(7)</a></li>
|
||||
<li><a href="../files/npmrc.html">npmrc(5)</a></li>
|
||||
<li><a href="../misc/npm-developers.html">npm-developers(7)</a></li>
|
||||
<li><a href="../misc/npm-disputes.html">npm-disputes(7)</a></li>
|
||||
</ul>
|
||||
|
||||
</div>
|
||||
|
||||
<table border=0 cellspacing=0 cellpadding=0 id=npmlogo>
|
||||
<tr><td style="width:180px;height:10px;background:rgb(237,127,127)" colspan=18> </td></tr>
|
||||
<tr><td rowspan=4 style="width:10px;height:10px;background:rgb(237,127,127)"> </td><td style="width:40px;height:10px;background:#fff" colspan=4> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=4> </td><td style="width:40px;height:10px;background:#fff" colspan=4> </td><td rowspan=4 style="width:10px;height:10px;background:rgb(237,127,127)"> </td><td colspan=6 style="width:60px;height:10px;background:#fff"> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=4> </td></tr>
|
||||
<tr><td colspan=2 style="width:20px;height:30px;background:#fff" rowspan=3> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:20px;height:10px;background:#fff" rowspan=4 colspan=2> </td><td style="width:10px;height:20px;background:rgb(237,127,127)" rowspan=2> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:20px;height:10px;background:#fff" rowspan=3 colspan=2> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td></tr>
|
||||
<tr><td style="width:10px;height:10px;background:#fff" rowspan=2> </td></tr>
|
||||
<tr><td style="width:10px;height:10px;background:#fff"> </td></tr>
|
||||
<tr><td style="width:60px;height:10px;background:rgb(237,127,127)" colspan=6> </td><td colspan=10 style="width:10px;height:10px;background:rgb(237,127,127)"> </td></tr>
|
||||
<tr><td colspan=5 style="width:50px;height:10px;background:#fff"> </td><td style="width:40px;height:10px;background:rgb(237,127,127)" colspan=4> </td><td style="width:90px;height:10px;background:#fff" colspan=9> </td></tr>
|
||||
</table>
|
||||
<p id="footer">npm-registry — npm@2.15.12</p>
|
||||
|
||||
98
node_modules/npm/html/doc/misc/npm-scope.html
generated
vendored
Normal file
98
node_modules/npm/html/doc/misc/npm-scope.html
generated
vendored
Normal file
@@ -0,0 +1,98 @@
|
||||
<!doctype html>
|
||||
<html>
|
||||
<title>npm-scope</title>
|
||||
<meta charset="utf-8">
|
||||
<link rel="stylesheet" type="text/css" href="../../static/style.css">
|
||||
<link rel="canonical" href="https://www.npmjs.org/doc/misc/npm-scope.html">
|
||||
<script async=true src="../../static/toc.js"></script>
|
||||
|
||||
<body>
|
||||
<div id="wrapper">
|
||||
|
||||
<h1><a href="../misc/npm-scope.html">npm-scope</a></h1> <p>Scoped packages</p>
|
||||
<h2 id="description">DESCRIPTION</h2>
|
||||
<p>All npm packages have a name. Some package names also have a scope. A scope
|
||||
follows the usual rules for package names (url-safe characters, no leading dots
|
||||
or underscores). When used in package names, preceded by an @-symbol and
|
||||
followed by a slash, e.g.</p>
|
||||
<pre><code>@somescope/somepackagename
|
||||
</code></pre><p>Scopes are a way of grouping related packages together, and also affect a few
|
||||
things about the way npm treats the package.</p>
|
||||
<p>Scoped packages can be published and installed as of <code>npm@2</code> and are supported
|
||||
by the primary npm registry. The npm client is backwards-compatible with
|
||||
un-scoped registries, so it can be used to work with scoped and un-scoped
|
||||
registries at the same time.</p>
|
||||
<h2 id="installing-scoped-packages">Installing scoped packages</h2>
|
||||
<p>Scoped packages are installed to a sub-folder of the regular installation
|
||||
folder, e.g. if your other packages are installed in <code>node_modules/packagename</code>,
|
||||
scoped modules will be in <code>node_modules/@myorg/packagename</code>. The scope folder
|
||||
(<code>@myorg</code>) is simply the name of the scope preceded by an @-symbol, and can
|
||||
contain any number of scoped packages.</p>
|
||||
<p>A scoped package is installed by referencing it by name, preceded by an
|
||||
@-symbol, in <code>npm install</code>:</p>
|
||||
<pre><code>npm install @myorg/mypackage
|
||||
</code></pre><p>Or in <code>package.json</code>:</p>
|
||||
<pre><code>"dependencies": {
|
||||
"@myorg/mypackage": "^1.3.0"
|
||||
}
|
||||
</code></pre><p>Note that if the @-symbol is omitted in either case npm will instead attempt to
|
||||
install from GitHub; see <code><a href="../cli/npm-install.html">npm-install(1)</a></code>.</p>
|
||||
<h2 id="requiring-scoped-packages">Requiring scoped packages</h2>
|
||||
<p>Because scoped packages are installed into a scope folder, you have to
|
||||
include the name of the scope when requiring them in your code, e.g.</p>
|
||||
<pre><code>require('@myorg/mypackage')
|
||||
</code></pre><p>There is nothing special about the way Node treats scope folders, this is
|
||||
just specifying to require the module <code>mypackage</code> in the folder called <code>@myorg</code>.</p>
|
||||
<h2 id="publishing-scoped-packages">Publishing scoped packages</h2>
|
||||
<p>Scoped packages can be published from the CLI as of <code>npm@2</code> and can be
|
||||
published to any registry that supports them, including the primary npm
|
||||
registry.</p>
|
||||
<p>(As of 2015-04-19, and with npm 2.0 or newer, the primary npm registry <strong>does</strong>
|
||||
support scoped packages)</p>
|
||||
<p>If you wish, you may associate a scope with a registry; see below.</p>
|
||||
<h3 id="publishing-public-scoped-packages-to-the-primary-npm-registry">Publishing public scoped packages to the primary npm registry</h3>
|
||||
<p>To publish a public scoped package, you must specify <code>--access public</code> with
|
||||
the initial publication. This will publish the package and set access
|
||||
to <code>public</code> as if you had run <code>npm access public</code> after publishing.</p>
|
||||
<h3 id="publishing-private-scoped-packages-to-the-npm-registry">Publishing private scoped packages to the npm registry</h3>
|
||||
<p>To publish a private scoped package to the npm registry, you must have
|
||||
an <a href="https://www.npmjs.com/private-modules">npm Private Modules</a>
|
||||
account.</p>
|
||||
<p>You can then publish the module with <code>npm publish</code> or <code>npm publish
|
||||
--access restricted</code>, and it will be present in the npm registry, with
|
||||
restricted access. You can then change the access permissions, if
|
||||
desired, with <code>npm access</code> or on the npmjs.com website.</p>
|
||||
<h2 id="associating-a-scope-with-a-registry">Associating a scope with a registry</h2>
|
||||
<p>Scopes can be associated with a separate registry. This allows you to
|
||||
seamlessly use a mix of packages from the primary npm registry and one or more
|
||||
private registries, such as npm Enterprise.</p>
|
||||
<p>You can associate a scope with a registry at login, e.g.</p>
|
||||
<pre><code>npm login --registry=http://reg.example.com --scope=@myco
|
||||
</code></pre><p>Scopes have a many-to-one relationship with registries: one registry can
|
||||
host multiple scopes, but a scope only ever points to one registry.</p>
|
||||
<p>You can also associate a scope with a registry using <code>npm config</code>:</p>
|
||||
<pre><code>npm config set @myco:registry http://reg.example.com
|
||||
</code></pre><p>Once a scope is associated with a registry, any <code>npm install</code> for a package
|
||||
with that scope will request packages from that registry instead. Any
|
||||
<code>npm publish</code> for a package name that contains the scope will be published to
|
||||
that registry instead.</p>
|
||||
<h2 id="see-also">SEE ALSO</h2>
|
||||
<ul>
|
||||
<li><a href="../cli/npm-install.html">npm-install(1)</a></li>
|
||||
<li><a href="../cli/npm-publish.html">npm-publish(1)</a></li>
|
||||
<li><a href="../cli/npm-access.html">npm-access(1)</a></li>
|
||||
</ul>
|
||||
|
||||
</div>
|
||||
|
||||
<table border=0 cellspacing=0 cellpadding=0 id=npmlogo>
|
||||
<tr><td style="width:180px;height:10px;background:rgb(237,127,127)" colspan=18> </td></tr>
|
||||
<tr><td rowspan=4 style="width:10px;height:10px;background:rgb(237,127,127)"> </td><td style="width:40px;height:10px;background:#fff" colspan=4> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=4> </td><td style="width:40px;height:10px;background:#fff" colspan=4> </td><td rowspan=4 style="width:10px;height:10px;background:rgb(237,127,127)"> </td><td colspan=6 style="width:60px;height:10px;background:#fff"> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=4> </td></tr>
|
||||
<tr><td colspan=2 style="width:20px;height:30px;background:#fff" rowspan=3> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:20px;height:10px;background:#fff" rowspan=4 colspan=2> </td><td style="width:10px;height:20px;background:rgb(237,127,127)" rowspan=2> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:20px;height:10px;background:#fff" rowspan=3 colspan=2> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td></tr>
|
||||
<tr><td style="width:10px;height:10px;background:#fff" rowspan=2> </td></tr>
|
||||
<tr><td style="width:10px;height:10px;background:#fff"> </td></tr>
|
||||
<tr><td style="width:60px;height:10px;background:rgb(237,127,127)" colspan=6> </td><td colspan=10 style="width:10px;height:10px;background:rgb(237,127,127)"> </td></tr>
|
||||
<tr><td colspan=5 style="width:50px;height:10px;background:#fff"> </td><td style="width:40px;height:10px;background:rgb(237,127,127)" colspan=4> </td><td style="width:90px;height:10px;background:#fff" colspan=9> </td></tr>
|
||||
</table>
|
||||
<p id="footer">npm-scope — npm@2.15.12</p>
|
||||
|
||||
213
node_modules/npm/html/doc/misc/npm-scripts.html
generated
vendored
Normal file
213
node_modules/npm/html/doc/misc/npm-scripts.html
generated
vendored
Normal file
@@ -0,0 +1,213 @@
|
||||
<!doctype html>
|
||||
<html>
|
||||
<title>npm-scripts</title>
|
||||
<meta charset="utf-8">
|
||||
<link rel="stylesheet" type="text/css" href="../../static/style.css">
|
||||
<link rel="canonical" href="https://www.npmjs.org/doc/misc/npm-scripts.html">
|
||||
<script async=true src="../../static/toc.js"></script>
|
||||
|
||||
<body>
|
||||
<div id="wrapper">
|
||||
|
||||
<h1><a href="../misc/npm-scripts.html">npm-scripts</a></h1> <p>How npm handles the "scripts" field</p>
|
||||
<h2 id="description">DESCRIPTION</h2>
|
||||
<p>npm supports the "scripts" property of the package.json script, for the
|
||||
following scripts:</p>
|
||||
<ul>
|
||||
<li>prepublish:
|
||||
Run BEFORE the package is published. (Also run on local <code>npm
|
||||
install</code> without any arguments.)</li>
|
||||
<li>publish, postpublish:
|
||||
Run AFTER the package is published.</li>
|
||||
<li>preinstall:
|
||||
Run BEFORE the package is installed</li>
|
||||
<li>install, postinstall:
|
||||
Run AFTER the package is installed.</li>
|
||||
<li>preuninstall, uninstall:
|
||||
Run BEFORE the package is uninstalled.</li>
|
||||
<li>postuninstall:
|
||||
Run AFTER the package is uninstalled.</li>
|
||||
<li>preversion, version:
|
||||
Run BEFORE bumping the package version.</li>
|
||||
<li>postversion:
|
||||
Run AFTER bumping the package version.</li>
|
||||
<li>pretest, test, posttest:
|
||||
Run by the <code>npm test</code> command.</li>
|
||||
<li>prestop, stop, poststop:
|
||||
Run by the <code>npm stop</code> command.</li>
|
||||
<li>prestart, start, poststart:
|
||||
Run by the <code>npm start</code> command.</li>
|
||||
<li>prerestart, restart, postrestart:
|
||||
Run by the <code>npm restart</code> command. Note: <code>npm restart</code> will run the
|
||||
stop and start scripts if no <code>restart</code> script is provided.</li>
|
||||
</ul>
|
||||
<p>Additionally, arbitrary scripts can be executed by running <code>npm
|
||||
run-script <stage></code>. <em>Pre</em> and <em>post</em> commands with matching
|
||||
names will be run for those as well (e.g. <code>premyscript</code>, <code>myscript</code>,
|
||||
<code>postmyscript</code>). Scripts from dependencies can be run with `npm explore</p>
|
||||
<p><pkg> -- npm run <stage>`.</p>
|
||||
<h2 id="common-uses">COMMON USES</h2>
|
||||
<p>If you need to perform operations on your package before it is used, in a way
|
||||
that is not dependent on the operating system or architecture of the
|
||||
target system, use a <code>prepublish</code> script. This includes
|
||||
tasks such as:</p>
|
||||
<ul>
|
||||
<li>Compiling CoffeeScript source code into JavaScript.</li>
|
||||
<li>Creating minified versions of JavaScript source code.</li>
|
||||
<li>Fetching remote resources that your package will use.</li>
|
||||
</ul>
|
||||
<p>The advantage of doing these things at <code>prepublish</code> time is that they can be done once, in a
|
||||
single place, thus reducing complexity and variability.
|
||||
Additionally, this means that:</p>
|
||||
<ul>
|
||||
<li>You can depend on <code>coffee-script</code> as a <code>devDependency</code>, and thus
|
||||
your users don't need to have it installed.</li>
|
||||
<li>You don't need to include minifiers in your package, reducing
|
||||
the size for your users.</li>
|
||||
<li>You don't need to rely on your users having <code>curl</code> or <code>wget</code> or
|
||||
other system tools on the target machines.</li>
|
||||
</ul>
|
||||
<h2 id="default-values">DEFAULT VALUES</h2>
|
||||
<p>npm will default some script values based on package contents.</p>
|
||||
<ul>
|
||||
<li><p><code>"start": "node server.js"</code>:</p>
|
||||
<p>If there is a <code>server.js</code> file in the root of your package, then npm
|
||||
will default the <code>start</code> command to <code>node server.js</code>.</p>
|
||||
</li>
|
||||
<li><p><code>"install": "node-gyp rebuild"</code>:</p>
|
||||
<p>If there is a <code>binding.gyp</code> file in the root of your package and you
|
||||
haven't defined your own <code>install</code> or <code>preinstall</code> scripts, npm will
|
||||
default the <code>install</code> command to compile using node-gyp.</p>
|
||||
</li>
|
||||
</ul>
|
||||
<h2 id="user">USER</h2>
|
||||
<p>If npm was invoked with root privileges, then it will change the uid
|
||||
to the user account or uid specified by the <code>user</code> config, which
|
||||
defaults to <code>nobody</code>. Set the <code>unsafe-perm</code> flag to run scripts with
|
||||
root privileges.</p>
|
||||
<h2 id="environment">ENVIRONMENT</h2>
|
||||
<p>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.</p>
|
||||
<h3 id="path">path</h3>
|
||||
<p>If you depend on modules that define executable scripts, like test
|
||||
suites, then those executables will be added to the <code>PATH</code> for
|
||||
executing the scripts. So, if your package.json has this:</p>
|
||||
<pre><code>{ "name" : "foo"
|
||||
, "dependencies" : { "bar" : "0.1.x" }
|
||||
, "scripts": { "start" : "bar ./test" } }
|
||||
</code></pre><p>then you could run <code>npm start</code> to execute the <code>bar</code> script, which is
|
||||
exported into the <code>node_modules/.bin</code> directory on <code>npm install</code>.</p>
|
||||
<h3 id="package-json-vars">package.json vars</h3>
|
||||
<p>The package.json fields are tacked onto the <code>npm_package_</code> prefix. So,
|
||||
for instance, if you had <code>{"name":"foo", "version":"1.2.5"}</code> in your
|
||||
package.json file, then your package scripts would have the
|
||||
<code>npm_package_name</code> environment variable set to "foo", and the
|
||||
<code>npm_package_version</code> set to "1.2.5"</p>
|
||||
<h3 id="configuration">configuration</h3>
|
||||
<p>Configuration parameters are put in the environment with the
|
||||
<code>npm_config_</code> prefix. For instance, you can view the effective <code>root</code>
|
||||
config by checking the <code>npm_config_root</code> environment variable.</p>
|
||||
<h3 id="special-package-json-config-object">Special: package.json "config" object</h3>
|
||||
<p>The package.json "config" keys are overwritten in the environment if
|
||||
there is a config param of <code><name>[@<version>]:<key></code>. For example,
|
||||
if the package.json has this:</p>
|
||||
<pre><code>{ "name" : "foo"
|
||||
, "config" : { "port" : "8080" }
|
||||
, "scripts" : { "start" : "node server.js" } }
|
||||
</code></pre><p>and the server.js is this:</p>
|
||||
<pre><code>http.createServer(...).listen(process.env.npm_package_config_port)
|
||||
</code></pre><p>then the user could change the behavior by doing:</p>
|
||||
<pre><code>npm config set foo:port 80
|
||||
</code></pre><h3 id="current-lifecycle-event">current lifecycle event</h3>
|
||||
<p>Lastly, the <code>npm_lifecycle_event</code> 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.</p>
|
||||
<p>Objects are flattened following this format, so if you had
|
||||
<code>{"scripts":{"install":"foo.js"}}</code> in your package.json, then you'd
|
||||
see this in the script:</p>
|
||||
<pre><code>process.env.npm_package_scripts_install === "foo.js"
|
||||
</code></pre><h2 id="examples">EXAMPLES</h2>
|
||||
<p>For example, if your package.json contains this:</p>
|
||||
<pre><code>{ "scripts" :
|
||||
{ "install" : "scripts/install.js"
|
||||
, "postinstall" : "scripts/install.js"
|
||||
, "uninstall" : "scripts/uninstall.js"
|
||||
}
|
||||
}
|
||||
</code></pre><p>then <code>scripts/install.js</code> will be called for the install
|
||||
and post-install stages of the lifecycle, and <code>scripts/uninstall.js</code>
|
||||
will be called when the package is uninstalled. Since
|
||||
<code>scripts/install.js</code> is running for two different phases, it would
|
||||
be wise in this case to look at the <code>npm_lifecycle_event</code> environment
|
||||
variable.</p>
|
||||
<p>If you want to run a make command, you can do so. This works just
|
||||
fine:</p>
|
||||
<pre><code>{ "scripts" :
|
||||
{ "preinstall" : "./configure"
|
||||
, "install" : "make && make install"
|
||||
, "test" : "make test"
|
||||
}
|
||||
}
|
||||
</code></pre><h2 id="exiting">EXITING</h2>
|
||||
<p>Scripts are run by passing the line as a script argument to <code>sh</code>.</p>
|
||||
<p>If the script exits with a code other than 0, then this will abort the
|
||||
process.</p>
|
||||
<p>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.</p>
|
||||
<h2 id="hook-scripts">HOOK SCRIPTS</h2>
|
||||
<p>If you want to run a specific script at a specific lifecycle event for
|
||||
ALL packages, then you can use a hook script.</p>
|
||||
<p>Place an executable file at <code>node_modules/.hooks/{eventname}</code>, 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.</p>
|
||||
<p>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.</p>
|
||||
<h2 id="best-practices">BEST PRACTICES</h2>
|
||||
<ul>
|
||||
<li>Don't exit with a non-zero error code unless you <em>really</em> 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.</li>
|
||||
<li>Try not to use scripts to do what npm can do for you. Read through
|
||||
<code><a href="../files/package.json.html">package.json(5)</a></code> 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.</li>
|
||||
<li>Inspect the env to determine where to put things. For instance, if
|
||||
the <code>npm_config_binroot</code> environment variable is set to <code>/home/user/bin</code>, then
|
||||
don't try to install executables into <code>/usr/local/bin</code>. The user
|
||||
probably set it up that way for a reason.</li>
|
||||
<li>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.</li>
|
||||
<li>Don't use <code>install</code>. Use a <code>.gyp</code> file for compilation, and <code>prepublish</code>
|
||||
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 <code>install</code> or <code>preinstall</code>
|
||||
scripts is for compilation which must be done on the target architecture.</li>
|
||||
</ul>
|
||||
<h2 id="see-also">SEE ALSO</h2>
|
||||
<ul>
|
||||
<li><a href="../cli/npm-run-script.html">npm-run-script(1)</a></li>
|
||||
<li><a href="../files/package.json.html">package.json(5)</a></li>
|
||||
<li><a href="../misc/npm-developers.html">npm-developers(7)</a></li>
|
||||
<li><a href="../cli/npm-install.html">npm-install(1)</a></li>
|
||||
</ul>
|
||||
|
||||
</div>
|
||||
|
||||
<table border=0 cellspacing=0 cellpadding=0 id=npmlogo>
|
||||
<tr><td style="width:180px;height:10px;background:rgb(237,127,127)" colspan=18> </td></tr>
|
||||
<tr><td rowspan=4 style="width:10px;height:10px;background:rgb(237,127,127)"> </td><td style="width:40px;height:10px;background:#fff" colspan=4> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=4> </td><td style="width:40px;height:10px;background:#fff" colspan=4> </td><td rowspan=4 style="width:10px;height:10px;background:rgb(237,127,127)"> </td><td colspan=6 style="width:60px;height:10px;background:#fff"> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=4> </td></tr>
|
||||
<tr><td colspan=2 style="width:20px;height:30px;background:#fff" rowspan=3> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:20px;height:10px;background:#fff" rowspan=4 colspan=2> </td><td style="width:10px;height:20px;background:rgb(237,127,127)" rowspan=2> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:20px;height:10px;background:#fff" rowspan=3 colspan=2> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td></tr>
|
||||
<tr><td style="width:10px;height:10px;background:#fff" rowspan=2> </td></tr>
|
||||
<tr><td style="width:10px;height:10px;background:#fff"> </td></tr>
|
||||
<tr><td style="width:60px;height:10px;background:rgb(237,127,127)" colspan=6> </td><td colspan=10 style="width:10px;height:10px;background:rgb(237,127,127)"> </td></tr>
|
||||
<tr><td colspan=5 style="width:50px;height:10px;background:#fff"> </td><td style="width:40px;height:10px;background:rgb(237,127,127)" colspan=4> </td><td style="width:90px;height:10px;background:#fff" colspan=9> </td></tr>
|
||||
</table>
|
||||
<p id="footer">npm-scripts — npm@2.15.12</p>
|
||||
|
||||
61
node_modules/npm/html/doc/misc/removing-npm.html
generated
vendored
Normal file
61
node_modules/npm/html/doc/misc/removing-npm.html
generated
vendored
Normal file
@@ -0,0 +1,61 @@
|
||||
<!doctype html>
|
||||
<html>
|
||||
<title>removing-npm</title>
|
||||
<meta charset="utf-8">
|
||||
<link rel="stylesheet" type="text/css" href="../../static/style.css">
|
||||
<link rel="canonical" href="https://www.npmjs.org/doc/misc/removing-npm.html">
|
||||
<script async=true src="../../static/toc.js"></script>
|
||||
|
||||
<body>
|
||||
<div id="wrapper">
|
||||
|
||||
<h1><a href="../cli/npm-removal.html">npm-removal</a></h1> <p>Cleaning the Slate</p>
|
||||
<h2 id="synopsis">SYNOPSIS</h2>
|
||||
<p>So sad to see you go.</p>
|
||||
<pre><code>sudo npm uninstall npm -g
|
||||
</code></pre><p>Or, if that fails, get the npm source code, and do:</p>
|
||||
<pre><code>sudo make uninstall
|
||||
</code></pre><h2 id="more-severe-uninstalling">More Severe Uninstalling</h2>
|
||||
<p>Usually, the above instructions are sufficient. That will remove
|
||||
npm, but leave behind anything you've installed.</p>
|
||||
<p>If that doesn't work, or if you require more drastic measures,
|
||||
continue reading.</p>
|
||||
<p>Note that this is only necessary for globally-installed packages. Local
|
||||
installs are completely contained within a project's <code>node_modules</code>
|
||||
folder. Delete that folder, and everything is gone (unless a package's
|
||||
install script is particularly ill-behaved).</p>
|
||||
<p>This assumes that you installed node and npm in the default place. If
|
||||
you configured node with a different <code>--prefix</code>, or installed npm with a
|
||||
different prefix setting, then adjust the paths accordingly, replacing
|
||||
<code>/usr/local</code> with your install prefix.</p>
|
||||
<p>To remove everything npm-related manually:</p>
|
||||
<pre><code>rm -rf /usr/local/{lib/node{,/.npm,_modules},bin,share/man}/npm*
|
||||
</code></pre><p>If you installed things <em>with</em> 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:</p>
|
||||
<pre><code>ls -laF /usr/local/{lib/node{,/.npm},bin,share/man} | grep npm
|
||||
</code></pre><p>Prior to version 0.3, npm used shim files for executables and node
|
||||
modules. To track those down, you can do the following:</p>
|
||||
<pre><code>find /usr/local/{lib/node,bin} -exec grep -l npm \{\} \; ;
|
||||
</code></pre><p>(This is also in the <a href="../../doc/README.html">README</a> file.)</p>
|
||||
<h2 id="see-also">SEE ALSO</h2>
|
||||
<ul>
|
||||
<li><a href="../../doc/README.html">README</a></li>
|
||||
<li><a href="../cli/npm-uninstall.html">npm-uninstall(1)</a></li>
|
||||
<li><a href="../cli/npm-prune.html">npm-prune(1)</a></li>
|
||||
</ul>
|
||||
|
||||
</div>
|
||||
|
||||
<table border=0 cellspacing=0 cellpadding=0 id=npmlogo>
|
||||
<tr><td style="width:180px;height:10px;background:rgb(237,127,127)" colspan=18> </td></tr>
|
||||
<tr><td rowspan=4 style="width:10px;height:10px;background:rgb(237,127,127)"> </td><td style="width:40px;height:10px;background:#fff" colspan=4> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=4> </td><td style="width:40px;height:10px;background:#fff" colspan=4> </td><td rowspan=4 style="width:10px;height:10px;background:rgb(237,127,127)"> </td><td colspan=6 style="width:60px;height:10px;background:#fff"> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=4> </td></tr>
|
||||
<tr><td colspan=2 style="width:20px;height:30px;background:#fff" rowspan=3> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:20px;height:10px;background:#fff" rowspan=4 colspan=2> </td><td style="width:10px;height:20px;background:rgb(237,127,127)" rowspan=2> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:20px;height:10px;background:#fff" rowspan=3 colspan=2> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td></tr>
|
||||
<tr><td style="width:10px;height:10px;background:#fff" rowspan=2> </td></tr>
|
||||
<tr><td style="width:10px;height:10px;background:#fff"> </td></tr>
|
||||
<tr><td style="width:60px;height:10px;background:rgb(237,127,127)" colspan=6> </td><td colspan=10 style="width:10px;height:10px;background:rgb(237,127,127)"> </td></tr>
|
||||
<tr><td colspan=5 style="width:50px;height:10px;background:#fff"> </td><td style="width:40px;height:10px;background:rgb(237,127,127)" colspan=4> </td><td style="width:90px;height:10px;background:#fff" colspan=9> </td></tr>
|
||||
</table>
|
||||
<p id="footer">removing-npm — npm@2.15.12</p>
|
||||
|
||||
306
node_modules/npm/html/doc/misc/semver.html
generated
vendored
Normal file
306
node_modules/npm/html/doc/misc/semver.html
generated
vendored
Normal file
@@ -0,0 +1,306 @@
|
||||
<!doctype html>
|
||||
<html>
|
||||
<title>semver</title>
|
||||
<meta charset="utf-8">
|
||||
<link rel="stylesheet" type="text/css" href="../../static/style.css">
|
||||
<link rel="canonical" href="https://www.npmjs.org/doc/misc/semver.html">
|
||||
<script async=true src="../../static/toc.js"></script>
|
||||
|
||||
<body>
|
||||
<div id="wrapper">
|
||||
|
||||
<h1><a href="../misc/semver.html">semver</a></h1> <p>The semantic versioner for npm</p>
|
||||
<h2 id="usage">Usage</h2>
|
||||
<pre><code>$ 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
|
||||
</code></pre><p>As a command-line utility:</p>
|
||||
<pre><code>$ semver -h
|
||||
|
||||
Usage: semver <version> [<version> [...]] [-r <range> | -i <inc> | --preid <identifier> | -l | -rv]
|
||||
Test if version(s) satisfy the supplied range(s), and sort them.
|
||||
|
||||
Multiple versions or ranges may be supplied, unless increment
|
||||
option is 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.
|
||||
</code></pre><h2 id="versions">Versions</h2>
|
||||
<p>A "version" is described by the <code>v2.0.0</code> specification found at
|
||||
<a href="http://semver.org/">http://semver.org/</a>.</p>
|
||||
<p>A leading <code>"="</code> or <code>"v"</code> character is stripped off and ignored.</p>
|
||||
<h2 id="ranges">Ranges</h2>
|
||||
<p>A <code>version range</code> is a set of <code>comparators</code> which specify versions
|
||||
that satisfy the range.</p>
|
||||
<p>A <code>comparator</code> is composed of an <code>operator</code> and a <code>version</code>. The set
|
||||
of primitive <code>operators</code> is:</p>
|
||||
<ul>
|
||||
<li><code><</code> Less than</li>
|
||||
<li><code><=</code> Less than or equal to</li>
|
||||
<li><code>></code> Greater than</li>
|
||||
<li><code>>=</code> Greater than or equal to</li>
|
||||
<li><code>=</code> Equal. If no operator is specified, then equality is assumed,
|
||||
so this operator is optional, but MAY be included.</li>
|
||||
</ul>
|
||||
<p>For example, the comparator <code>>=1.2.7</code> would match the versions
|
||||
<code>1.2.7</code>, <code>1.2.8</code>, <code>2.5.3</code>, and <code>1.3.9</code>, but not the versions <code>1.2.6</code>
|
||||
or <code>1.1.0</code>.</p>
|
||||
<p>Comparators can be joined by whitespace to form a <code>comparator set</code>,
|
||||
which is satisfied by the <strong>intersection</strong> of all of the comparators
|
||||
it includes.</p>
|
||||
<p>A range is composed of one or more comparator sets, joined by <code>||</code>. A
|
||||
version matches a range if and only if every comparator in at least
|
||||
one of the <code>||</code>-separated comparator sets is satisfied by the version.</p>
|
||||
<p>For example, the range <code>>=1.2.7 <1.3.0</code> would match the versions
|
||||
<code>1.2.7</code>, <code>1.2.8</code>, and <code>1.2.99</code>, but not the versions <code>1.2.6</code>, <code>1.3.0</code>,
|
||||
or <code>1.1.0</code>.</p>
|
||||
<p>The range <code>1.2.7 || >=1.2.9 <2.0.0</code> would match the versions <code>1.2.7</code>,
|
||||
<code>1.2.9</code>, and <code>1.4.6</code>, but not the versions <code>1.2.8</code> or <code>2.0.0</code>.</p>
|
||||
<h3 id="prerelease-tags">Prerelease Tags</h3>
|
||||
<p>If a version has a prerelease tag (for example, <code>1.2.3-alpha.3</code>) then
|
||||
it will only be allowed to satisfy comparator sets if at least one
|
||||
comparator with the same <code>[major, minor, patch]</code> tuple also has a
|
||||
prerelease tag.</p>
|
||||
<p>For example, the range <code>>1.2.3-alpha.3</code> would be allowed to match the
|
||||
version <code>1.2.3-alpha.7</code>, but it would <em>not</em> be satisfied by
|
||||
<code>3.4.5-alpha.9</code>, even though <code>3.4.5-alpha.9</code> is technically "greater
|
||||
than" <code>1.2.3-alpha.3</code> according to the SemVer sort rules. The version
|
||||
range only accepts prerelease tags on the <code>1.2.3</code> version. The
|
||||
version <code>3.4.5</code> <em>would</em> satisfy the range, because it does not have a
|
||||
prerelease flag, and <code>3.4.5</code> is greater than <code>1.2.3-alpha.7</code>.</p>
|
||||
<p>The purpose for this behavior is twofold. First, prerelease versions
|
||||
frequently are updated very quickly, and contain many breaking changes
|
||||
that are (by the author's design) not yet fit for public consumption.
|
||||
Therefore, by default, they are excluded from range matching
|
||||
semantics.</p>
|
||||
<p>Second, a user who has opted into using a prerelease version has
|
||||
clearly indicated the intent to use <em>that specific</em> set of
|
||||
alpha/beta/rc versions. By including a prerelease tag in the range,
|
||||
the user is indicating that they are aware of the risk. However, it
|
||||
is still not appropriate to assume that they have opted into taking a
|
||||
similar risk on the <em>next</em> set of prerelease versions.</p>
|
||||
<h4 id="prerelease-identifiers">Prerelease Identifiers</h4>
|
||||
<p>The method <code>.inc</code> takes an additional <code>identifier</code> string argument that
|
||||
will append the value of the string as a prerelease identifier:</p>
|
||||
<pre><code class="lang-javascript">> semver.inc('1.2.3', 'prerelease', 'beta')
|
||||
'1.2.4-beta.0'
|
||||
</code></pre>
|
||||
<p>command-line example:</p>
|
||||
<pre><code class="lang-shell">$ semver 1.2.3 -i prerelease --preid beta
|
||||
1.2.4-beta.0
|
||||
</code></pre>
|
||||
<p>Which then can be used to increment further:</p>
|
||||
<pre><code class="lang-shell">$ semver 1.2.4-beta.0 -i prerelease
|
||||
1.2.4-beta.1
|
||||
</code></pre>
|
||||
<h3 id="advanced-range-syntax">Advanced Range Syntax</h3>
|
||||
<p>Advanced range syntax desugars to primitive comparators in
|
||||
deterministic ways.</p>
|
||||
<p>Advanced ranges may be combined in the same way as primitive
|
||||
comparators using white space or <code>||</code>.</p>
|
||||
<h4 id="hyphen-ranges-x-y-z-a-b-c-">Hyphen Ranges <code>X.Y.Z - A.B.C</code></h4>
|
||||
<p>Specifies an inclusive set.</p>
|
||||
<ul>
|
||||
<li><code>1.2.3 - 2.3.4</code> := <code>>=1.2.3 <=2.3.4</code></li>
|
||||
</ul>
|
||||
<p>If a partial version is provided as the first version in the inclusive
|
||||
range, then the missing pieces are replaced with zeroes.</p>
|
||||
<ul>
|
||||
<li><code>1.2 - 2.3.4</code> := <code>>=1.2.0 <=2.3.4</code></li>
|
||||
</ul>
|
||||
<p>If a partial version is provided as the second version in the
|
||||
inclusive range, then all versions that start with the supplied parts
|
||||
of the tuple are accepted, but nothing that would be greater than the
|
||||
provided tuple parts.</p>
|
||||
<ul>
|
||||
<li><code>1.2.3 - 2.3</code> := <code>>=1.2.3 <2.4.0</code></li>
|
||||
<li><code>1.2.3 - 2</code> := <code>>=1.2.3 <3.0.0</code></li>
|
||||
</ul>
|
||||
<h4 id="x-ranges-1-2-x-1-x-1-2-">X-Ranges <code>1.2.x</code> <code>1.X</code> <code>1.2.*</code> <code>*</code></h4>
|
||||
<p>Any of <code>X</code>, <code>x</code>, or <code>*</code> may be used to "stand in" for one of the
|
||||
numeric values in the <code>[major, minor, patch]</code> tuple.</p>
|
||||
<ul>
|
||||
<li><code>*</code> := <code>>=0.0.0</code> (Any version satisfies)</li>
|
||||
<li><code>1.x</code> := <code>>=1.0.0 <2.0.0</code> (Matching major version)</li>
|
||||
<li><code>1.2.x</code> := <code>>=1.2.0 <1.3.0</code> (Matching major and minor versions)</li>
|
||||
</ul>
|
||||
<p>A partial version range is treated as an X-Range, so the special
|
||||
character is in fact optional.</p>
|
||||
<ul>
|
||||
<li><code>""</code> (empty string) := <code>*</code> := <code>>=0.0.0</code></li>
|
||||
<li><code>1</code> := <code>1.x.x</code> := <code>>=1.0.0 <2.0.0</code></li>
|
||||
<li><code>1.2</code> := <code>1.2.x</code> := <code>>=1.2.0 <1.3.0</code></li>
|
||||
</ul>
|
||||
<h4 id="tilde-ranges-1-2-3-1-2-1-">Tilde Ranges <code>~1.2.3</code> <code>~1.2</code> <code>~1</code></h4>
|
||||
<p>Allows patch-level changes if a minor version is specified on the
|
||||
comparator. Allows minor-level changes if not.</p>
|
||||
<ul>
|
||||
<li><code>~1.2.3</code> := <code>>=1.2.3 <1.(2+1).0</code> := <code>>=1.2.3 <1.3.0</code></li>
|
||||
<li><code>~1.2</code> := <code>>=1.2.0 <1.(2+1).0</code> := <code>>=1.2.0 <1.3.0</code> (Same as <code>1.2.x</code>)</li>
|
||||
<li><code>~1</code> := <code>>=1.0.0 <(1+1).0.0</code> := <code>>=1.0.0 <2.0.0</code> (Same as <code>1.x</code>)</li>
|
||||
<li><code>~0.2.3</code> := <code>>=0.2.3 <0.(2+1).0</code> := <code>>=0.2.3 <0.3.0</code></li>
|
||||
<li><code>~0.2</code> := <code>>=0.2.0 <0.(2+1).0</code> := <code>>=0.2.0 <0.3.0</code> (Same as <code>0.2.x</code>)</li>
|
||||
<li><code>~0</code> := <code>>=0.0.0 <(0+1).0.0</code> := <code>>=0.0.0 <1.0.0</code> (Same as <code>0.x</code>)</li>
|
||||
<li><code>~1.2.3-beta.2</code> := <code>>=1.2.3-beta.2 <1.3.0</code> Note that prereleases in
|
||||
the <code>1.2.3</code> version will be allowed, if they are greater than or
|
||||
equal to <code>beta.2</code>. So, <code>1.2.3-beta.4</code> would be allowed, but
|
||||
<code>1.2.4-beta.2</code> would not, because it is a prerelease of a
|
||||
different <code>[major, minor, patch]</code> tuple.</li>
|
||||
</ul>
|
||||
<h4 id="caret-ranges-1-2-3-0-2-5-0-0-4-">Caret Ranges <code>^1.2.3</code> <code>^0.2.5</code> <code>^0.0.4</code></h4>
|
||||
<p>Allows changes that do not modify the left-most non-zero digit in the
|
||||
<code>[major, minor, patch]</code> tuple. In other words, this allows patch and
|
||||
minor updates for versions <code>1.0.0</code> and above, patch updates for
|
||||
versions <code>0.X >=0.1.0</code>, and <em>no</em> updates for versions <code>0.0.X</code>.</p>
|
||||
<p>Many authors treat a <code>0.x</code> version as if the <code>x</code> were the major
|
||||
"breaking-change" indicator.</p>
|
||||
<p>Caret ranges are ideal when an author may make breaking changes
|
||||
between <code>0.2.4</code> and <code>0.3.0</code> releases, which is a common practice.
|
||||
However, it presumes that there will <em>not</em> be breaking changes between
|
||||
<code>0.2.4</code> and <code>0.2.5</code>. It allows for changes that are presumed to be
|
||||
additive (but non-breaking), according to commonly observed practices.</p>
|
||||
<ul>
|
||||
<li><code>^1.2.3</code> := <code>>=1.2.3 <2.0.0</code></li>
|
||||
<li><code>^0.2.3</code> := <code>>=0.2.3 <0.3.0</code></li>
|
||||
<li><code>^0.0.3</code> := <code>>=0.0.3 <0.0.4</code></li>
|
||||
<li><code>^1.2.3-beta.2</code> := <code>>=1.2.3-beta.2 <2.0.0</code> Note that prereleases in
|
||||
the <code>1.2.3</code> version will be allowed, if they are greater than or
|
||||
equal to <code>beta.2</code>. So, <code>1.2.3-beta.4</code> would be allowed, but
|
||||
<code>1.2.4-beta.2</code> would not, because it is a prerelease of a
|
||||
different <code>[major, minor, patch]</code> tuple.</li>
|
||||
<li><code>^0.0.3-beta</code> := <code>>=0.0.3-beta <0.0.4</code> Note that prereleases in the
|
||||
<code>0.0.3</code> version <em>only</em> will be allowed, if they are greater than or
|
||||
equal to <code>beta</code>. So, <code>0.0.3-pr.2</code> would be allowed.</li>
|
||||
</ul>
|
||||
<p>When parsing caret ranges, a missing <code>patch</code> value desugars to the
|
||||
number <code>0</code>, but will allow flexibility within that value, even if the
|
||||
major and minor versions are both <code>0</code>.</p>
|
||||
<ul>
|
||||
<li><code>^1.2.x</code> := <code>>=1.2.0 <2.0.0</code></li>
|
||||
<li><code>^0.0.x</code> := <code>>=0.0.0 <0.1.0</code></li>
|
||||
<li><code>^0.0</code> := <code>>=0.0.0 <0.1.0</code></li>
|
||||
</ul>
|
||||
<p>A missing <code>minor</code> and <code>patch</code> values will desugar to zero, but also
|
||||
allow flexibility within those values, even if the major version is
|
||||
zero.</p>
|
||||
<ul>
|
||||
<li><code>^1.x</code> := <code>>=1.0.0 <2.0.0</code></li>
|
||||
<li><code>^0.x</code> := <code>>=0.0.0 <1.0.0</code></li>
|
||||
</ul>
|
||||
<h3 id="range-grammar">Range Grammar</h3>
|
||||
<p>Putting all this together, here is a Backus-Naur grammar for ranges,
|
||||
for the benefit of parser authors:</p>
|
||||
<pre><code class="lang-bnf">range-set ::= range ( logical-or range ) *
|
||||
logical-or ::= ( ' ' ) * '||' ( ' ' ) *
|
||||
range ::= hyphen | simple ( ' ' simple ) * | ''
|
||||
hyphen ::= partial ' - ' partial
|
||||
simple ::= primitive | partial | tilde | caret
|
||||
primitive ::= ( '<' | '>' | '>=' | '<=' | '=' | ) partial
|
||||
partial ::= xr ( '.' xr ( '.' xr qualifier ? )? )?
|
||||
xr ::= 'x' | 'X' | '*' | nr
|
||||
nr ::= '0' | ['1'-'9']['0'-'9']+
|
||||
tilde ::= '~' partial
|
||||
caret ::= '^' partial
|
||||
qualifier ::= ( '-' pre )? ( '+' build )?
|
||||
pre ::= parts
|
||||
build ::= parts
|
||||
parts ::= part ( '.' part ) *
|
||||
part ::= nr | [-0-9A-Za-z]+
|
||||
</code></pre>
|
||||
<h2 id="functions">Functions</h2>
|
||||
<p>All methods and classes take a final <code>loose</code> 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.</p>
|
||||
<p>Strict-mode Comparators and Ranges will be strict about the SemVer
|
||||
strings that they parse.</p>
|
||||
<ul>
|
||||
<li><code>valid(v)</code>: Return the parsed version, or null if it's not valid.</li>
|
||||
<li><code>inc(v, release)</code>: Return the version incremented by the release
|
||||
type (<code>major</code>, <code>premajor</code>, <code>minor</code>, <code>preminor</code>, <code>patch</code>,
|
||||
<code>prepatch</code>, or <code>prerelease</code>), or null if it's not valid<ul>
|
||||
<li><code>premajor</code> in one call will bump the version up to the next major
|
||||
version and down to a prerelease of that major version.
|
||||
<code>preminor</code>, and <code>prepatch</code> work the same way.</li>
|
||||
<li>If called from a non-prerelease version, the <code>prerelease</code> will work the
|
||||
same as <code>prepatch</code>. It increments the patch version, then makes a
|
||||
prerelease. If the input version is already a prerelease it simply
|
||||
increments it.</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><code>major(v)</code>: Return the major version number.</li>
|
||||
<li><code>minor(v)</code>: Return the minor version number.</li>
|
||||
<li><code>patch(v)</code>: Return the patch version number.</li>
|
||||
</ul>
|
||||
<h3 id="comparison">Comparison</h3>
|
||||
<ul>
|
||||
<li><code>gt(v1, v2)</code>: <code>v1 > v2</code></li>
|
||||
<li><code>gte(v1, v2)</code>: <code>v1 >= v2</code></li>
|
||||
<li><code>lt(v1, v2)</code>: <code>v1 < v2</code></li>
|
||||
<li><code>lte(v1, v2)</code>: <code>v1 <= v2</code></li>
|
||||
<li><code>eq(v1, v2)</code>: <code>v1 == v2</code> This is true if they're logically equivalent,
|
||||
even if they're not the exact same string. You already know how to
|
||||
compare strings.</li>
|
||||
<li><code>neq(v1, v2)</code>: <code>v1 != v2</code> The opposite of <code>eq</code>.</li>
|
||||
<li><code>cmp(v1, comparator, v2)</code>: Pass in a comparison string, and it'll call
|
||||
the corresponding function above. <code>"==="</code> and <code>"!=="</code> do simple
|
||||
string comparison, but are included for completeness. Throws if an
|
||||
invalid comparison string is provided.</li>
|
||||
<li><code>compare(v1, v2)</code>: Return <code>0</code> if <code>v1 == v2</code>, or <code>1</code> if <code>v1</code> is greater, or <code>-1</code> if
|
||||
<code>v2</code> is greater. Sorts in ascending order if passed to <code>Array.sort()</code>.</li>
|
||||
<li><code>rcompare(v1, v2)</code>: The reverse of compare. Sorts an array of versions
|
||||
in descending order when passed to <code>Array.sort()</code>.</li>
|
||||
<li><code>diff(v1, v2)</code>: Returns difference between two versions by the release type
|
||||
(<code>major</code>, <code>premajor</code>, <code>minor</code>, <code>preminor</code>, <code>patch</code>, <code>prepatch</code>, or <code>prerelease</code>),
|
||||
or null if the versions are the same.</li>
|
||||
</ul>
|
||||
<h3 id="ranges">Ranges</h3>
|
||||
<ul>
|
||||
<li><code>validRange(range)</code>: Return the valid range or null if it's not valid</li>
|
||||
<li><code>satisfies(version, range)</code>: Return true if the version satisfies the
|
||||
range.</li>
|
||||
<li><code>maxSatisfying(versions, range)</code>: Return the highest version in the list
|
||||
that satisfies the range, or <code>null</code> if none of them do.</li>
|
||||
<li><code>gtr(version, range)</code>: Return <code>true</code> if version is greater than all the
|
||||
versions possible in the range.</li>
|
||||
<li><code>ltr(version, range)</code>: Return <code>true</code> if version is less than all the
|
||||
versions possible in the range.</li>
|
||||
<li><code>outside(version, range, hilo)</code>: Return true if the version is outside
|
||||
the bounds of the range in either the high or low direction. The
|
||||
<code>hilo</code> argument must be either the string <code>'>'</code> or <code>'<'</code>. (This is
|
||||
the function called by <code>gtr</code> and <code>ltr</code>.)</li>
|
||||
</ul>
|
||||
<p>Note that, since ranges may be non-contiguous, a version might not be
|
||||
greater than a range, less than a range, <em>or</em> satisfy a range! For
|
||||
example, the range <code>1.2 <1.2.9 || >2.0.0</code> would have a hole from <code>1.2.9</code>
|
||||
until <code>2.0.0</code>, so the version <code>1.2.10</code> would not be greater than the
|
||||
range (because <code>2.0.1</code> satisfies, which is higher), nor less than the
|
||||
range (since <code>1.2.8</code> satisfies, which is lower), and it also does not
|
||||
satisfy the range.</p>
|
||||
<p>If you want to know if a version satisfies or does not satisfy a
|
||||
range, use the <code>satisfies(version, range)</code> function.</p>
|
||||
|
||||
</div>
|
||||
|
||||
<table border=0 cellspacing=0 cellpadding=0 id=npmlogo>
|
||||
<tr><td style="width:180px;height:10px;background:rgb(237,127,127)" colspan=18> </td></tr>
|
||||
<tr><td rowspan=4 style="width:10px;height:10px;background:rgb(237,127,127)"> </td><td style="width:40px;height:10px;background:#fff" colspan=4> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=4> </td><td style="width:40px;height:10px;background:#fff" colspan=4> </td><td rowspan=4 style="width:10px;height:10px;background:rgb(237,127,127)"> </td><td colspan=6 style="width:60px;height:10px;background:#fff"> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=4> </td></tr>
|
||||
<tr><td colspan=2 style="width:20px;height:30px;background:#fff" rowspan=3> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:20px;height:10px;background:#fff" rowspan=4 colspan=2> </td><td style="width:10px;height:20px;background:rgb(237,127,127)" rowspan=2> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:20px;height:10px;background:#fff" rowspan=3 colspan=2> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td><td style="width:10px;height:10px;background:#fff" rowspan=3> </td><td style="width:10px;height:10px;background:rgb(237,127,127)" rowspan=3> </td></tr>
|
||||
<tr><td style="width:10px;height:10px;background:#fff" rowspan=2> </td></tr>
|
||||
<tr><td style="width:10px;height:10px;background:#fff"> </td></tr>
|
||||
<tr><td style="width:60px;height:10px;background:rgb(237,127,127)" colspan=6> </td><td colspan=10 style="width:10px;height:10px;background:rgb(237,127,127)"> </td></tr>
|
||||
<tr><td colspan=5 style="width:50px;height:10px;background:#fff"> </td><td style="width:40px;height:10px;background:rgb(237,127,127)" colspan=4> </td><td style="width:90px;height:10px;background:#fff" colspan=9> </td></tr>
|
||||
</table>
|
||||
<p id="footer">semver — npm@2.15.12</p>
|
||||
|
||||
Reference in New Issue
Block a user