Compare commits

...

14 Commits

Author SHA1 Message Date
isaacs
c1a1ab0677 2013.06.04, Version 0.8.24 (maintenance)
* npm: Upgrade to v1.2.24

* url: Properly parse certain oddly formed urls (isaacs)

* http: Don't try to destroy nonexistent sockets (isaacs)

* handle_wrap: fix NULL pointer dereference (Ben Noordhuis)
2013-06-03 16:53:09 -07:00
isaacs
71091f78f2 npm: Upgrade to 1.2.24 2013-06-03 16:51:23 -07:00
isaacs
ba0ed00b5f url: Properly parse certain oddly formed urls
In cases where there are multiple @-chars in a url, Node currently
parses the hostname and auth sections differently than web browsers.

This part of the bug is serious, and should be landed in v0.10, and
also ported to v0.8, and releases made as soon as possible.

The less serious issue is that there are many other sorts of malformed
urls which Node either accepts when it should reject, or interprets
differently than web browsers.  For example, `http://a.com*foo` is
interpreted by Node like `http://a.com/*foo` when web browsers treat
this as `http://a.com%3Bfoo/`.

In general, *only* the `hostEndingChars` should be the characters that
delimit the host portion of the URL.  Most of the current `nonHostChars`
that appear in the hostname should be escaped, but some of them (such as
`;` and `%` when it does not introduce a hex pair) should raise an
error.

We need to have a broader discussion about whether it's best to throw in
these cases, and potentially break extant programs, or return an object
that has every field set to `null` so that any attempt to read the
hostname/auth/etc. will appear to be empty.
2013-06-03 16:29:10 -07:00
isaacs
4dc5b13861 http: Don't try to destroy nonexistent sockets
Fixes #3740

In the case of pipelined requests, you can have a situation where
the socket gets destroyed via one req/res object, but then trying
to destroy *another* req/res on the same socket will cause it to
call undefined.destroy(), since it was already removed from that
message.

Add a guard to OutgoingMessage.destroy and IncomingMessage.destroy
to prevent this error.
2013-04-22 09:56:48 -07:00
Ben Noordhuis
600cd28167 test: make stdout-close-unref work in test runner
process.stdout isn't fully initialized yet by the time the test starts
when invoked with `python tools/test.py`. Use process.stdin instead and
force initialization with process.stdin.resume().

This is a back-port of commit 2e70dda from the v0.10 branch.
2013-04-18 00:05:31 +02:00
Ben Noordhuis
0801a18890 handle_wrap: fix NULL pointer dereference
Fix a NULL pointer dereference in src/handle_wrap.cc which is really a
use-after-close bug.

The test checks that unref() after close() works on process.stdout but
this bug affects everything that derives from HandleWrap. I discovered
it because child processes would sometimes quit for no reason (that is,
no reason until I turned on core dumps.)

This is a back-port of commit ccd3722 from the v0.10 branch.
2013-04-16 23:17:50 +02:00
isaacs
49dcab933b Now working on 0.8.24 2013-04-08 17:41:26 -07:00
isaacs
b36aab16f0 Merge branch 'v0.8.23-release' into v0.8 2013-04-08 17:40:58 -07:00
isaacs
c67f8d0500 2013.04.09, Version 0.8.23 (maintenance)
* npm: Upgrade to v1.2.18

* http: Avoid EE warning on ECONNREFUSED handling (isaacs)

* tls: Re-enable check of CN-ID in cert verification (Tobias Müllerleile)

* child_process: fix sending utf-8 to child process (Ben Noordhuis)

* crypto: check key type in GetPeerCertificate() (Ben Noordhuis)

* win/openssl: mark assembled object files as seh safe (Bert Belder)

* windows/msi: fix msi build issue with WiX 3.7/3.8 (Raymond Feng)
2013-04-08 16:51:44 -07:00
isaacs
f2f893b2a7 npm: Upgrade to v1.2.18 2013-04-08 16:47:58 -07:00
isaacs
b2587b2678 http: Avoid EE warning on ECONNREFUSED handling
This is a back-port of the same fix in
deb1dc279d49463e13af44feed45c79ae0f379f9, for v0.8.
2013-04-08 16:25:50 -07:00
Tobias Müllerleile
1a95ce5214 tls: Re-enable check of CN-ID in cert verification
RFC 6125 explicitly states that a client "MUST NOT seek a match
for a reference identifier of CN-ID if the presented identifiers
include a DNS-ID, SRV-ID, URI-ID, or any application-specific
identifier types supported by the client", but it MAY do so if
none of the mentioned identifier types (but others) are present.
2013-04-07 19:04:02 +04:00
Ben Noordhuis
84bb0ec613 child_process: fix sending utf-8 to child process
In process#send() and child_process.ChildProcess#send(), use 'utf8' as
the encoding and correctly handle partial character sequences by
introducing a StringDecoder. Before this commit, it used 'ascii' and
partial sequences were dropped or corrupted.

This is a back-port of commit 44843a6 from the v0.10 branch.

Fixes #4999 and #5011.
2013-03-25 13:33:26 +01:00
Ben Noordhuis
2c41a80282 crypto: check key type in GetPeerCertificate()
Works around the following exception:

  Error: 140463203215168:error:0607907F:digital envelope
  routines:EVP_PKEY_get1_RSA:expecting an rsa key:
  ../deps/openssl/openssl/crypto/evp/p_lib.c:288:
    at CleartextStream._pusher (tls.js:656:24)
    at SlabBuffer.use (tls.js:199:18)
    at CleartextStream.CryptoStream._push (tls.js:483:33)
    at SecurePair.cycle (tls.js:880:20)
    <snip>

The issue has been solved properly in v0.10 and the master branch as of
commit c6e2db2 ("crypto: clear error stack"). This is the "back-port"
to v0.8.

For some (rather unquantifiable) reason the original fix only works for
the tls module in v0.8 but not the https module unless OpenSSL is
downgraded to 0.9.8. Upgrading OpenSSL does *not* fix it, however.

The https module doesn't appear to be at fault; upgrading it to v0.10
doesn't fix the issue. That leaves either the tls or the http module
(that https derives from) but the changes to those modules are too
massive to back-port as-is.

`git bisect` over the v0.8 -> v0.10 commits didn't show up anything
useful, it pinpoints c6e2db2 as the commit that fixes things.

I've spent several hours on this now and seeing that v0.8 is in
maintenance mode, this cheap hack will have to do.

Fixes #4771.
2013-03-13 16:42:23 +01:00
818 changed files with 56789 additions and 2629 deletions

View File

@@ -382,3 +382,5 @@ Rick Yakubowski <richard@orpha-systems.com>
Dan Kohn <dan@dankohn.com>
Timothy J Fontaine <tjfontaine@gmail.com>
Eugene Girshov <eugene.girshov@nixu.com>
Raymond Feng <enjoyjava@gmail.com>
Tobias Müllerleile <tobias@muellerleile.net>

View File

@@ -1,4 +1,32 @@
2013.03.07, Version 0.8.22 (Stable)
2013.06.04, Version 0.8.24 (maintenance)
* npm: Upgrade to v1.2.24
* url: Properly parse certain oddly formed urls (isaacs)
* http: Don't try to destroy nonexistent sockets (isaacs)
* handle_wrap: fix NULL pointer dereference (Ben Noordhuis)
2013.04.09, Version 0.8.23 (maintenance), c67f8d0500fe15637a623eb759d2ad7eb9fb3b0b
* npm: Upgrade to v1.2.18
* http: Avoid EE warning on ECONNREFUSED handling (isaacs)
* tls: Re-enable check of CN-ID in cert verification (Tobias Müllerleile)
* child_process: fix sending utf-8 to child process (Ben Noordhuis)
* crypto: check key type in GetPeerCertificate() (Ben Noordhuis)
* win/openssl: mark assembled object files as seh safe (Bert Belder)
* windows/msi: fix msi build issue with WiX 3.7/3.8 (Raymond Feng)
2013.03.07, Version 0.8.22 (Stable), 67a4cb4fe8c2346e30ffb83f7178e205cc2dab33
* npm: Update to 1.2.14

3
deps/npm/.npmignore vendored
View File

