Skip to content

Commit

Permalink
deps: upgrade npm to 2.9.1
Browse files Browse the repository at this point in the history
Reviewed-By: Julien Gilli <[email protected]>
PR-URL: nodejs#25289
  • Loading branch information
othiym23 authored and Julien Gilli committed May 13, 2015
1 parent 101e103 commit 03cfbd6
Show file tree
Hide file tree
Showing 288 changed files with 2,276 additions and 1,137 deletions.
3 changes: 3 additions & 0 deletions deps/npm/AUTHORS
Original file line number Diff line number Diff line change
Expand Up @@ -271,3 +271,6 @@ Michiel Sikma <[email protected]>
Jakob Krigovsky <[email protected]>
Charmander <[email protected]>
erik wienhold <[email protected]>
James Butler <[email protected]>
Kevin Kragenbrink <[email protected]>
Arnaud Rinquin <[email protected]>
146 changes: 146 additions & 0 deletions deps/npm/CHANGELOG.md
Original file line number Diff line number Diff line change
@@ -1,3 +1,149 @@
### v2.9.1 (2015-04-30):

#### WOW! MORE GIT FIXES! YOU LOVE THOSE!

The first item below is actually a pretty big deal, as it fixes (with a
one-word change and a much, much longer test case (thanks again,
[@iarna](https://github.com/iarna))) a regression that's been around for months
now. If you're depending on multiple branches of a single git dependency in a
single project, you probably want to check out `[email protected]` and verify that
things (again?) work correctly in your project.

* [`178a6ad`](https://github.com/npm/npm/commit/178a6ad540215820d16217465a5f220d8c95a313)
[#7202](https://github.com/npm/npm/issues/7202) When caching git
dependencies, do so by the whole URL, including the branch name, so that if a
single application depends on multiple branches from the same repository (in
practice, multiple version tags), every install is of the correct version,
instead of reusing whichever branch the caching process happened to check out
first. ([@iarna](https://github.com/iarna))
* [`63b79cc`](https://github.com/npm/npm/commit/63b79ccde092a9cb3b1f34abe43e1d2ba69c0dbf)
[#8084](https://github.com/npm/npm/issues/8084) Ensure that Bitbucket,
GitHub, and Gitlab dependencies are installed the same way as non-hosted git
dependencies, fixing `npm install --link`.
([@laiso](https://github.com/laiso))

#### DOCUMENTATION FIXES AND TWEAKS

These changes may seem simple and small (except Lin's fix to the package name
restrictions, which was more an egregious oversight on our part), but cleaner
documentation makes npm significantly more pleasant to use. I really appreciate
all the typo fixes, clarifications, and formatting tweaks people send us, and
am delighted that we get so many of these pull requests. Thanks, everybody!

* [`ca478dc`](https://github.com/npm/npm/commit/ca478dcaa29b8f07cd6fe515a3c4518166819291)
[#8137](https://github.com/npm/npm/issues/8137) Somehow, we had failed to
clearly document the full restrictions on package names.
[@linclark](https://github.com/linclark) has now fixed that, although we will
take with us to our graves the reasons why the maximum package name length is 214
characters (well, OK, it was that that was the longest name in the registry
when we decided to put a cap on the name length).
([@linclark](https://github.com/linclark))
* [`b574076`](https://github.com/npm/npm/commit/b5740767c320c1eff3576a8d63952534a0fbb936)
[#8079](https://github.com/npm/npm/issues/8079) Make the `npm shrinkwrap`
documentation use code formatting for examples consistently. It would be
great to do this for more commands HINT HINT.
([@RichardLitt](https://github.com/RichardLitt))
* [`1ff636e`](https://github.com/npm/npm/commit/1ff636e2db3852a53e38c866fed7eafdacd307fc)
[#8105](https://github.com/npm/npm/issues/8105) Document that the global
`npmrc` goes in `$PREFIX/etc/npmrc`, instead of `$PREFIX/npmrc`.
([@anttti](https://github.com/anttti))
* [`c3f2f7c`](https://github.com/npm/npm/commit/c3f2f7c299342e1c1eccc55a976a63c607f51621)
[#8127](https://github.com/npm/npm/issues/8127) Document how to use `npm run
build` directly (hint: it's different from `npm build`!).
([@mikemaccana](https://github.com/mikemaccana))
* [`873e467`](https://github.com/npm/npm/commit/873e46757e1986761b15353f94580a071adcb383)
[#8069](https://github.com/npm/npm/issues/8069) Take the old, dead npm
mailing list address out of `package.json`. It seems that people don't have
much trouble figuring out how to report errors to npm.
([@robertkowalski](https://github.com/robertkowalski))

#### ENROBUSTIFICATIONMENT

* [`5abfc9c`](https://github.com/npm/npm/commit/5abfc9c9017da714e47a3aece750836b4f9af6a9)
[#7973](https://github.com/npm/npm/issues/7973) `npm run-script` completion
will only suggest run scripts, instead of including dependencies. If for some
reason you still wanted it to suggest dependencies, let us know.
([@mantoni](https://github.com/mantoni))
* [`4b564f0`](https://github.com/npm/npm/commit/4b564f0ce979dc74c09604f4d46fd25a2ee63804)
[#8081](https://github.com/npm/npm/issues/8081) Use `osenv` to parse the
environment's `PATH` in a platform-neutral way.
([@watilde](https://github.com/watilde))
* [`a4b6238`](https://github.com/npm/npm/commit/a4b62387b41848818973eeed056fd5c6570274f3)
[#8094](https://github.com/npm/npm/issues/8094) When we refactored the
configuration code to split out checking for IPv4 local addresses, we
inadvertently completely broke it by failing to return the values. In
addition, just the call to `os.getInterfaces()` could throw on systems where
querying the network configuration requires elevated privileges (e.g. Amazon
Lambda). Add the return, and trap errors so they don't cause npm to explode.
Thanks to [@mhart](https://github.com/mhart) for bringing this to our
attention! ([@othiym23](https://github.com/othiym23))

#### DEPENDENCY UPDATES WAIT FOR NO SOPHONT

* [`000cd8b`](https://github.com/npm/npm/commit/000cd8b52104942ac3404f0ad0651d82f573da37)
`[email protected]`: More informative assertions on argument validation failure.
([@isaacs](https://github.com/isaacs))
* [`530a2e3`](https://github.com/npm/npm/commit/530a2e369128270f3e098f0e9be061533003b0eb)
`[email protected]`: Revert to old key access-time behavior, as it was correct
all along. ([@isaacs](https://github.com/isaacs))
* [`d88958c`](https://github.com/npm/npm/commit/d88958ca02ce81b027b9919aec539d0145875a59)
`[email protected]`: Feature detection and test improvements.
([@isaacs](https://github.com/isaacs))
* [`3fa39e4`](https://github.com/npm/npm/commit/3fa39e4d492609d5d045033896dcd99f7b875329)
`[email protected]` ([@pgte](https://github.com/pgte))

### v2.9.0 (2015-04-23):

This week was kind of a breather to concentrate on fixing up the tests on the
`multi-stage` branch, and not mess with git issues for a little while.
Unfortunately, There are now enough severe git issues that we'll probably have
to spend another couple weeks tackling them. In the meantime, enjoy these two
small features. They're just enough to qualify for a semver-minor bump:

#### NANOFEATURES

* [`2799322`](https://github.com/npm/npm/commit/279932298ce5b589c5eea9439ac40b88b99c6a4a)
[#7426](https://github.com/npm/npm/issues/7426) Include local modules in `npm
outdated` and `npm update`. ([@ArnaudRinquin](https://github.com/ArnaudRinquin))
* [`2114862`](https://github.com/npm/npm/commit/21148620fa03a582f4ec436bb16bd472664f2737)
[#8014](https://github.com/npm/npm/issues/8014) The prefix used before the
version on version tags is now configurable via `tag-version-prefix`. Be
careful with this one and read the docs before using it.
([@kkragenbrink](https://github.com/kkragenbrink))

#### OTHER MINOR TWEAKS

* [`18ce0ec`](https://github.com/npm/npm/commit/18ce0ecd2d94ad3af01e997f1396515892dd363c)
[#3032](https://github.com/npm/npm/issues/3032) `npm unpublish` will now use
the registry set in `package.json`, just like `npm publish`. This only
applies, for now, when unpublishing the entire package, as unpublishing a
single version requires the name be included on the command line and
therefore doesn't read from `package.json`. ([@watilde](https://github.com/watilde))
* [`9ad2100`](https://github.com/npm/npm/commit/9ad210042242e51d52b2a8b633d8e59248f5faa4)
[#8008](https://github.com/npm/npm/issues/8008) Once again, when considering
what to install on `npm install`, include `devDependencies`.
([@smikes](https://github.com/smikes))
* [`5466260`](https://github.com/npm/npm/commit/546626059909dca1906454e820ca4e315c1795bd)
[#8003](https://github.com/npm/npm/issues/8003) Clarify the documentation
around scopes to make it easier to understand how they support private
packages. ([@smikes](https://github.com/smikes))

#### DEPENDENCIES WILL NOT STOP UNTIL YOU ARE VERY SLEEPY

* [`faf65a7`](https://github.com/npm/npm/commit/faf65a7bbb2fad13216f64ed8f1243bafe743f97)
`[email protected]`: If there are multiple validation errors and
warnings, ensure they all get displayed (includes a rad new way of testing
`init-package-json` contributed by
[@michaelnisi](https://github.com/michaelnisi)).
([@MisumiRize](https://github.com/MisumiRize))
* [`7f10f38`](https://github.com/npm/npm/commit/7f10f38d29a8423d7cde8103fa7b64ac728da1e0)
`[email protected]`: `1.0.0` is literally more than `0.1.0` (no change aside from
version number). ([@substack](https://github.com/substack))
* [`4979af3`](https://github.com/npm/npm/commit/4979af3fcae5a3962383b7fdad3162381e62eefe)
[#6805](https://github.com/npm/npm/issues/6805) `[email protected]`:
Decode scoped package names sent by the registry so they look nicer.
([@mmalecki](https://github.com/mmalecki))

### v2.8.4 (2015-04-16):

This is the fourth release of npm this week, so it's mostly just landing a few
Expand Down
2 changes: 1 addition & 1 deletion deps/npm/Makefile
Original file line number Diff line number Diff line change
Expand Up @@ -235,7 +235,7 @@ authors:
git add AUTHORS &&\
git commit -m "update AUTHORS" || true

publish: link doc authors
publish: authors link doc
@git push origin :v$(shell npm -v) 2>&1 || true
git clean -fd &&\
git push origin $(BRANCH) &&\
Expand Down
5 changes: 4 additions & 1 deletion deps/npm/doc/cli/npm-build.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,10 @@ npm-build(1) -- Build a package

This is the plumbing command called by `npm link` and `npm install`.

It should generally not be called directly.
It should generally be called during installation, but if you need to run it
directly, run:

npm run-script build

## SEE ALSO

Expand Down
30 changes: 15 additions & 15 deletions deps/npm/doc/cli/npm-shrinkwrap.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,10 +9,10 @@ npm-shrinkwrap(1) -- Lock down dependency versions

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".
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
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
Expand Down Expand Up @@ -53,13 +53,13 @@ and package C:
}

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

[email protected]
`-- [email protected]
`-- [email protected]

However, if [email protected] is published, then a fresh "npm install A" will
However, if [email protected] is published, then a fresh `npm install A` will
install:

[email protected]
Expand Down Expand Up @@ -96,7 +96,7 @@ 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"
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
Expand All @@ -109,31 +109,31 @@ 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.
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
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
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
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
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
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
Expand All @@ -142,13 +142,13 @@ available.
### Other Notes

A shrinkwrap file must be consistent with the package's package.json
file. "npm shrinkwrap" will fail if required dependencies are not
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
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
Expand Down
2 changes: 1 addition & 1 deletion deps/npm/doc/files/npmrc.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,7 @@ The four relevant files are:

* per-project config file (/path/to/my/project/.npmrc)
* per-user config file (~/.npmrc)
* global config file ($PREFIX/npmrc)
* global config file ($PREFIX/etc/npmrc)
* npm builtin config file (/path/to/npm/npmrc)

All npm config files are an ini-formatted list of `key = value`
Expand Down
17 changes: 13 additions & 4 deletions deps/npm/doc/files/package.json.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,14 +17,23 @@ them. The name and version together form an identifier that is assumed
to be completely unique. Changes to the package should come along with
changes to the version.

The name is what your thing is called. Some tips:
The name is what your thing is called.

Some rules:

* The name must be shorter than 214 characters. This includes the scope for
scoped packages.
* The name can't start with a dot or an underscore.
* New packages must not have uppercase letters in the name.
* The name ends up being part of a URL, an argument on the command line, and a
folder name. Therefore, the name can't contain any non-URL-safe characters.

Some tips:

* Don't use the same name as a core Node module.
* Don't put "js" or "node" in the name. It's assumed that it's js, since you're
writing a package.json file, and you can specify the engine using the "engines"
field. (See below.)
* The name ends up being part of a URL, an argument on the command line, and a
folder name. Any name with non-url-safe characters will be rejected.
Also, it can't start with a dot or an underscore.
* The name will probably be passed as an argument to require(), so it should
be something short, but also reasonably descriptive.
* You may want to check the npm registry to see if there's something by that name
Expand Down
13 changes: 13 additions & 0 deletions deps/npm/doc/misc/npm-config.md
Original file line number Diff line number Diff line change
Expand Up @@ -804,6 +804,19 @@ it will install the specified tag.
Also the tag that is added to the package@version specified by the `npm
tag` command, if no explicit tag is given.

### tag-version-prefix

* Default: `"v"`
* Type: String

If set, alters the prefix used when tagging a new version when performing a
version increment using `npm-version`. To remove the prefix altogether, set it
to the empty string: `""`.

Because other tools may rely on the convention that npm version tags look like
`v1.0.0`, _only use this property if it is absolutely necessary_. In
particular, use care when overriding this setting for public packages.

### tmp

* Default: TMPDIR environment variable, or "/tmp"
Expand Down
36 changes: 28 additions & 8 deletions deps/npm/doc/misc/npm-scope.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,9 +13,9 @@ followed by a slash, e.g.
Scopes are a way of grouping related packages together, and also affect a few
things about the way npm treats the package.

**As of 2014-09-03, scoped packages are not supported by the public npm registry**.
However, 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.
Scoped packages are supported by the public 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.

## Installing scoped packages

Expand Down Expand Up @@ -51,10 +51,29 @@ just specifying to require the module `mypackage` in the folder called `@myorg`.

## Publishing scoped packages

Scoped packages can be published to any registry that supports them.
*As of 2014-09-03, the public npm registry does not support scoped packages*,
so attempting to publish a scoped package to the registry will fail unless
you have associated that scope with a different registry, see below.
Scoped packages can be published to any registry that supports them, including
the public npm registry.

(As of 2015-04-19, the public npm registry **does** support scoped packages)

If you wish, you may associate a scope with a registry; see below.

### Publishing public scoped packages to the public npm registry

To publish a public scoped package, you must specify `--access public` with
the initial publication. This will publish the package and set access
to `public` as if you had run `npm access public` after publishing.

### Publishing private scoped packages to the npm registry

To publish a private scoped package to the npm registry, you must have
an [npm Private Modules](https://www.npmjs.com/private-modules)
account.

You can then publish the module with `npm publish` or `npm publish
--access restricted`, and it will be present in the npm registry, with
restricted access. You can then change the access permissions, if
desired, with `npm access` or on the npmjs.com website.

## Associating a scope with a registry

Expand All @@ -81,4 +100,5 @@ that registry instead.
## SEE ALSO

* npm-install(1)
* npm-publish(1)
* npm-publish(1)
* npm-access(1)
Loading

0 comments on commit 03cfbd6

Please sign in to comment.