@@ -1,4 +1,5 @@
*.swp
.*.swp
npm-debug.log
/test/bin
/test/output.log
@@ -20,3 +21,5 @@ html/*.png
!.npmignore
/npm-*.tgz
*.pyc

7
deps/npm/.tern-project vendored Normal file
View File

@@ -0,0 +1,7 @@
{
"libs": [
],
"plugins": {
"node": {}
}
}

View File

@@ -15,7 +15,7 @@ config param.
### browser
* Default: OS X: `"open"`, others: `"google-chrome"`
* Default: OS X: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
* Type: String
The browser that is called by the `npm bugs` command to open websites.

View File

@@ -185,7 +185,7 @@ ostensibly Unix systems.
### browser
* Default: OS X: `"open"`, others: `"google-chrome"`
* Default: OS X: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
* Type: String
The browser that is called by the `npm docs` command to open websites.
@@ -721,6 +721,14 @@ character to indicate reverse sort.
The shell to run for the `npm explore` command.
### shrinkwrap
* Default: true
* Type: Boolean
If set to false, then ignore `npm-shrinkwrap.json` files when
installing.
### sign-git-tag
* Default: false

View File

@@ -97,10 +97,34 @@ more info.
## Keeping files *out* of your package
Use a `.npmignore` file to keep stuff out of your package. If there's
no .npmignore file, but there *is* a .gitignore file, then npm will
ignore the stuff matched by the .gitignore file. If you *want* to
include something that is excluded by your .gitignore file, you can
create an empty .npmignore file to override it.
no `.npmignore` file, but there *is* a `.gitignore` file, then npm will
ignore the stuff matched by the `.gitignore` file. If you *want* to
include something that is excluded by your `.gitignore` file, you can
create an empty `.npmignore` file to override it.
By default, the following paths and files are ignored, so there's no
need to add them to `.npmignore` explicitly:
* `.*.swp`
* `._*`
* `.DS_Store`
* `.git`
* `.hg`
* `.lock-wscript`
* `.svn`
* `.wafpickle-*`
* `CVS`
* `npm-debug.log`
Additionally, everything in `node_modules` is ignored, except for
bundled dependencies. npm automatically handles this for you, so don't
bother adding `node_modules` to `.npmignore`.
The following paths and files are never ignored, so adding them to
`.npmignore` is pointless:
* `package.json`
* `README.*`
## Link Packages

View File

@@ -15,9 +15,9 @@ There sometimes arise cases where a user publishes a module, and then
later, some other user wants to use that name. Here are some common
ways that happens (each of these is based on actual events.)
1. Bob writes a JavaScript module `foo`, which is not node-specific.
Bob doesn't use node at all. Joe wants to use `foo` in node, so he
wraps it in an npm module. Some time later, Bob starts using node,
1. Joe writes a JavaScript module `foo`, which is not node-specific.
Joe doesn't use node at all. Bob wants to use `foo` in node, so he
wraps it in an npm module. Some time later, Joe starts using node,
and wants to take over management of his program.
2. Bob writes an npm module `foo`, and publishes it. Perhaps much
later, Joe finds a bug in `foo`, and fixes it. He sends a pull
@@ -49,7 +49,8 @@ Joe's appropriate course of action in each case is the same.
the `foo` package.
3. After a reasonable amount of time, if Bob has not responded, or if
Bob and Joe can't come to any sort of resolution, email isaacs
<i@izs.me> and we'll sort it out.
<i@izs.me> and we'll sort it out. ("Reasonable" is usually about 4
weeks, but extra time is allowed around common holidays.)
## REASONING
@@ -71,17 +72,23 @@ Some things are not allowed, and will be removed without discussion if
they are brought to the attention of the npm registry admins, including
but not limited to:
1. Malware (that is, a module designed to exploit or harm the machine on
which it is installed)
1. Malware (that is, a package designed to exploit or harm the machine on
which it is installed).
2. Violations of copyright or licenses (for example, cloning an
MIT-licensed program, and then removing or changing the copyright and
license statement)
license statement).
3. Illegal content.
4. "Squatting" on a package name that you *plan* to use, but aren't
actually using. Sorry, I don't care how great the name is, or how
perfect a fit it is for the thing that someday might happen. If
someone wants to use it today, and you're just taking up space with
an empty tarball, you're going to be evicted.
5. Putting empty packages in the registry. Packages must have SOME
functionality. It can be silly, but it can't be *nothing*. (See
also: squatting.)
6. Doing weird things with the registry, like using it as your own
personal application database or otherwise putting non-packagey
things into it.
If you see bad behavior like this, please report it right away.

View File

@@ -16,7 +16,7 @@ config param.
### browser
* Default: OS X: `"open"`, others: `"google-chrome"`
* Default: OS X: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
* Type: String
The browser that is called by the `npm docs` command to open websites.

View File

@@ -77,7 +77,7 @@ npm will not help you do something that is known to be a bad idea.
No. This will never happen. This question comes up sometimes,
because it seems silly from the outside that npm couldn't just be
configured to put stuff somewhere else, and then npm could load them
from there. It's an arbitrary spelling choice, right? What's the bg
from there. It's an arbitrary spelling choice, right? What's the big
deal?
At the time of this writing, the string `'node_modules'` appears 151
@@ -221,11 +221,18 @@ an argument to `git checkout`. The default is `master`.
## How do I install node with npm?
You don't. Try one of these:
You don't. Try one of these node version managers:
* <https://github.com/isaacs/nave>
* <https://github.com/visionmedia/n>
* <https://github.com/creationix/nvm>
Unix:
* <http://github.com/isaacs/nave>
* <http://github.com/visionmedia/n>
* <http://github.com/creationix/nvm>
Windows:
* <http://github.com/marcelklehr/nodist>
* <https://github.com/hakobera/nvmw>
## How can I use npm for development?

View File

@@ -157,21 +157,21 @@ In this case, we might expect a folder structure like this:
+-- node_modules
+-- blerg (1.2.5) <---[A]
+-- bar (1.2.3) <---[B]
| +-- node_modules
| | `-- baz (2.0.2) <---[C]
| | `-- node_modules
| | `-- quux (3.2.0)
| `-- asdf (2.3.4)
| `-- node_modules
| +-- baz (2.0.2) <---[C]
| | `-- node_modules
| | `-- quux (3.2.0)
| `-- asdf (2.3.4)
`-- baz (1.2.3) <---[D]
`-- node_modules
`-- quux (3.2.0) <---[E]
Since foo depends directly on bar@1.2.3 and baz@1.2.3, those are
Since foo depends directly on `bar@1.2.3` and `baz@1.2.3`, those are
installed in foo's `node_modules` folder.
Even though the latest copy of blerg is 1.3.7, foo has a specific
dependency on version 1.2.5. So, that gets installed at [A]. Since the
parent installation of blerg satisfie's bar's dependency on blerg@1.x,
parent installation of blerg satisfies bar's dependency on `blerg@1.x`,
it does not install another copy under [B].
Bar [B] also has dependencies on baz and asdf, so those are installed in
@@ -179,11 +179,11 @@ bar's `node_modules` folder. Because it depends on `baz@2.x`, it cannot
re-use the `baz@1.2.3` installed in the parent `node_modules` folder [D],
and must install its own copy [C].
Underneath bar, the `baz->quux->bar` dependency creates a cycle.
However, because `bar` is already in `quux`'s ancestry [B], it does not
Underneath bar, the `baz -> quux -> bar` dependency creates a cycle.
However, because bar is already in quux's ancestry [B], it does not
unpack another copy of bar into that folder.
Underneath `foo->baz` [D], quux's [E] folder tree is empty, because its
Underneath `foo -> baz` [D], quux's [E] folder tree is empty, because its
dependency on bar is satisfied by the parent folder copy installed at [B].
For a graphical breakdown of what is installed where, use `npm ls`.

View File

@@ -118,6 +118,27 @@ you can specify the value for "bugs" as a simple string instead of an object.
If a url is provided, it will be used by the `npm bugs` command.
## license
You should specify a license for your package so that people know how they are
permitted to use it, and any restrictions you're placing on it.
The simplest way, assuming you're using a common license such as BSD or MIT, is
to just specify the name of the license you're using, like this:
{ "license" : "BSD" }
If you have more complex licensing terms, or you want to provide more detail
in your package.json file, you can use the more verbose plural form, like this:
"licenses" : [
{ "type" : "MyLicense"
, "url" : "http://github.com/owner/project/path/to/license"
}
]
It's also a good idea to include a license file at the top level in your package.
## people fields: author, contributors
The "author" is one person. "contributors" is an array of people. A "person"
@@ -416,9 +437,9 @@ In this case, it's best to list these additional items in a
`devDependencies` hash.
These things will be installed whenever the `--dev` configuration flag
is set. This flag is set automatically when doing `npm link`, and can
be managed like any other npm configuration param. See `npm-config(1)`
for more on the topic.
is set. This flag is set automatically when doing `npm link` or when doing
`npm install` from the root of a package, and can be managed like any other npm
configuration param. See `npm-config(1)` for more on the topic.
## bundledDependencies

View File

@@ -16,6 +16,9 @@ symbolic link from `prefix/package-name` to the current folder.
Next, in some other location, `npm link package-name` will create a
symlink from the local `node_modules` folder to the global symlink.
Note that `package-name` is taken from `package.json` ,
not from directory name.
When creating tarballs for `npm publish`, the linked packages are
"snapshotted" to their current state by resolving the symbolic links.

View File

@@ -7,68 +7,72 @@ npm-shrinkwrap(1) -- Lock down dependency versions
## DESCRIPTION
This command locks down the versions of a package's dependencies so that you can
control exactly which versions of each dependency will be used when your package
is installed.
This command locks down the versions of a package's dependencies so
that you can control exactly which versions of each dependency will be
used when your package is installed. The "package.json" file is still
required if you want to use "npm install".
By default, "npm install" recursively installs the target's dependencies (as
specified in package.json), choosing the latest available version that satisfies
the dependency's semver pattern. In some situations, particularly when shipping
software where each change is tightly managed, it's desirable to fully specify
each version of each dependency recursively so that subsequent builds and
deploys do not inadvertently pick up newer versions of a dependency that satisfy
the semver pattern. Specifying specific semver patterns in each dependency's
package.json would facilitate this, but that's not always possible or desirable,
as when another author owns the npm package. It's also possible to check
dependencies directly into source control, but that may be undesirable for other
reasons.
By default, "npm install" recursively installs the target's
dependencies (as specified in package.json), choosing the latest
available version that satisfies the dependency's semver pattern. In
some situations, particularly when shipping software where each change
is tightly managed, it's desirable to fully specify each version of
each dependency recursively so that subsequent builds and deploys do
not inadvertently pick up newer versions of a dependency that satisfy
the semver pattern. Specifying specific semver patterns in each
dependency's package.json would facilitate this, but that's not always
possible or desirable, as when another author owns the npm package.
It's also possible to check dependencies directly into source control,
but that may be undesirable for other reasons.
As an example, consider package A:
{
"name": "A",
"version": "0.1.0",
"dependencies": {
"B": "<0.1.0"
}
"name": "A",
"version": "0.1.0",
"dependencies": {
"B": "<0.1.0"
}
}
package B:
{
"name": "B",
"version": "0.0.1",
"dependencies": {
"C": "<0.1.0"
}
"name": "B",
"version": "0.0.1",
"dependencies": {
"C": "<0.1.0"
}
}
and package C:
{
"name": "C,
"version": "0.0.1"
"name": "C,
"version": "0.0.1"
}
If these are the only versions of A, B, and C available in the registry, then
a normal "npm install A" will install:
If these are the only versions of A, B, and C available in the
registry, then a normal "npm install A" will install:
A@0.1.0
`-- B@0.0.1
`-- C@0.0.1
However, if B@0.0.2 is published, then a fresh "npm install A" will install:
However, if B@0.0.2 is published, then a fresh "npm install A" will
install:
A@0.1.0
`-- B@0.0.2
`-- C@0.0.1
assuming the new version did not modify B's dependencies. Of course, the new
version of B could include a new version of C and any number of new
dependencies. If such changes are undesirable, the author of A could specify a
dependency on B@0.0.1. However, if A's author and B's author are not the same
person, there's no way for A's author to say that he or she does not want to
pull in newly published versions of C when B hasn't changed at all.
assuming the new version did not modify B's dependencies. Of course,
the new version of B could include a new version of C and any number
of new dependencies. If such changes are undesirable, the author of A
could specify a dependency on B@0.0.1. However, if A's author and B's
author are not the same person, there's no way for A's author to say
that he or she does not want to pull in newly published versions of C
when B hasn't changed at all.
In this case, A's author can run
@@ -91,78 +95,88 @@ This generates npm-shrinkwrap.json, which will look something like this:
}
}
The shrinkwrap command has locked down the dependencies based on what's
currently installed in node_modules. When "npm install" installs a package with
a npm-shrinkwrap.json file in the package root, the shrinkwrap file (rather than
package.json files) completely drives the installation of that package and all
of its dependencies (recursively). So now the author publishes A@0.1.0, and
subsequent installs of this package will use B@0.0.1 and C@0.1.0, regardless the
dependencies and versions listed in A's, B's, and C's package.json files.
The shrinkwrap command has locked down the dependencies based on
what's currently installed in node_modules. When "npm install"
installs a package with a npm-shrinkwrap.json file in the package
root, the shrinkwrap file (rather than package.json files) completely
drives the installation of that package and all of its dependencies
(recursively). So now the author publishes A@0.1.0, and subsequent
installs of this package will use B@0.0.1 and C@0.1.0, regardless the
dependencies and versions listed in A's, B's, and C's package.json
files.
### Using shrinkwrapped packages
Using a shrinkwrapped package is no different than using any other package: you
can "npm install" it by hand, or add a dependency to your package.json file and
"npm install" it.
Using a shrinkwrapped package is no different than using any other
package: you can "npm install" it by hand, or add a dependency to your
package.json file and "npm install" it.
### Building shrinkwrapped packages
To shrinkwrap an existing package:
1. Run "npm install" in the package root to install the current versions of all
dependencies.
1. Run "npm install" in the package root to install the current
versions of all dependencies.
2. Validate that the package works as expected with these versions.
3. Run "npm shrinkwrap", add npm-shrinkwrap.json to git, and publish your
package.
3. Run "npm shrinkwrap", add npm-shrinkwrap.json to git, and publish
your package.
To add or update a dependency in a shrinkwrapped package:
1. Run "npm install" in the package root to install the current versions of all
1. Run "npm install" in the package root to install the current
versions of all dependencies.
2. Add or update dependencies. "npm install" each new or updated
package individually and then update package.json. Note that they
must be explicitly named in order to be installed: running `npm
install` with no arguments will merely reproduce the existing
shrinkwrap.
3. Validate that the package works as expected with the new
dependencies.
2. Add or update dependencies. "npm install" each new or updated package
individually and then update package.json. Note that they must be
explicitly named in order to be installed: running `npm install` with
no arguments will merely reproduce the existing shrinkwrap.
3. Validate that the package works as expected with the new dependencies.
4. Run "npm shrinkwrap", commit the new npm-shrinkwrap.json, and publish your
package.
4. Run "npm shrinkwrap", commit the new npm-shrinkwrap.json, and
publish your package.
You can use npm-outdated(1) to view dependencies with newer versions available.
You can use npm-outdated(1) to view dependencies with newer versions
available.
### Other Notes
Since "npm shrinkwrap" uses the locally installed packages to construct the
shrinkwrap file, devDependencies will be included if and only if you've
installed them already when you make the shrinkwrap.
A shrinkwrap file must be consistent with the package's package.json
file. "npm shrinkwrap" will fail if required dependencies are not
already installed, since that would result in a shrinkwrap that
wouldn't actually work. Similarly, the command will fail if there are
extraneous packages (not referenced by package.json), since that would
indicate that package.json is not correct.
A shrinkwrap file must be consistent with the package's package.json file. "npm
shrinkwrap" will fail if required dependencies are not already installed, since
that would result in a shrinkwrap that wouldn't actually work. Similarly, the
command will fail if there are extraneous packages (not referenced by
package.json), since that would indicate that package.json is not correct.
Since "npm shrinkwrap" is intended to lock down your dependencies for
production use, `devDependencies` will not be included unless you
explicitly set the `--dev` flag when you run `npm shrinkwrap`. If
installed `devDependencies` are excluded, then npm will print a
warning. If you want them to be installed with your module by
default, please consider adding them to `dependencies` instead.
If shrinkwrapped package A depends on shrinkwrapped package B, B's shrinkwrap
will not be used as part of the installation of A. However, because A's
shrinkwrap is constructed from a valid installation of B and recursively
specifies all dependencies, the contents of B's shrinkwrap will implicitly be
included in A's shrinkwrap.
If shrinkwrapped package A depends on shrinkwrapped package B, B's
shrinkwrap will not be used as part of the installation of A. However,
because A's shrinkwrap is constructed from a valid installation of B
and recursively specifies all dependencies, the contents of B's
shrinkwrap will implicitly be included in A's shrinkwrap.
### Caveats
Shrinkwrap files only lock down package versions, not actual package contents.
While discouraged, a package author can republish an existing version of a
package, causing shrinkwrapped packages using that version to pick up different
code than they were before. If you want to avoid any risk that a byzantine
author replaces a package you're using with code that breaks your application,
you could modify the shrinkwrap file to use git URL references rather than
version numbers so that npm always fetches all packages from git.
Shrinkwrap files only lock down package versions, not actual package
contents. While discouraged, a package author can republish an
existing version of a package, causing shrinkwrapped packages using
that version to pick up different code than they were before. If you
want to avoid any risk that a byzantine author replaces a package
you're using with code that breaks your application, you could modify
the shrinkwrap file to use git URL references rather than version
numbers so that npm always fetches all packages from git.
If you wish to lock down the specific bytes included in a package, for
example to have 100% confidence in being able to reproduce a deployment
or build, then you ought to check your dependencies into source control,
or pursue some other mechanism that can verify contents rather than
versions.
example to have 100% confidence in being able to reproduce a
deployment or build, then you ought to check your dependencies into
source control, or pursue some other mechanism that can verify
contents rather than versions.
## SEE ALSO

View File

@@ -19,7 +19,7 @@
<p>This function should not be used programmatically. Instead, just refer
to the <code>npm.bin</code> member.</p>
</div>
<p id="footer">bin &mdash; npm@1.2.14</p>
<p id="footer">bin &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -25,7 +25,7 @@ optional version number.</p>
<p>This command will launch a browser, so this command may not be the most
friendly for programmatic use.</p>
</div>
<p id="footer">bugs &mdash; npm@1.2.14</p>
<p id="footer">bugs &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -28,7 +28,7 @@ usage, or <code>man 3 npm-&lt;command&gt;</code> for programmatic usage.</p>
<ul><li><a href="../doc/index.html">index(1)</a></li></ul>
</div>
<p id="footer">commands &mdash; npm@1.2.14</p>
<p id="footer">commands &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -33,7 +33,7 @@ functions instead.</p>
<ul><li><a href="../api/npm.html">npm(3)</a></li></ul>
</div>
<p id="footer">config &mdash; npm@1.2.14</p>
<p id="footer">config &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -32,7 +32,7 @@ install the package.</p></li></ul>
<ul><li><a href="../api/publish.html">publish(3)</a></li><li><a href="../api/unpublish.html">unpublish(3)</a></li><li><a href="../doc/registry.html">registry(1)</a></li></ul>
</div>
<p id="footer">deprecate &mdash; npm@1.2.14</p>
<p id="footer">deprecate &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -25,7 +25,7 @@ optional version number.</p>
<p>This command will launch a browser, so this command may not be the most
friendly for programmatic use.</p>
</div>
<p id="footer">docs &mdash; npm@1.2.14</p>
<p id="footer">docs &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -30,7 +30,7 @@ to open. The package can optionally have a version number attached.</p>
<p>Since this command opens an editor in a new process, be careful about where
and how this is used.</p>
</div>
<p id="footer">edit &mdash; npm@1.2.14</p>
<p id="footer">edit &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -24,7 +24,7 @@ sure to use <code>npm rebuild &lt;pkg&gt;</code> if you make any changes.</p>
<p>The first element in the &#39;args&#39; parameter must be a package name. After that is the optional command, which can be any number of strings. All of the strings will be combined into one, space-delimited command.</p>
</div>
<p id="footer">explore &mdash; npm@1.2.14</p>
<p id="footer">explore &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -32,7 +32,7 @@ Name of the file that matched</li></ul>
<p>The silent parameter is not neccessary not used, but it may in the future.</p>
</div>
<p id="footer">help-search &mdash; npm@1.2.14</p>
<p id="footer">help-search &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -35,7 +35,7 @@ then go ahead and use this programmatically.</p>
<p><a href="../doc/json.html">json(1)</a></p>
</div>
<p id="footer">init &mdash; npm@1.2.14</p>
<p id="footer">init &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -25,7 +25,7 @@ the name of a package to be installed.</p>
<p>Finally, &#39;callback&#39; is a function that will be called when all packages have been
installed or when an error has been encountered.</p>
</div>
<p id="footer">install &mdash; npm@1.2.14</p>
<p id="footer">install &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -39,7 +39,7 @@ npm.commands.link(&#39;redis&#39;, cb) # link-install the package</code></pre>
<p>Now, any changes to the redis package will be reflected in
the package in the current working directory</p>
</div>
<p id="footer">link &mdash; npm@1.2.14</p>
<p id="footer">link &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -32,7 +32,7 @@ config object.</p>
<p>For a list of all the available command-line configs, see <code>npm help config</code></p>
</div>
<p id="footer">load &mdash; npm@1.2.14</p>
<p id="footer">load &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -59,7 +59,7 @@ project.</p>
This means that if a submodule a same dependency as a parent module, then the
dependency will only be output once.</p>
</div>
<p id="footer">ls &mdash; npm@1.2.14</p>
<p id="footer">ls &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -24,7 +24,7 @@ npm.load([configObject,] function (er, npm) {
<h2 id="VERSION">VERSION</h2>
<p>1.2.14</p>
<p>1.2.24</p>
<h2 id="DESCRIPTION">DESCRIPTION</h2>
@@ -92,7 +92,7 @@ method names. Use the <code>npm.deref</code> method to find the real name.</p>
<pre><code>var cmd = npm.deref(&quot;unp&quot;) // cmd === &quot;unpublish&quot;</code></pre>
</div>
<p id="footer">npm &mdash; npm@1.2.14</p>
<p id="footer">npm &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -19,7 +19,7 @@ currently outdated.</p>
<p>If the &#39;packages&#39; parameter is left out, npm will check all packages.</p>
</div>
<p id="footer">outdated &mdash; npm@1.2.14</p>
<p id="footer">outdated &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -34,7 +34,7 @@ that is not implemented at this time.</p>
<ul><li><a href="../api/publish.html">publish(3)</a></li><li><a href="../doc/registry.html">registry(1)</a></li></ul>
</div>
<p id="footer">owner &mdash; npm@1.2.14</p>
<p id="footer">owner &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -25,7 +25,7 @@ overwritten the second time.</p>
<p>If no arguments are supplied, then npm packs the current package folder.</p>
</div>
<p id="footer">pack &mdash; npm@1.2.14</p>
<p id="footer">pack &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -21,7 +21,7 @@
<p>This function is not useful programmatically</p>
</div>
<p id="footer">prefix &mdash; npm@1.2.14</p>
<p id="footer">prefix &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -23,7 +23,7 @@
<p>Extraneous packages are packages that are not listed on the parent
package&#39;s dependencies list.</p>
</div>
<p id="footer">prune &mdash; npm@1.2.14</p>
<p id="footer">prune &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -32,7 +32,7 @@ the registry. Overwrites when the &quot;force&quot; environment variable is set
<ul><li><a href="../doc/registry.html">registry(1)</a></li><li><a href="../doc/adduser.html">adduser(1)</a></li><li><a href="../api/owner.html">owner(3)</a></li></ul>
</div>
<p id="footer">publish &mdash; npm@1.2.14</p>
<p id="footer">publish &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -22,7 +22,7 @@ the new binary. If no &#39;packages&#39; parameter is specify, every package wil
<p>See <code>npm help build</code></p>
</div>
<p id="footer">rebuild &mdash; npm@1.2.14</p>
<p id="footer">rebuild &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -27,7 +27,7 @@ in the <code>packages</code> parameter.</p>
<ul><li><a href="../api/start.html">start(3)</a></li><li><a href="../api/stop.html">stop(3)</a></li></ul>
</div>
<p id="footer">restart &mdash; npm@1.2.14</p>
<p id="footer">restart &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -21,7 +21,7 @@
<p>This function is not useful programmatically.</p>
</div>
<p id="footer">root &mdash; npm@1.2.14</p>
<p id="footer">root &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -29,7 +29,7 @@ assumed to be the command to run. All other elements are ignored.</p>
<ul><li><a href="../doc/scripts.html">scripts(1)</a></li><li><a href="../api/test.html">test(3)</a></li><li><a href="../api/start.html">start(3)</a></li><li><a href="../api/restart.html">restart(3)</a></li><li><a href="../api/stop.html">stop(3)</a></li></ul>
</div>
<p id="footer">run-script &mdash; npm@1.2.14</p>
<p id="footer">run-script &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -32,7 +32,7 @@ excluded term (the &quot;searchexclude&quot; config). The search is case insensi
and doesn&#39;t try to read your mind (it doesn&#39;t do any verb tense matching or the
like).</p>
</div>
<p id="footer">search &mdash; npm@1.2.14</p>
<p id="footer">search &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -26,7 +26,7 @@ but the shrinkwrap file will still be written.</p>
<p>Finally, &#39;callback&#39; is a function that will be called when the shrinkwrap has
been saved.</p>
</div>
<p id="footer">shrinkwrap &mdash; npm@1.2.14</p>
<p id="footer">shrinkwrap &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -19,7 +19,7 @@
<p>npm can run tests on multiple packages. Just specify multiple packages
in the <code>packages</code> parameter.</p>
</div>
<p id="footer">start &mdash; npm@1.2.14</p>
<p id="footer">start &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -19,7 +19,7 @@
<p>npm can run stop on multiple packages. Just specify multiple packages
in the <code>packages</code> parameter.</p>
</div>
<p id="footer">stop &mdash; npm@1.2.14</p>
<p id="footer">stop &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -33,7 +33,7 @@ dependencies into the submodule folder.</p>
<ul><li>npm help json</li><li>git help submodule</li></ul>
</div>
<p id="footer">submodule &mdash; npm@1.2.14</p>
<p id="footer">submodule &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -29,7 +29,7 @@ parameter is missing or falsey (empty), the default froom the config will be
used. For more information about how to set this config, check
<code>man 3 npm-config</code> for programmatic usage or <code>man npm-config</code> for cli usage.</p>
</div>
<p id="footer">tag &mdash; npm@1.2.14</p>
<p id="footer">tag &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -22,7 +22,7 @@ true.</p>
<p>npm can run tests on multiple packages. Just specify multiple packages
in the <code>packages</code> parameter.</p>
</div>
<p id="footer">test &mdash; npm@1.2.14</p>
<p id="footer">test &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -22,7 +22,7 @@ the name of a package to be uninstalled.</p>
<p>Finally, &#39;callback&#39; is a function that will be called when all packages have been
uninstalled or when an error has been encountered.</p>
</div>
<p id="footer">uninstall &mdash; npm@1.2.14</p>
<p id="footer">uninstall &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -26,7 +26,7 @@ is what is meant.</p>
<p>If no version is specified, or if all versions are removed then
the root package entry is removed from the registry entirely.</p>
</div>
<p id="footer">unpublish &mdash; npm@1.2.14</p>
<p id="footer">unpublish &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -18,7 +18,7 @@
<p>The &#39;packages&#39; argument is an array of packages to update. The &#39;callback&#39; parameter will be called when done or when an error occurs.</p>
</div>
<p id="footer">update &mdash; npm@1.2.14</p>
<p id="footer">update &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -24,7 +24,7 @@ fail if the repo is not clean.</p>
parameter. The difference, however, is this function will fail if it does
not have exactly one element. The only element should be a version number.</p>
</div>
<p id="footer">version &mdash; npm@1.2.14</p>
<p id="footer">version &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -99,7 +99,7 @@ the field name.</p>
<p>corresponding to the list of fields selected.</p>
</div>
<p id="footer">view &mdash; npm@1.2.14</p>
<p id="footer">view &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -21,7 +21,7 @@
<p>This function is not useful programmatically</p>
</div>
<p id="footer">whoami &mdash; npm@1.2.14</p>
<p id="footer">whoami &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -240,7 +240,7 @@ will no doubt tell you to put the output in a gist or email.</p>
<ul><li><a href="../doc/npm.html">npm(1)</a></li><li><a href="../doc/faq.html">faq(1)</a></li><li><a href="../doc/help.html">help(1)</a></li><li><a href="../doc/index.html">index(1)</a></li></ul>
</div>
<p id="footer"><a href="../doc/README.html">README</a> &mdash; npm@1.2.14</p>
<p id="footer"><a href="../doc/README.html">README</a> &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -39,7 +39,7 @@ authorize on a new machine.</p>
<ul><li><a href="../doc/registry.html">registry(1)</a></li><li><a href="../doc/config.html">config(1)</a></li><li><a href="../doc/owner.html">owner(1)</a></li><li><a href="../doc/whoami.html">whoami(1)</a></li></ul>
</div>
<p id="footer">adduser &mdash; npm@1.2.14</p>
<p id="footer">adduser &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -20,7 +20,7 @@
<ul><li><a href="../doc/prefix.html">prefix(1)</a></li><li><a href="../doc/root.html">root(1)</a></li><li><a href="../doc/folders.html">folders(1)</a></li><li><a href="../doc/config.html">config(1)</a></li></ul>
</div>
<p id="footer">bin &mdash; npm@1.2.14</p>
<p id="footer">bin &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -22,7 +22,7 @@ config param.</p>
<h3 id="browser">browser</h3>
<ul><li>Default: OS X: <code>&quot;open&quot;</code>, others: <code>&quot;google-chrome&quot;</code></li><li>Type: String</li></ul>
<ul><li>Default: OS X: <code>&quot;open&quot;</code>, Windows: <code>&quot;start&quot;</code>, Others: <code>&quot;xdg-open&quot;</code></li><li>Type: String</li></ul>
<p>The browser that is called by the <code>npm bugs</code> command to open websites.</p>
@@ -36,7 +36,7 @@ config param.</p>
<ul><li><a href="../doc/docs.html">docs(1)</a></li><li><a href="../doc/view.html">view(1)</a></li><li><a href="../doc/publish.html">publish(1)</a></li><li><a href="../doc/registry.html">registry(1)</a></li><li><a href="../doc/config.html">config(1)</a></li><li><a href="../doc/json.html">json(1)</a></li></ul>
</div>
<p id="footer">bugs &mdash; npm@1.2.14</p>
<p id="footer">bugs &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -25,7 +25,7 @@ A folder containing a <code>package.json</code> file in its root.</li></ul>
<ul><li><a href="../doc/install.html">install(1)</a></li><li><a href="../doc/link.html">link(1)</a></li><li><a href="../doc/scripts.html">scripts(1)</a></li><li><a href="../doc/json.html">json(1)</a></li></ul>
</div>
<p id="footer">build &mdash; npm@1.2.14</p>
<p id="footer">build &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -20,7 +20,7 @@ install packages into the local space.</p>
<ul><li><a href="../doc/install.html">install(1)</a></li></ul>
</div>
<p id="footer">bundle &mdash; npm@1.2.14</p>
<p id="footer">bundle &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -66,7 +66,7 @@ they do not make an HTTP request to the registry.</p>
<ul><li><a href="../doc/folders.html">folders(1)</a></li><li><a href="../doc/config.html">config(1)</a></li><li><a href="../doc/install.html">install(1)</a></li><li><a href="../doc/publish.html">publish(1)</a></li><li><a href="../doc/pack.html">pack(1)</a></li></ul>
</div>
<p id="footer">cache &mdash; npm@1.2.14</p>
<p id="footer">cache &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -65,7 +65,7 @@
<ul><li><a href="../doc/npm.html">npm(1)</a></li><li><a href="../doc/faq.html">faq(1)</a></li></ul>
</div>
<p id="footer">changelog &mdash; npm@1.2.14</p>
<p id="footer">changelog &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -182,7 +182,7 @@ set to anything.&quot;</p>
<ul><li><a href="../doc/developers.html">developers(1)</a></li><li><a href="../doc/faq.html">faq(1)</a></li><li><a href="../doc/npm.html">npm(1)</a></li></ul>
</div>
<p id="footer">coding-style &mdash; npm@1.2.14</p>
<p id="footer">coding-style &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -33,7 +33,7 @@ completions based on the arguments.</p>
<ul><li><a href="../doc/developers.html">developers(1)</a></li><li><a href="../doc/faq.html">faq(1)</a></li><li><a href="../doc/npm.html">npm(1)</a></li></ul>
</div>
<p id="footer">completion &mdash; npm@1.2.14</p>
<p id="footer">completion &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -169,7 +169,7 @@ ostensibly Unix systems.</p>
<h3 id="browser">browser</h3>
<ul><li>Default: OS X: <code>&quot;open&quot;</code>, others: <code>&quot;google-chrome&quot;</code></li><li>Type: String</li></ul>
<ul><li>Default: OS X: <code>&quot;open&quot;</code>, Windows: <code>&quot;start&quot;</code>, Others: <code>&quot;xdg-open&quot;</code></li><li>Type: String</li></ul>
<p>The browser that is called by the <code>npm docs</code> command to open websites.</p>
@@ -636,6 +636,13 @@ 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>
@@ -771,7 +778,7 @@ then answer &quot;no&quot; to any prompt.</p>
<ul><li><a href="../doc/folders.html">folders(1)</a></li><li><a href="../doc/npm.html">npm(1)</a></li></ul>
</div>
<p id="footer">config &mdash; npm@1.2.14</p>
<p id="footer">config &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -57,7 +57,7 @@ registry.</p>
<ul><li><a href="../doc/ls.html">ls(1)</a></li><li><a href="../doc/update.html">update(1)</a></li><li><a href="../doc/install.html">install(1)</a></li></ul>
</div>
<p id="footer">dedupe &mdash; npm@1.2.14</p>
<p id="footer">dedupe &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -31,7 +31,7 @@ something like this:</p>
<ul><li><a href="../doc/publish.html">publish(1)</a></li><li><a href="../doc/registry.html">registry(1)</a></li></ul>
</div>
<p id="footer">deprecate &mdash; npm@1.2.14</p>
<p id="footer">deprecate &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -82,10 +82,24 @@ 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&#39;s
no .npmignore file, but there <em>is</em> a .gitignore file, then npm will
ignore the stuff matched by the .gitignore file. If you <em>want</em> to
include something that is excluded by your .gitignore file, you can
create an empty .npmignore file to override it.</p>
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.</p>
<p>By default, the following paths and files are ignored, so there&#39;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>.lock-wscript</code></li><li><code>.svn</code></li><li><code>.wafpickle-*</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&#39;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></li></ul>
<h2 id="Link-Packages">Link Packages</h2>
@@ -160,7 +174,7 @@ from a fresh checkout.</p>
<ul><li><a href="../doc/faq.html">faq(1)</a></li><li><a href="../doc/npm.html">npm(1)</a></li><li><a href="../doc/init.html">init(1)</a></li><li><a href="../doc/json.html">json(1)</a></li><li><a href="../doc/scripts.html">scripts(1)</a></li><li><a href="../doc/publish.html">publish(1)</a></li><li><a href="../doc/adduser.html">adduser(1)</a></li><li><a href="../doc/registry.html">registry(1)</a></li></ul>
</div>
<p id="footer">developers &mdash; npm@1.2.14</p>
<p id="footer">developers &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -20,9 +20,9 @@
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>Bob writes a JavaScript module <code>foo</code>, which is not node-specific.
Bob doesn&#39;t use node at all. Joe wants to use <code>foo</code> in node, so he
wraps it in an npm module. Some time later, Bob starts using node,
<ol><li>Joe writes a JavaScript module <code>foo</code>, which is not node-specific.
Joe doesn&#39;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&#39;t have the time to deal with it,
@@ -49,7 +49,8 @@ isaacs <a href="mailto:i@izs.me">i@izs.me</a> to the CC list of the email. Ment
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&#39;t come to any sort of resolution, email isaacs
<a href="mailto:i@izs.me">i@izs.me</a> and we&#39;ll sort it out.</li></ol>
<a href="mailto:i@izs.me">i@izs.me</a> and we&#39;ll sort it out. (&quot;Reasonable&quot; is usually about 4
weeks, but extra time is allowed around common holidays.)</li></ol>
<h2 id="REASONING">REASONING</h2>
@@ -71,14 +72,18 @@ feeling good about the interaction.</p>
they are brought to the attention of the npm registry admins, including
but not limited to:</p>
<ol><li>Malware (that is, a module designed to exploit or harm the machine on
which it is installed)</li><li>Violations of copyright or licenses (for example, cloning an
<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>&quot;Squatting&quot; on a package name that you <em>plan</em> to use, but aren&#39;t
license statement).</li><li>Illegal content.</li><li>&quot;Squatting&quot; on a package name that you <em>plan</em> to use, but aren&#39;t
actually using. Sorry, I don&#39;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&#39;re just taking up space with
an empty tarball, you&#39;re going to be evicted.</li></ol>
an empty tarball, you&#39;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&#39;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>
@@ -86,7 +91,7 @@ an empty tarball, you&#39;re going to be evicted.</li></ol>
<ul><li><a href="../doc/registry.html">registry(1)</a></li><li><a href="../doc/owner.html">owner(1)</a></li></ul>
</div>
<p id="footer">disputes &mdash; npm@1.2.14</p>
<p id="footer">disputes &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -23,7 +23,7 @@ config param.</p>
<h3 id="browser">browser</h3>
<ul><li>Default: OS X: <code>&quot;open&quot;</code>, others: <code>&quot;google-chrome&quot;</code></li><li>Type: String</li></ul>
<ul><li>Default: OS X: <code>&quot;open&quot;</code>, Windows: <code>&quot;start&quot;</code>, Others: <code>&quot;xdg-open&quot;</code></li><li>Type: String</li></ul>
<p>The browser that is called by the <code>npm docs</code> command to open websites.</p>
@@ -37,7 +37,7 @@ config param.</p>
<ul><li><a href="../doc/view.html">view(1)</a></li><li><a href="../doc/publish.html">publish(1)</a></li><li><a href="../doc/registry.html">registry(1)</a></li><li><a href="../doc/config.html">config(1)</a></li><li><a href="../doc/json.html">json(1)</a></li></ul>
</div>
<p id="footer">docs &mdash; npm@1.2.14</p>
<p id="footer">docs &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -37,7 +37,7 @@ or <code>&quot;notepad&quot;</code> on Windows.</li><li>Type: path</li></ul>
<ul><li><a href="../doc/folders.html">folders(1)</a></li><li><a href="../doc/explore.html">explore(1)</a></li><li><a href="../doc/install.html">install(1)</a></li><li><a href="../doc/config.html">config(1)</a></li></ul>
</div>
<p id="footer">edit &mdash; npm@1.2.14</p>
<p id="footer">edit &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -40,7 +40,7 @@ Windows</li><li>Type: path</li></ul>
<ul><li><a href="../doc/submodule.html">submodule(1)</a></li><li><a href="../doc/folders.html">folders(1)</a></li><li><a href="../doc/edit.html">edit(1)</a></li><li><a href="../doc/rebuild.html">rebuild(1)</a></li><li><a href="../doc/build.html">build(1)</a></li><li><a href="../doc/install.html">install(1)</a></li></ul>
</div>
<p id="footer">explore &mdash; npm@1.2.14</p>
<p id="footer">explore &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -83,7 +83,7 @@ program that uses it.</p>
<p>No. This will never happen. This question comes up sometimes,
because it seems silly from the outside that npm couldn&#39;t just be
configured to put stuff somewhere else, and then npm could load them
from there. It&#39;s an arbitrary spelling choice, right? What&#39;s the bg
from there. It&#39;s an arbitrary spelling choice, right? What&#39;s the big
deal?</p>
<p>At the time of this writing, the string <code>&#39;node_modules&#39;</code> appears 151
@@ -219,9 +219,15 @@ an argument to <code>git checkout</code>. The default is <code>master</code>.</
<h2 id="How-do-I-install-node-with-npm">How do I install node with npm?</h2>
<p>You don&#39;t. Try one of these:</p>
<p>You don&#39;t. Try one of these node version managers:</p>
<ul><li><a href="https://github.com/isaacs/nave">https://github.com/isaacs/nave</a></li><li><a href="https://github.com/visionmedia/n">https://github.com/visionmedia/n</a></li><li><a href="https://github.com/creationix/nvm">https://github.com/creationix/nvm</a></li></ul>
<p>Unix:</p>
<ul><li><a href="http://github.com/isaacs/nave">http://github.com/isaacs/nave</a></li><li><a href="http://github.com/visionmedia/n">http://github.com/visionmedia/n</a></li><li><a href="http://github.com/creationix/nvm">http://github.com/creationix/nvm</a></li></ul>
<p>Windows:</p>
<ul><li><a href="http://github.com/marcelklehr/nodist">http://github.com/marcelklehr/nodist</a></li><li><a href="https://github.com/hakobera/nvmw">https://github.com/hakobera/nvmw</a></li></ul>
<h2 id="How-can-I-use-npm-for-development">How can I use npm for development?</h2>
@@ -296,7 +302,7 @@ There is not sufficient need to impose namespace rules on everyone.</p>
<ul><li><a href="../doc/npm.html">npm(1)</a></li><li><a href="../doc/developers.html">developers(1)</a></li><li><a href="../doc/json.html">json(1)</a></li><li><a href="../doc/config.html">config(1)</a></li><li><a href="../doc/folders.html">folders(1)</a></li></ul>
</div>
<p id="footer">faq &mdash; npm@1.2.14</p>
<p id="footer">faq &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -160,21 +160,21 @@ highest level possible, below the localized &quot;target&quot; folder.</p>
+-- node_modules
+-- blerg (1.2.5) &lt;---[A]
+-- bar (1.2.3) &lt;---[B]
| +-- node_modules
| | `-- baz (2.0.2) &lt;---[C]
| | `-- node_modules
| | `-- quux (3.2.0)
| `-- asdf (2.3.4)
| `-- node_modules
| +-- baz (2.0.2) &lt;---[C]
| | `-- node_modules
| | `-- quux (3.2.0)
| `-- asdf (2.3.4)
`-- baz (1.2.3) &lt;---[D]
`-- node_modules
`-- quux (3.2.0) &lt;---[E]</code></pre>
<p>Since foo depends directly on bar@1.2.3 and baz@1.2.3, those are
<p>Since foo depends directly on <code>bar@1.2.3</code> and <code>baz@1.2.3</code>, those are
installed in foo&#39;s <code>node_modules</code> folder.</p>
<p>Even though the latest copy of blerg is 1.3.7, foo has a specific
dependency on version 1.2.5. So, that gets installed at [A]. Since the
parent installation of blerg satisfie&#39;s bar&#39;s dependency on blerg@1.x,
parent installation of blerg satisfies bar&#39;s dependency on <code>blerg@1.x</code>,
it does not install another copy under [B].</p>
<p>Bar [B] also has dependencies on baz and asdf, so those are installed in
@@ -182,11 +182,11 @@ bar&#39;s <code>node_modules</code> folder. Because it depends on <code>baz@2.x
re-use the <code>baz@1.2.3</code> installed in the parent <code>node_modules</code> folder [D],
and must install its own copy [C].</p>
<p>Underneath bar, the <code>baz-&gt;quux-&gt;bar</code> dependency creates a cycle.
However, because <code>bar</code> is already in <code>quux</code>&#39;s ancestry [B], it does not
<p>Underneath bar, the <code>baz -&gt; quux -&gt; bar</code> dependency creates a cycle.
However, because bar is already in quux&#39;s ancestry [B], it does not
unpack another copy of bar into that folder.</p>
<p>Underneath <code>foo-&gt;baz</code> [D], quux&#39;s [E] folder tree is empty, because its
<p>Underneath <code>foo -&gt; baz</code> [D], quux&#39;s [E] folder tree is empty, because its
dependency on bar is satisfied by the parent folder copy installed at [B].</p>
<p>For a graphical breakdown of what is installed where, use <code>npm ls</code>.</p>
@@ -205,7 +205,7 @@ cannot be found elsewhere. See <code><a href="../doc/json.html">json(1)</a></co
<ul><li><a href="../doc/faq.html">faq(1)</a></li><li><a href="../doc/json.html">json(1)</a></li><li><a href="../doc/install.html">install(1)</a></li><li><a href="../doc/pack.html">pack(1)</a></li><li><a href="../doc/cache.html">cache(1)</a></li><li><a href="../doc/config.html">config(1)</a></li><li><a href="../doc/publish.html">publish(1)</a></li></ul>
</div>
<p id="footer">folders &mdash; npm@1.2.14</p>
<p id="footer">folders &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -205,7 +205,7 @@ cannot be found elsewhere. See <code><a href="../doc/json.html">json(1)</a></co
<ul><li><a href="../doc/faq.html">faq(1)</a></li><li><a href="../doc/json.html">json(1)</a></li><li><a href="../doc/install.html">install(1)</a></li><li><a href="../doc/pack.html">pack(1)</a></li><li><a href="../doc/cache.html">cache(1)</a></li><li><a href="../doc/config.html">config(1)</a></li><li><a href="../doc/publish.html">publish(1)</a></li></ul>
</div>
<p id="footer">global &mdash; npm@1.2.14</p>
<p id="footer">global &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -38,7 +38,7 @@ where the terms were found in the documentation.</p>
<ul><li><a href="../doc/npm.html">npm(1)</a></li><li><a href="../doc/faq.html">faq(1)</a></li><li><a href="../doc/help.html">help(1)</a></li></ul>
</div>
<p id="footer">help-search &mdash; npm@1.2.14</p>
<p id="footer">help-search &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -36,7 +36,7 @@ matches are equivalent to specifying a topic name.</p>
<ul><li><a href="../doc/npm.html">npm(1)</a></li><li><a href="../doc/README.html">README</a></li><li><a href="../doc/faq.html">faq(1)</a></li><li><a href="../doc/folders.html">folders(1)</a></li><li><a href="../doc/config.html">config(1)</a></li><li><a href="../doc/json.html">json(1)</a></li><li><a href="../doc/help-search.html">help-search(1)</a></li><li><a href="../doc/index.html">index(1)</a></li></ul>
</div>
<p id="footer">help &mdash; npm@1.2.14</p>
<p id="footer">help &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -400,7 +400,7 @@
<p> Display npm username</p>
</div>
<p id="footer">index &mdash; npm@1.2.14</p>
<p id="footer">index &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -29,7 +29,7 @@ without a really good reason to do so.</p>
<ul><li><a href="https://github.com/isaacs/init-package-json">https://github.com/isaacs/init-package-json</a></li><li><a href="../doc/json.html">json(1)</a></li><li><a href="../doc/version.html">version(1)</a></li></ul>
</div>
<p id="footer">init &mdash; npm@1.2.14</p>
<p id="footer">init &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -136,7 +136,7 @@ affects a real use-case, it will be investigated.</p>
<ul><li><a href="../doc/folders.html">folders(1)</a></li><li><a href="../doc/update.html">update(1)</a></li><li><a href="../doc/link.html">link(1)</a></li><li><a href="../doc/rebuild.html">rebuild(1)</a></li><li><a href="../doc/scripts.html">scripts(1)</a></li><li><a href="../doc/build.html">build(1)</a></li><li><a href="../doc/config.html">config(1)</a></li><li><a href="../doc/registry.html">registry(1)</a></li><li><a href="../doc/folders.html">folders(1)</a></li><li><a href="../doc/tag.html">tag(1)</a></li><li><a href="../doc/rm.html">rm(1)</a></li><li><a href="../doc/shrinkwrap.html">shrinkwrap(1)</a></li></ul>
</div>
<p id="footer">install &mdash; npm@1.2.14</p>
<p id="footer">install &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -107,6 +107,27 @@ you can specify the value for &quot;bugs&quot; as a simple string instead of an
<p>If a url is provided, it will be used by the <code>npm bugs</code> command.</p>
<h2 id="license">license</h2>
<p>You should specify a license for your package so that people know how they are
permitted to use it, and any restrictions you&#39;re placing on it.</p>
<p>The simplest way, assuming you&#39;re using a common license such as BSD or MIT, is
to just specify the name of the license you&#39;re using, like this:</p>
<pre><code>{ &quot;license&quot; : &quot;BSD&quot; }</code></pre>
<p>If you have more complex licensing terms, or you want to provide more detail
in your package.json file, you can use the more verbose plural form, like this:</p>
<pre><code>&quot;licenses&quot; : [
{ &quot;type&quot; : &quot;MyLicense&quot;
, &quot;url&quot; : &quot;http://github.com/owner/project/path/to/license&quot;
}
]</code></pre>
<p>It&#39;s also a good idea to include a license file at the top level in your package.</p>
<h2 id="people-fields-author-contributors">people fields: author, contributors</h2>
<p>The &quot;author&quot; is one person. &quot;contributors&quot; is an array of people. A &quot;person&quot;
@@ -384,9 +405,9 @@ the external test or documentation framework that you use.</p>
<code>devDependencies</code> hash.</p>
<p>These things will be installed whenever the <code>--dev</code> configuration flag
is set. This flag is set automatically when doing <code>npm link</code>, and can
be managed like any other npm configuration param. See <code><a href="../doc/config.html">config(1)</a></code>
for more on the topic.</p>
is set. This flag is set automatically when doing <code>npm link</code> or when doing
<code>npm install</code> from the root of a package, and can be managed like any other npm
configuration param. See <code><a href="../doc/config.html">config(1)</a></code> for more on the topic.</p>
<h2 id="bundledDependencies">bundledDependencies</h2>
@@ -525,7 +546,7 @@ overridden.</p>
<ul><li><a href="../doc/semver.html">semver(1)</a></li><li><a href="../doc/init.html">init(1)</a></li><li><a href="../doc/version.html">version(1)</a></li><li><a href="../doc/config.html">config(1)</a></li><li><a href="../doc/help.html">help(1)</a></li><li><a href="../doc/faq.html">faq(1)</a></li><li><a href="../doc/install.html">install(1)</a></li><li><a href="../doc/publish.html">publish(1)</a></li><li><a href="../doc/rm.html">rm(1)</a></li></ul>
</div>
<p id="footer">json &mdash; npm@1.2.14</p>
<p id="footer">json &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -23,6 +23,9 @@ symbolic link from <code>prefix/package-name</code> to the current folder.</p>
<p>Next, in some other location, <code>npm link package-name</code> will create a
symlink from the local <code>node_modules</code> folder to the global symlink.</p>
<p>Note that <code>package-name</code> is taken from <code>package.json</code> ,
not from directory name.</p>
<p>When creating tarballs for <code>npm publish</code>, the linked packages are
&quot;snapshotted&quot; to their current state by resolving the symbolic links.</p>
@@ -58,7 +61,7 @@ installation target into your project&#39;s <code>node_modules</code> folder.</p
<ul><li><a href="../doc/developers.html">developers(1)</a></li><li><a href="../doc/faq.html">faq(1)</a></li><li><a href="../doc/json.html">json(1)</a></li><li><a href="../doc/install.html">install(1)</a></li><li><a href="../doc/folders.html">folders(1)</a></li><li><a href="../doc/config.html">config(1)</a></li></ul>
</div>
<p id="footer">link &mdash; npm@1.2.14</p>
<p id="footer">link &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -25,7 +25,7 @@ limit the results to only the paths to the packages named. Note that
nested packages will <em>also</em> show the paths to the specified packages.
For example, running <code>npm ls promzard</code> in npm&#39;s source tree will show:</p>
<pre><code>npm@1.2.14 /path/to/npm
<pre><code>npm@1.2.24 /path/to/npm
└─┬ init-package-json@0.0.4
└── promzard@0.1.5</code></pre>
@@ -64,7 +64,7 @@ project.</p>
<ul><li><a href="../doc/config.html">config(1)</a></li><li><a href="../doc/folders.html">folders(1)</a></li><li><a href="../doc/install.html">install(1)</a></li><li><a href="../doc/link.html">link(1)</a></li><li><a href="../doc/prune.html">prune(1)</a></li><li><a href="../doc/outdated.html">outdated(1)</a></li><li><a href="../doc/update.html">update(1)</a></li></ul>
</div>
<p id="footer">ls &mdash; npm@1.2.14</p>
<p id="footer">ls &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -14,7 +14,7 @@
<h2 id="VERSION">VERSION</h2>
<p>1.2.14</p>
<p>1.2.24</p>
<h2 id="DESCRIPTION">DESCRIPTION</h2>
@@ -135,7 +135,7 @@ will no doubt tell you to put the output in a gist or email.</p>
<ul><li><a href="../doc/help.html">help(1)</a></li><li><a href="../doc/faq.html">faq(1)</a></li><li><a href="../doc/README.html">README</a></li><li><a href="../doc/json.html">json(1)</a></li><li><a href="../doc/install.html">install(1)</a></li><li><a href="../doc/config.html">config(1)</a></li><li><a href="../doc/index.html">index(1)</a></li><li><a href="../api/npm.html">npm(3)</a></li></ul>
</div>
<p id="footer">npm &mdash; npm@1.2.14</p>
<p id="footer">npm &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -21,7 +21,7 @@ packages are currently outdated.</p>
<ul><li><a href="../doc/update.html">update(1)</a></li><li><a href="../doc/registry.html">registry(1)</a></li><li><a href="../doc/folders.html">folders(1)</a></li></ul>
</div>
<p id="footer">outdated &mdash; npm@1.2.14</p>
<p id="footer">outdated &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -34,7 +34,7 @@ that is not implemented at this time.</p>
<ul><li><a href="../doc/publish.html">publish(1)</a></li><li><a href="../doc/registry.html">registry(1)</a></li><li><a href="../doc/adduser.html">adduser(1)</a></li><li><a href="../doc/disputes.html">disputes(1)</a></li></ul>
</div>
<p id="footer">owner &mdash; npm@1.2.14</p>
<p id="footer">owner &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -29,7 +29,7 @@ overwritten the second time.</p>
<ul><li><a href="../doc/cache.html">cache(1)</a></li><li><a href="../doc/publish.html">publish(1)</a></li><li><a href="../doc/config.html">config(1)</a></li></ul>
</div>
<p id="footer">pack &mdash; npm@1.2.14</p>
<p id="footer">pack &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -20,7 +20,7 @@
<ul><li><a href="../doc/root.html">root(1)</a></li><li><a href="../doc/bin.html">bin(1)</a></li><li><a href="../doc/folders.html">folders(1)</a></li><li><a href="../doc/config.html">config(1)</a></li></ul>
</div>
<p id="footer">prefix &mdash; npm@1.2.14</p>
<p id="footer">prefix &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -25,7 +25,7 @@ package&#39;s dependencies list.</p>
<ul><li><a href="../doc/rm.html">rm(1)</a></li><li><a href="../doc/folders.html">folders(1)</a></li><li><a href="../doc/list.html">list(1)</a></li></ul>
</div>
<p id="footer">prune &mdash; npm@1.2.14</p>
<p id="footer">prune &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -29,7 +29,7 @@ the registry. Overwrites when the &quot;--force&quot; flag is set.</p>
<ul><li><a href="../doc/registry.html">registry(1)</a></li><li><a href="../doc/adduser.html">adduser(1)</a></li><li><a href="../doc/owner.html">owner(1)</a></li><li><a href="../doc/deprecate.html">deprecate(1)</a></li><li><a href="../doc/tag.html">tag(1)</a></li></ul>
</div>
<p id="footer">publish &mdash; npm@1.2.14</p>
<p id="footer">publish &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -25,7 +25,7 @@ the new binary.</p>
<ul><li><a href="../doc/build.html">build(1)</a></li><li><a href="../doc/install.html">install(1)</a></li></ul>
</div>
<p id="footer">rebuild &mdash; npm@1.2.14</p>
<p id="footer">rebuild &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -95,7 +95,7 @@ ask for help on the <a href="mailto:npm-@googlegroups.com">npm-@googlegroups.com
<ul><li><a href="../doc/config.html">config(1)</a></li><li><a href="../doc/developers.html">developers(1)</a></li><li><a href="../doc/disputes.html">disputes(1)</a></li></ul>
</div>
<p id="footer">registry &mdash; npm@1.2.14</p>
<p id="footer">registry &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -58,7 +58,7 @@ modules. To track those down, you can do the following:</p>
<ul><li><a href="../doc/README.html">README</a></li><li><a href="../doc/rm.html">rm(1)</a></li><li><a href="../doc/prune.html">prune(1)</a></li></ul>
</div>
<p id="footer">removing-npm &mdash; npm@1.2.14</p>
<p id="footer">removing-npm &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -24,7 +24,7 @@ the &quot;start&quot; script.</p>
<ul><li><a href="../doc/run-script.html">run-script(1)</a></li><li><a href="../doc/scripts.html">scripts(1)</a></li><li><a href="../doc/test.html">test(1)</a></li><li><a href="../doc/start.html">start(1)</a></li><li><a href="../doc/stop.html">stop(1)</a></li></ul>
</div>
<p id="footer">restart &mdash; npm@1.2.14</p>
<p id="footer">restart &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -22,7 +22,7 @@ on its behalf.</p>
<ul><li><a href="../doc/prune.html">prune(1)</a></li><li><a href="../doc/install.html">install(1)</a></li><li><a href="../doc/folders.html">folders(1)</a></li><li><a href="../doc/config.html">config(1)</a></li></ul>
</div>
<p id="footer">rm &mdash; npm@1.2.14</p>
<p id="footer">rm &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -20,7 +20,7 @@
<ul><li><a href="../doc/prefix.html">prefix(1)</a></li><li><a href="../doc/bin.html">bin(1)</a></li><li><a href="../doc/folders.html">folders(1)</a></li><li><a href="../doc/config.html">config(1)</a></li></ul>
</div>
<p id="footer">root &mdash; npm@1.2.14</p>
<p id="footer">root &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -23,7 +23,7 @@ called directly, as well.</p>
<ul><li><a href="../doc/scripts.html">scripts(1)</a></li><li><a href="../doc/test.html">test(1)</a></li><li><a href="../doc/start.html">start(1)</a></li><li><a href="../doc/restart.html">restart(1)</a></li><li><a href="../doc/stop.html">stop(1)</a></li></ul>
</div>
<p id="footer">run-script &mdash; npm@1.2.14</p>
<p id="footer">run-script &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -218,7 +218,7 @@ will sudo the npm command in question.</li></ul>
<ul><li><a href="../doc/run-script.html">run-script(1)</a></li><li><a href="../doc/json.html">json(1)</a></li><li><a href="../doc/developers.html">developers(1)</a></li><li><a href="../doc/install.html">install(1)</a></li></ul>
</div>
<p id="footer">scripts &mdash; npm@1.2.14</p>
<p id="footer">scripts &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -24,7 +24,7 @@ expression characters must be escaped or quoted in most shells.)</p>
<ul><li><a href="../doc/registry.html">registry(1)</a></li><li><a href="../doc/config.html">config(1)</a></li><li><a href="../doc/view.html">view(1)</a></li></ul>
</div>
<p id="footer">search &mdash; npm@1.2.14</p>
<p id="footer">search &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -104,7 +104,7 @@ that satisfies the range, or null if none of them do.</li></ul>
<ul><li><a href="../doc/json.html">json(1)</a></li></ul>
</div>
<p id="footer">semver &mdash; npm@1.2.14</p>
<p id="footer">semver &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -14,68 +14,72 @@
<h2 id="DESCRIPTION">DESCRIPTION</h2>
<p>This command locks down the versions of a package&#39;s dependencies so that you can
control exactly which versions of each dependency will be used when your package
is installed.</p>
<p>This command locks down the versions of a package&#39;s dependencies so
that you can control exactly which versions of each dependency will be
used when your package is installed. The &quot;package.json&quot; file is still
required if you want to use &quot;npm install&quot;.</p>
<p>By default, &quot;npm install&quot; recursively installs the target&#39;s dependencies (as
specified in package.json), choosing the latest available version that satisfies
the dependency&#39;s semver pattern. In some situations, particularly when shipping
software where each change is tightly managed, it&#39;s desirable to fully specify
each version of each dependency recursively so that subsequent builds and
deploys do not inadvertently pick up newer versions of a dependency that satisfy
the semver pattern. Specifying specific semver patterns in each dependency&#39;s
package.json would facilitate this, but that&#39;s not always possible or desirable,
as when another author owns the npm package. It&#39;s also possible to check
dependencies directly into source control, but that may be undesirable for other
reasons.</p>
<p>By default, &quot;npm install&quot; recursively installs the target&#39;s
dependencies (as specified in package.json), choosing the latest
available version that satisfies the dependency&#39;s semver pattern. In
some situations, particularly when shipping software where each change
is tightly managed, it&#39;s desirable to fully specify each version of
each dependency recursively so that subsequent builds and deploys do
not inadvertently pick up newer versions of a dependency that satisfy
the semver pattern. Specifying specific semver patterns in each
dependency&#39;s package.json would facilitate this, but that&#39;s not always
possible or desirable, as when another author owns the npm package.
It&#39;s also possible to check dependencies directly into source control,
but that may be undesirable for other reasons.</p>
<p>As an example, consider package A:</p>
<pre><code>{
&quot;name&quot;: &quot;A&quot;,
&quot;version&quot;: &quot;0.1.0&quot;,
&quot;dependencies&quot;: {
&quot;B&quot;: &quot;&lt;0.1.0&quot;
}
&quot;name&quot;: &quot;A&quot;,
&quot;version&quot;: &quot;0.1.0&quot;,
&quot;dependencies&quot;: {
&quot;B&quot;: &quot;&lt;0.1.0&quot;
}
}</code></pre>
<p>package B:</p>
<pre><code>{
&quot;name&quot;: &quot;B&quot;,
&quot;version&quot;: &quot;0.0.1&quot;,
&quot;dependencies&quot;: {
&quot;C&quot;: &quot;&lt;0.1.0&quot;
}
&quot;name&quot;: &quot;B&quot;,
&quot;version&quot;: &quot;0.0.1&quot;,
&quot;dependencies&quot;: {
&quot;C&quot;: &quot;&lt;0.1.0&quot;
}
}</code></pre>
<p>and package C:</p>
<pre><code>{
&quot;name&quot;: &quot;C,
&quot;version&quot;: &quot;0.0.1&quot;
&quot;name&quot;: &quot;C,
&quot;version&quot;: &quot;0.0.1&quot;
}</code></pre>
<p>If these are the only versions of A, B, and C available in the registry, then
a normal &quot;npm install A&quot; will install:</p>
<p>If these are the only versions of A, B, and C available in the
registry, then a normal &quot;npm install A&quot; will install:</p>
<pre><code>A@0.1.0
`-- B@0.0.1
`-- C@0.0.1</code></pre>
<p>However, if B@0.0.2 is published, then a fresh &quot;npm install A&quot; will install:</p>
<p>However, if B@0.0.2 is published, then a fresh &quot;npm install A&quot; will
install:</p>
<pre><code>A@0.1.0
`-- B@0.0.2
`-- C@0.0.1</code></pre>
<p>assuming the new version did not modify B&#39;s dependencies. Of course, the new
version of B could include a new version of C and any number of new
dependencies. If such changes are undesirable, the author of A could specify a
dependency on B@0.0.1. However, if A&#39;s author and B&#39;s author are not the same
person, there&#39;s no way for A&#39;s author to say that he or she does not want to
pull in newly published versions of C when B hasn&#39;t changed at all.</p>
<p>assuming the new version did not modify B&#39;s dependencies. Of course,
the new version of B could include a new version of C and any number
of new dependencies. If such changes are undesirable, the author of A
could specify a dependency on B@0.0.1. However, if A&#39;s author and B&#39;s
author are not the same person, there&#39;s no way for A&#39;s author to say
that he or she does not want to pull in newly published versions of C
when B hasn&#39;t changed at all.</p>
<p>In this case, A&#39;s author can run</p>
@@ -98,78 +102,88 @@ pull in newly published versions of C when B hasn&#39;t changed at all.</p>
}
}</code></pre>
<p>The shrinkwrap command has locked down the dependencies based on what&#39;s
currently installed in node_modules. When &quot;npm install&quot; installs a package with
a npm-shrinkwrap.json file in the package root, the shrinkwrap file (rather than
package.json files) completely drives the installation of that package and all
of its dependencies (recursively). So now the author publishes A@0.1.0, and
subsequent installs of this package will use B@0.0.1 and C@0.1.0, regardless the
dependencies and versions listed in A&#39;s, B&#39;s, and C&#39;s package.json files.</p>
<p>The shrinkwrap command has locked down the dependencies based on
what&#39;s currently installed in node_modules. When &quot;npm install&quot;
installs a package with a npm-shrinkwrap.json file in the package
root, the shrinkwrap file (rather than package.json files) completely
drives the installation of that package and all of its dependencies
(recursively). So now the author publishes A@0.1.0, and subsequent
installs of this package will use B@0.0.1 and C@0.1.0, regardless the
dependencies and versions listed in A&#39;s, B&#39;s, and C&#39;s package.json
files.</p>
<h3 id="Using-shrinkwrapped-packages">Using shrinkwrapped packages</h3>
<p>Using a shrinkwrapped package is no different than using any other package: you
can &quot;npm install&quot; it by hand, or add a dependency to your package.json file and
&quot;npm install&quot; it.</p>
<p>Using a shrinkwrapped package is no different than using any other
package: you can &quot;npm install&quot; it by hand, or add a dependency to your
package.json file and &quot;npm install&quot; it.</p>
<h3 id="Building-shrinkwrapped-packages">Building shrinkwrapped packages</h3>
<p>To shrinkwrap an existing package:</p>
<ol><li>Run &quot;npm install&quot; in the package root to install the current versions of all
dependencies.</li><li>Validate that the package works as expected with these versions.</li><li>Run &quot;npm shrinkwrap&quot;, add npm-shrinkwrap.json to git, and publish your
package.</li></ol>
<ol><li>Run &quot;npm install&quot; in the package root to install the current
versions of all dependencies.</li><li>Validate that the package works as expected with these versions.</li><li>Run &quot;npm shrinkwrap&quot;, add npm-shrinkwrap.json to git, and publish
your package.</li></ol>
<p>To add or update a dependency in a shrinkwrapped package:</p>
<ol><li>Run &quot;npm install&quot; in the package root to install the current versions of all
dependencies.</li><li>Add or update dependencies. &quot;npm install&quot; each new or updated package
individually and then update package.json. Note that they must be
explicitly named in order to be installed: running <code>npm install</code> with
no arguments will merely reproduce the existing shrinkwrap.</li><li>Validate that the package works as expected with the new dependencies.</li><li>Run &quot;npm shrinkwrap&quot;, commit the new npm-shrinkwrap.json, and publish your
package.</li></ol>
<ol><li>Run &quot;npm install&quot; in the package root to install the current
versions of all dependencies.</li><li>Add or update dependencies. &quot;npm install&quot; each new or updated
package individually and then update package.json. Note that they
must be explicitly named in order to be installed: running <code>npm
install</code> with no arguments will merely reproduce the existing
shrinkwrap.</li><li>Validate that the package works as expected with the new
dependencies.</li><li>Run &quot;npm shrinkwrap&quot;, commit the new npm-shrinkwrap.json, and
publish your package.</li></ol>
<p>You can use <a href="../doc/outdated.html">outdated(1)</a> to view dependencies with newer versions available.</p>
<p>You can use <a href="../doc/outdated.html">outdated(1)</a> to view dependencies with newer versions
available.</p>
<h3 id="Other-Notes">Other Notes</h3>
<p>Since &quot;npm shrinkwrap&quot; uses the locally installed packages to construct the
shrinkwrap file, devDependencies will be included if and only if you&#39;ve
installed them already when you make the shrinkwrap.</p>
<p>A shrinkwrap file must be consistent with the package&#39;s package.json
file. &quot;npm shrinkwrap&quot; will fail if required dependencies are not
already installed, since that would result in a shrinkwrap that
wouldn&#39;t actually work. Similarly, the command will fail if there are
extraneous packages (not referenced by package.json), since that would
indicate that package.json is not correct.</p>
<p>A shrinkwrap file must be consistent with the package&#39;s package.json file. &quot;npm
shrinkwrap&quot; will fail if required dependencies are not already installed, since
that would result in a shrinkwrap that wouldn&#39;t actually work. Similarly, the
command will fail if there are extraneous packages (not referenced by
package.json), since that would indicate that package.json is not correct.</p>
<p>Since &quot;npm shrinkwrap&quot; is intended to lock down your dependencies for
production use, <code>devDependencies</code> will not be included unless you
explicitly set the <code>--dev</code> flag when you run <code>npm shrinkwrap</code>. If
installed <code>devDependencies</code> are excluded, then npm will print a
warning. If you want them to be installed with your module by
default, please consider adding them to <code>dependencies</code> instead.</p>
<p>If shrinkwrapped package A depends on shrinkwrapped package B, B&#39;s shrinkwrap
will not be used as part of the installation of A. However, because A&#39;s
shrinkwrap is constructed from a valid installation of B and recursively
specifies all dependencies, the contents of B&#39;s shrinkwrap will implicitly be
included in A&#39;s shrinkwrap.</p>
<p>If shrinkwrapped package A depends on shrinkwrapped package B, B&#39;s
shrinkwrap will not be used as part of the installation of A. However,
because A&#39;s shrinkwrap is constructed from a valid installation of B
and recursively specifies all dependencies, the contents of B&#39;s
shrinkwrap will implicitly be included in A&#39;s shrinkwrap.</p>
<h3 id="Caveats">Caveats</h3>
<p>Shrinkwrap files only lock down package versions, not actual package contents.
While discouraged, a package author can republish an existing version of a
package, causing shrinkwrapped packages using that version to pick up different
code than they were before. If you want to avoid any risk that a byzantine
author replaces a package you&#39;re using with code that breaks your application,
you could modify the shrinkwrap file to use git URL references rather than
version numbers so that npm always fetches all packages from git.</p>
<p>Shrinkwrap files only lock down package versions, not actual package
contents. While discouraged, a package author can republish an
existing version of a package, causing shrinkwrapped packages using
that version to pick up different code than they were before. If you
want to avoid any risk that a byzantine author replaces a package
you&#39;re using with code that breaks your application, you could modify
the shrinkwrap file to use git URL references rather than version
numbers so that npm always fetches all packages from git.</p>
<p>If you wish to lock down the specific bytes included in a package, for
example to have 100% confidence in being able to reproduce a deployment
or build, then you ought to check your dependencies into source control,
or pursue some other mechanism that can verify contents rather than
versions.</p>
example to have 100% confidence in being able to reproduce a
deployment or build, then you ought to check your dependencies into
source control, or pursue some other mechanism that can verify
contents rather than versions.</p>
<h2 id="SEE-ALSO">SEE ALSO</h2>
<ul><li><a href="../doc/install.html">install(1)</a></li><li><a href="../doc/json.html">json(1)</a></li><li><a href="../doc/list.html">list(1)</a></li></ul>
</div>
<p id="footer">shrinkwrap &mdash; npm@1.2.14</p>
<p id="footer">shrinkwrap &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

View File

@@ -26,7 +26,7 @@ a vaguely positive way to show that you care.</p>
<ul><li><a href="../doc/view.html">view(1)</a></li><li><a href="../doc/whoami.html">whoami(1)</a></li><li><a href="../doc/adduser.html">adduser(1)</a></li></ul>
</div>
<p id="footer">star &mdash; npm@1.2.14</p>
<p id="footer">star &mdash; npm@1.2.24</p>
<script>
;(function () {
var wrapper = document.getElementById("wrapper")

Some files were not shown because too many files have changed in this diff Show More