lukechilds
/
node
mirror of https://github.com/lukechilds/node.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
12290 Commits
131 Branches
446 Tags
325 MiB
 
 
 
 
 
 
Tree: ead5cd990c
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'ead5cd990c'
${ noResults }
node/deps/npm/CHANGELOG.md

233 KiB
Raw Blame History

v2.14.4 (2015-09-10):

THE GREAT NODEv4 SAGA

So Node 4 is out now and that's going to involve a number of things over in npm land. Most importantly, it's the last major release that will include the 2.x branch of npm. That also means that 2.x is going to go into LTS mode in the coming weeks -- once npm@3 becomes our official latest release. You can most likely expect Node 5 to include npm@3 by default, whenever that happens. We'll go into more detail about LTS at that point, as well, so keep your eyes peeled for announcements!

NODE IS DEAD. LONG LIVE NODE!

Node 4 being released means that a few things that used to be floating patches are finally making it right into npm proper. This week, we've got two such updates, both to dependencies:

  • 505d9e4 node-gyp@3.0.1: Support for node nightlies and compilation for both node and io.js without extra patching (@rvagg)

@thefourtheye was kind enough to submit a bunch of PRs to npm's dependencies updating them to graceful-fs@4.1.2, which mainly makes it so we're no longer monkey-patching fs. The following are all updates related to this:

OTHER PATCHES

MORE DEPENDENCIES!

  • d940594 tap@1.4.1 (@isaacs)
  • ee38486 which@1.1.2: Added tests for Windows-related dead code that was previously helping a silent failure happen. Travis stuff, too. (@isaacs)

DOC UPDATES

  • 475daf5 #9492 Clarify how .npmignore and .gitignore are found and used by npm. (@addaleax)
  • b2c391d nopt@3.0.4: Minor clarifications to docs about how array and errors work. (@zkat)

v2.14.3 (2015-09-03):

TEAMS AND ORGS STILL BETA. CLI CODE STILL SOLID.

Our closed beta for Teens and Orcs is happening! The web team is hard at work making sure everything looks pretty and usable and such. Once we fix things stemming from that beta, you can expect the feature to be available publicly. Some time after that, it'll even be available for free for FOSS orgs. It'll Be Done When It's Done™.

OH GOOD, I CAN ACTUALLY UPSTREAM NOW

Looks like last week's release foiled our own test suite when trying to upstream it to Node! Just a friendly reminder that no, .npmrc is no longer included then you pack/release a package! @othiym23 and @isaacs managed to suss the really strange test failures resulting from that, and we've patched it in this release.

  • 01a3428 #9476 test: Recreate missing .npmrc files when missing so downstream packagers can run tests on packed npm. (@othiym23)

TALKING ABOUT THE CHANGELOG IN THE CHANGELOG IS LIKE, POMO OR SOMETHING

devDependencies UPDATED

No actual dep updates this week, but we're bumping a couple of devDeps:

  • 8454835 tap@1.4.0: Add t.contains() as alias to t.match() (@isaacs)
  • 13d2216 deep-equal@1.0.1: Make null == undefined in non-strict mode (@isaacs)

v2.14.2 (2015-08-27):

GETTING THAT PESKY preferGlobal WARNING RIGHT

So apparently the preferGlobal option hasn't quite been warning correctly for some time. But now it should be all better! tl;dr: if you try and install a dependency with preferGlobal: true, and it's not already in your package.json, you'll get a warning that the author would really rather you install it with --global. This should prevent Windows PowerShell from thinking npm has failed just because of a benign warning.

  • bbb25f3 #8841 #9409 The preferGlobal warning shouldn't happen if the dependency being installed is listed in devDependencies. (@saper)
  • 222fcec #9409 preferGlobal now prints a warning when there are no dependencies for the current package. (@zkat)
  • 5cfed6d #9409 Verify that preferGlobal is warning as expected (when a preferGlobal dependency is installed, but isn't listed in either dependencies or devDependencies). (@zkat)

BUMP +1

  • eeafce2 validate-npm-package-license@3.0.1: Include additional metadata in parsed license object, useful for license checkers. (@kemitchell)
  • 1502a28 normalise-package-data@2.3.2: Updated to use validate-npm-package-license@3.0.1. (@othiym23)
  • cbde823 init-package-json@1.9.1: Add a silent option to suppress output on writing the generated package.json. Also, updated to use validate-npm-package-license@3.0.1. (@zkat)
  • 08fda46 tar@2.2.0: Minor improvements. (@othiym23)
  • dc2f20b rimraf@2.4.3: EPERM now triggers a delay / retry loop (since Windows throws this when things still hold a handle). (@isaacs)
  • e8acb27 read@1.0.7: Fix licensing ambiguity. (@isaacs)

OTHER STUFF THAT'S RELEVANT

  • 73a1ee0 #9386 Include additional unignorable files in documentation. (@mjhasbach)
  • 0313e40 #9396 Improve the EISDIR error message returned by npm's error-handling code to give users a better hint of what's most likely going on. Usually, error reports with this error code are about people trying to install things without a package.json. (@KenanY)
  • 2677457 #9360 Make it easier to run only some of npm tests with lifecycle scripts via npm tap test/tap/testname.js. (@iarna)

v2.14.1 (2015-08-20):

SECURITY FIX

There are patches for two information leaks of moderate severity in npm@2.14.1:

  1. In some cases, npm was leaking sensitive credential information into the child environment when running package and lifecycle scripts. This could lead to packages being published with files (most notably config.gypi, a file created by node-gyp that is a cache of environmental information regenerated on every run) containing the bearer tokens used to authenticate users to the registry. Users with affected packages have been notified (and the affected tokens invalidated), and now npm has been modified to not upload files that could contain this information, as well as scrubbing the sensitive information out of the environment passed to child scripts.
  2. Per-package .npmrc files are used by some maintainers as a way to scope those packages to a specific registry and its credentials. This is a reasonable use case, but by default .npmrc was packed into packages, leaking those credentials. npm will no longer include .npmrc when packing tarballs.

If you maintain packages and believe you may be affected by either of the above scenarios (especially if you've received a security notification from npm recently), please upgrade to npm@2.14.1 as soon as possible. If you believe you may have inadvertently leaked your credentials, upgrade to npm@2.14.1 on the affected machine, and run npm logout and then npm login. Your access tokens will be invalidated, which will eliminate any risk posed by tokens inadvertently included in published packages. We apologize for the inconvenience this causes, as well as the oversight that led to the existence of this issue in the first place.

Huge thanks to @ChALkeR for bringing these issues to our attention, and for helping us identify affected packages and maintainers. Thanks also to the Node.js security working group for their coördination with the team in our response to this issue. We appreciate everybody's patience and understanding tremendously.

  • b9474a8 fstream-npm@1.0.5: Stop publishing build cruft (config.gypi) and per-project .npmrc files to keep local configuration out of published packages. (@othiym23)
  • 13c286d #9348 Filter "private" (underscore-prefixed, even when scoped to a registry) configuration values out of child environments. (@othiym23)

BETTER WINDOWS INTEGRATION, ONE STEP AT A TIME

  • e40e71f #6412 Improve the search strategy used by the npm shims for Windows to prioritize your own local npm installs. npm has really needed this tweak for a long time, so hammer on it and let us know if you run into issues, but with luck it will Just Work. (@joaocgreis)
  • 204ebbb #8751 #7333 Keep autorun scripts from interfering with npm package and lifecycle script execution on Windows by adding /d and /s when invoking cmd.exe. (@saper)

IT SEEMED LIKE AN IDEA AT THE TIME

  • 286f3d9 #9201 For a while npm was building HTML partials for use on docs.npmjs.com, but we weren't actually using them. Stop building them, which makes running the full test suite and installation process around a third faster. (@isaacs)

A SINGLE LONELY DEPENDENCY UPGRADE

  • b343b95 request@2.61.0: Bug fixes and keep-alive tweaks. (@simov)

v2.14.0 (2015-08-13):

IT'S HERE! KINDA!

This release adds support for teens and orcs (err, teams and organizations) to the npm CLI! Note that the web site and registry-side features of this are still not ready for public consumption.

A beta should be starting in the next couple of weeks, and the features themselves will become public once all that's done. Keep an eye out for more news!

All of these changes were done under #9011:

  • 6424170 Added new npm team command and subcommands. (@zkat)
  • 52220d1 Added documentation for new npm team command. (@zkat)
  • 4e66830 Updated npm access to support teams and organizations. (@zkat)
  • ea3eb87 Gussied up docs for npm access with new commands. (@zkat)
  • 6e0b431 Fix up npm whoami to make the underlying API usable elsewhere. (@zkat)
  • f29c931 npm-registry-client@7.0.1: Upgrade npm-registry-client API to support team and access calls against the registry. (@zkat)

A FEW EXTRA VERSION BUMPS

ALSO A DOC FIX

  • 846fcc7 #9200 Remove single quotes around semver range, thus making it valid semver. (@KenanY)

v2.13.5 (2015-08-07):

This is another quiet week for the npm@2 release. @zkat has been working hard on polishing the CLI bits of the registry's new feature to support direct management of teams and organizations, and @iarna continues to work through the list of issues blocking the general release of npm@3, which is looking more and more solid all the time.

@othiym23 and @zkat have also been at this week's Node.js / io.js collaborator summit, both as facilitators and participants. This is a valuable opportunity to get some face time with other contributors and to work through a bunch of important discussions, but it does leave us feeling kind of sleepy. Running meetings is hard!

What does that leave for this release? A few of the more tricky bug fixes that have been sitting around for a little while now, and a couple dependency upgrades. Nothing too fancy, but most of these were contributed by developers like you, which we think is swell. Thanks!

BUG FIXES

  • d7271b8 #4530 The bash completion script for npm no longer alters global completion behavior around word breaks. (@whitty)
  • c9ce294 #7198 When setting up dependencies to be shared via npm link <package>, only run the lifecycle scripts during the original link, not when running npm link <package> or npm install --link against them. (@murgatroid99)
  • 422da66 #9108 Clear up minor confusion around wording in bundledDependencies section of package.json docs. (@derekpeterson)
  • 6b42d99 #9146 Include scripts that run for preversion, version, and postversion in the section for lifecycle scripts rather than the generic npm run-script output. (@othiym23)

NOPE, NOT DONE WITH DEPENDENCY UPDATES

  • 91a48bb chmodr@1.0.1: Ignore symbolic links when recursively changing mode, just like the Unix command. (@isaacs)
  • 4bbc86e nock@2.10.0 (@pgte)

v2.13.4 (2015-07-30):

JULY ENDS ON A FAIRLY QUIET NOTE

Hey everyone! I hope you've had a great week. We're having a fairly small release this week while we wrap up Teams and Orgs (or, as we've taken to calling it internally, Teens and Orcs).

In other exciting news, a bunch of us are gonna be at the Node.js Collaborator Summit, and you can also find us at wafflejs on Wednesday. Hopefully we'll be seeing some of you there. :)

THE PATCH!!!

So here it is. The patch. Hope it helps. (Thanks, @ktarplee!)

OH AND THERE'S A DEV DEPENDENCIES UPDATE

Hooray.

v2.13.3 (2015-07-23):

I'M SAVING THE GOOD JOKES FOR MORE INTERESTING RELEASES

It's pretty hard to outdo last week's release buuuuut~ I promise I'll have a treat when we release our shiny new Teams and Organizations feature! :D (Coming Soon™). It'll be a real gem.

That means it's a pretty low-key release this week. We got some nice documentation tweaks, a few bugfixes, and other such things, though!

Oh, and a bunch of version bumps. Thanks, semver!

IT'S THE LITTLE THINGS THAT MATTER

  • 2fac6ae #9012 A convenience for releases -- using the globally-installed npm before now was causing minor annoyances, so we just use the exact same npm we're releasing to build the new release. (@zkat)

WHAT DOES THIS BUTTON DO?

There's a couple of doc updates! The last one might be interesting.

  • 4cd3205 #9002 Updated docs to list the various files that npm automatically includes and excludes, regardless of settings. (@SimenB)
  • cf09e75 #9022 Document the "access" field in "publishConfig". Did you know you don't need to use --access=public when publishing scoped packages?! Just put it in your package.json! Go refresh yourself on scopes packages by checking our docs on them. (@boennemann)
  • bfd73da #9013 fixed typo in changelog (@radarhere)

THE SEMVER MAJOR VERSION APOCALYPSE IS UPON US

Basically, semver is up to @5, and that meant we needed to go in an update a bunch of our dependencies manually. node-gyp is still pending update, since it's not ours, though!

*BUMP*

And some other version bumps for good measure.

  • 254ecfb #8990 marked-man@0.1.5: Fixes an issue with documentation rendering where backticks in 2nd-level headers would break rendering (?!?!) (@steveklabnik)
  • 79efd79 minimatch@2.0.10: A pattern like '*.!(x).!(y)' should not match a name like 'a.xyz.yab'. (@isaacs)
  • 39c7dc9 request@2.60.0: A few bug fixes and doc updates. (@simov)
  • 72d3c3a rimraf@2.4.2: Minor doc and dep updates (@isaacs)
  • 7513035 nock@2.9.1 (@pgte)
  • 3d9aa82 Fixes this thing where Kat decided to save nock as a regular dependency ;) (@othiym23)

v2.13.2 (2015-07-16):

HOLD ON TO YOUR TENTACLES... IT'S NPM RELEASE TIME!

Kat: Hooray! Full team again, and we've got a pretty small patch release this week, about everyone's favorite recurring issue: git URLs!

Rebecca: No Way! Again?

Kat: The ride never ends! In the meantime, there's some fun, exciting work in the background to get orgs and teams out the door. Keep an eye out for news. :)

Rebecca: And make sure to keep an eye out for patches for the super-fresh npm@3!

LET'S GIT INKY

Rebecca: So what's this about another git URL issue?

Kat: Welp, I apparently broke backwards-compatibility on what are actually invalid git+https URLs! So I'm making it work, but we're gonna deprecate URLs that look like git+https://user@host:path/is/here.

Rebecca: What should we use instead?!

Kat: Just do me a solid and use git+ssh://user@host:path/here or git+https://user@host/absolute/https/path instead!

  • 769f06e Updated tests for getResolved so the URLs are run through normalize-git-url. (@zkat)
  • edbae68 #8881 Added tests to verify that git+https: URLs are handled compatibly. (@zkat)

NEWS FLASH! DOCUMENTATION IMPROVEMENTS!

  • bad4e014 #8924 Make sure documented default values in lib/cache.js properly correspond to current code. (@watilde)
  • e7a11fd #8036 Clarify the documentation for .npmrc to clarify that it's not read at the project level when doing global installs. (@espadrine)

STAY FRESH~

Kat: That's it for npm core changes!

Rebecca: Great! Let's look at the fresh new dependencies, then!

Kat: See you all next week!

Both: Stay Freeesh~

(some cat form of Forrest can be seen snoring in the corner)

  • bfa1f45 normalize-git-url@3.0.1: Fixes url normalization such that git+https: accepts scp syntax, but get converted into absolute-path https: URLs. Also fixes scp syntax so you can have absolute paths after the : (git@myhost.org:/some/absolute/place.git) (@zkat)
  • 6f757d2 glob@5.0.15: Better handling of ENOTSUP (@isaacs)
  • 0920819 node-gyp@2.0.2: Fixes an issue with long paths on Win32 (@TooTallNate)

v2.13.1 (2015-07-09):

KAUAI WAS NICE. I MISS IT.

But Forrest's still kinda on vacation, and not just mentally, because he's hanging out with the fine meatbags at CascadiaFest. Enjoy this small bug release.

MAKE OURSELVES HAPPY

  • 40981f2 #8862 Make the lifecycle's safety check work with scoped packages. (@tcort)
  • 5125856 #8855 Make dependency versions of "*" match "latest" when all versions are prerelease. (@iarna)
  • 22fdc1d Visually emphasize the correct way to write lifecycle scripts. (@josh-egan)

MAKE TRAVIS HAPPY

  • 413c3ac Use npm's 2.x branch for testing its 2.x branch. (@iarna)
  • 7602f64 Don't prompt for GnuPG passphrase in version lifecycle tests. (@othiym23)

MAKE npm outdated HAPPY

  • d338668 #8796 fstream-npm@1.0.4: When packing the package tarball, npm no longer crashes for packages with certain combinations of .npmignore entries, .gitignore entries, and lifecycle scripts. (@iarna)
  • dbe7c9c nock@2.7.0: Add matching based on query strings. (@othiym23)

There are new versions of strip-ansi and ansi-regex, but npm only uses them indirectly, so we pushed them down into their dependencies where they can get updated at their own pace.

v2.13.0 (2015-07-02):

FORREST IS OUT! LET'S SNEAK IN ALL THE THINGS!

Well, not everything. Just a couple of goodies, like the new npm ping command, and the ability to add files to the commits created by npm version with the new version hooks. There's also a couple of bugfixes in npm itself and some of its dependencies. Here we go!

YES HELLO THIS IS NPM REGISTRY SORRY NO DOG HERE

Yes, that's right! We now have a dedicated npm ping command. It's super simple and super easy. You ping. We tell you whether you pinged right by saying hello right back. This should help out folks dealing with things like proxy issues or other registry-access debugging issues. Give it a shot!

This addresses #5750, and will help with the npm doctor stuff described in #6756.

I'VE WANTED THIS FOR version SINCE LIKE LITERALLY FOREVER AND A DAY

Seriously! This patch lets you add files to the version commit before it's made, So you can add additional metadata files, more automated changes to package.json, or even generate CHANGELOG.md automatically pre-commit if you're into that sort of thing. I'm so happy this is there I can't even. Do you have other fun usecases for this? Tell npmbot (@npmjs) about it!

ALL YOUR FILE DESCRIPTORS ARE BELONG TO US

We've had problems in the past with things like EMFILE errors popping up when trying to install packages with a bunch of dependencies. Isaac patched up graceful-fs to handle this case better, so we should be seeing fewer of those.

  • 022691a graceful-fs@4.1.2: Updated so we can monkey patch globally. (@isaacs)
  • c9fb0fd Globally monkey-patch graceful-fs. This should fix some errors when installing packages with lots of dependencies. (@isaacs)

READ THE FINE DOCS. THEY'VE IMPROVED

MORE NUMBERS! MORE VALUE!

  • 5afa2d5 validate-npm-package-name@2.2.2: Documented package name rules in README (@zeusdeux)
  • 021f4d9 rimraf@2.4.1: #74 Use async function for bin (to better handle Window's EBUSY) (@isaacs)
  • 5223432 osenv@0.1.3: Use os.homedir() polyfill for more reliable output. io.js added the function and the polyfill does a better job than the prior solution. (@sindresorhus)
  • 8ebbc90 npm-cache-filename@1.0.2: Make sure different git references get different cache folders. This should prevent foo/bar#v1.0 and foo/bar#master from sharing the same cache folder. (@tomekwi)
  • 367b854 lru-cache@2.6.5: Minor test/typo changes (@isaacs)
  • 9fcae61 glob@5.0.13: Tiny doc change + stop firing 'match' events for ignored items. (@isaacs)

OH AND ONE MORE THING

v2.12.1 (2015-06-25):

HEY WHERE DID EVERYBODY GO

I keep hearing some commotion. Is there something going on? Like, a party or something? Anyway, here's a small release with at least two significant bug fixes, at least one of which some of you have been waiting for for quite a while.

REMEMBER WHEN I SAID "REMEMBER WHEN I SAID THAT THING ABOUT PERMISSIONS?"?

npm@2.12.0 has a change that introduces a fix for a permissions problem whereby the _locks directory in the cache directory can up being owned by root. The fix in 2.12.0 takes care of that problem, but introduces a new problem for Windows users where npm tries to call process.getuid(), which doesn't exist on Windows. It was easy enough to fix (but more or less impossible to test, thanks to all the external dependencies involved with permissions and platforms and whatnot), but as a result, Windows users might want to skip npm@2.12.0 and go straight to npm@2.12.1. Sorry about that!

  • 7e5da23 When using the new, "fixed" cache directory creator, be extra-careful to not call process.getuid() on platforms that lack it. (@othiym23)

WHEW! ALL DONE FIXING GIT FOREVER!

New npm CLI team hero @zkat has finally (FINALLY) fixed the regression somebody (hi!) introduced a couple months ago whereby git URLs of the format git+ssh://user@githost.com:org/repo.git suddenly stopped working, and also started being saved (and cached) incorrectly. I am 100% sure there are absolutely no more bugs in the git caching code at all ever. Mm hm. Yep. Pretty sure. Maybe. Hmm... I hope.

Sighs audibly.

Let us know if we broke something else with this fix.

  • 94ca4a7 #8031 Even though git+ssh://user@githost.com:org/repo.git isn't a URL, treat it like one for the purposes of npm. (@zkat)
  • e7f56e5 #8031 normalize-git-url@2.0.0: Handle git URLs (and URL-like remote refs) in a manner consistent with npm's docs. (@zkat)

YEP, THERE ARE STILL DEPENDENCY UPGRADES

v2.12.0 (2015-06-18):

REMEMBER WHEN I SAID THAT THING ABOUT PERMISSIONS?

About a million people have filed issues related to having a tough time using npm after they've run npm once or twice with sudo. "Don't worry about it!" I said. "We've fixed all those permissions problems ages ago! Use this one weird trick and you'll never have to deal with this again!"

Well, uh, if you run npm with root the first time you run npm on a machine, it turns out that the directory npm uses to store lockfiles ends up being owned by the wrong user (almost always root), and that can, well, it can cause problems sometimes. By which I mean every time you run npm without being root it'll barf with EACCES errors. Whoops!

This is an obnoxious regression, and to prevent it from recurring, we've made it so that the cache, cached git remotes, and the lockfile directories are all created and maintained using the same utilty module, which not only creates the relevant paths with the correct permissions, but will fix the permissions on those directories (if it can) when it notices that they're broken. An npm install run as root ought to be sufficient to fix things up (and if that doesn't work, first tell us about it, and then run sudo chown -R $(whoami) $HOME/.npm)

Also, I apologize for inadvertently gaslighting any of you by claiming this bug wasn't actually a bug. I do think we've got this permanently dealt with now, but I'll be paying extra-close attention to permissions issues related to the cache for a while.

  • 85d1a53 Set permissions on lock directory to the owner of the process. (@othiym23)

I WENT TO NODECONF AND ALL I GOT WAS THIS LOUSY SPDX T-SHIRT

That's not literally true. We spent very little time discussing SPDX, @kemitchell is a champ, and I had a lot of fun playing drum & bass to a mostly empty Boogie Barn and only ended up with one moderately severe cold for my pains. Another winner of a NodeConf! (I would probably wear a SPDX T-shirt if somebody gave me one, though.)

A bunch of us did have a spirited discussion of the basics of open-source intellectual property, and the convergence of me, @kemitchell, and @jandrieu in one place allowed us to hammmer out a small but significant issue that had been bedeviling early adopters of the new SPDX expression syntax in package.json license fields: how to deal with packages that are left without a license on purpose.

Refer to the docs for the specifics, but the short version is that instead of using LicenseRef-LICENSE for proprietary licenses, you can now use either UNLICENSED if you want to make it clear that you don't want your software to be licensed (and want npm to stop warning you about this), or SEE LICENSE IN <filename> if there's a license with custom text you want to use. At some point in the near term, we'll be updating npm to verify that the mentioned file actually exists, but for now you're all on the honor system.

SMALLISH BUG FIXES

  • 9d8cac9 #8548 Remove extraneous newline from npm view output, making it easier to use in shell scripts. (@eush77)
  • 765fd4b #8521 When checking for outdated packages, or updating packages, raise an error when the registry is unreachable instead of silently "succeeding". (@ryantemple)

SMALLERISH DOCUMENTATION TWEAKS

WELL, I GUESS THERE ARE MORE DEPENDENCY UPGRADES

  • 7ce2f06 request@2.58.0: Refactor tunneling logic, and use extend instead of abusing util._extend. (@simov)
  • e6c6195 nock@2.6.0: Refined interception behavior. (@pgte)
  • 9583cc3 fstream-npm@1.0.3: Ensure that main entry in package.json is always included in the bundled package tarball. (@coderhaoxin)
  • df89493 fstream@1.0.7 (@isaacs)
  • 9744049 dezalgo@1.0.3: dezalgo should be usable in the browser, and can be now that asap has been upgraded to be browserifiable. (@mvayngrib)

v2.11.3 (2015-06-11):

This was a very quiet week. This release was done by @iarna, while the rest of the team hangs out at NodeConf Adventure!

TESTS IN 0.8 FAIL LESS

THE TREADMILL OF UPDATES NEVER CEASES

  • 9f439da spdx@0.4.1: License range updates (@kemitchell)
  • 2dd055b normalize-package-data@2.2.1: Fixes a crashing bug when the package.json scripts property is not an object. (@iarna)
  • e02e85d osenv@0.1.2: Switches to using the os-tmpdir module instead of os.tmpdir() for greate consistency in behavior between node versions. (@iarna)
  • a6f0265 ini@1.3.4 (@isaacs)
  • 7395977 rimraf@2.4.0 (@isaacs)

v2.11.2 (2015-06-04):

Another small release this week, brought to you by the latest addition to the CLI team, @zkat (Hi, all!)

Mostly small documentation tweaks and version updates. Oh! And npm outdated is actually sorted now. Rejoice!

It's gonna be a while before we get another palindromic version number. Enjoy it while it lasts. :3

QUALITY OF LIFE HAS NEVER BEEN BETTER

  • 31aada4 #8401 npm outdated output is just that much nicer to consume now, due to sorting by name. (@watilde)
  • 458a919 #8469 Explicitly set cwd for preversion, version, and postversion scripts. This makes the scripts findable relative to the root dir. (@alexkwolfe)
  • 55d6d71 Ensure package name and version are included in display during npm version lifecycle execution. Gets rid of those little undefineds in the console. (@othiym23)

WORDS HAVE NEVER BEEN QUITE THIS READABLE

  • 3901e49 #8462 English apparently requires correspondence between indefinite articles and attached nouns. (@Enet4)
  • 5a744e4 #8421 The effect of npm prune's --production flag and how to use it have been documented a bit better. (@foiseworth)
  • eada625 We've updated our .mailmap and AUTHORS files to make sure credit is given where credit is due. (@othiym23)

VERSION NUMBERS HAVE NEVER BEEN BIGGER

  • c929fd1 readable-stream@1.1.13: Manually deduped v1.1.13 (streams3) to make deduping more reliable on npm@<3. (@othiym23)
  • a9b4b78 request@2.57.0: Replace dependency on IncomingMessage's .client with .socket as the former was deprecated in io.js 2.2.0. (@othiym23)
  • 4b5e557 abbrev@1.0.7: Better testing, with coverage. (@othiym23)
  • 561affe semver@4.3.6: .npmignore added for less cruft, and better testing, with coverage. (@othiym23)
  • 60aef3c graceful-fs@3.0.8: io.js fixes. (@zkat)
  • f8bd453 config-chain@1.1.9: Added MIT license to package.json (@zkat)

v2.11.1 (2015-05-28):

This release brought to you from poolside at the Omni Amelia Island Resort and JSConf 2015, which is why it's so tiny.

CONFERENCE WIFI CAN'T STOP THESE BUG FIXES

  • cf109a6 #8381 Documented a subtle gotcha with .npmrc, which is that it needs to have its permissions set such that only the owner can read or write the file. (@colakong)
  • 180da67 #8365 Git 2.3 adds support for GIT_SSH_COMMAND, which allows you to pass an explicit git command (with, for example, a specific identity passed in on the command line). (@nmalaguti)

MY (VIRGIN) PINA COLADA IS GETTING LOW, BETTER UPGRADE THESE DEPENDENCIES

  • b72de41 node-gyp@2.0.0: Use a newer version of gyp, and generally improve support for Visual Studios and Windows. (@TooTallNate)
  • 8edbe21 node-gyp@2.0.1: Don't crash when Python's version doesn't parse as valid semver. (@TooTallNate)
  • ba0e0a8 glob@5.0.10: Add coverage to tests. (@isaacs)
  • 7333701 request@2.56.0: Bug fixes and dependency upgrades. (@simov)

v2.11.0 (2015-05-21):

For the first time in a very long time, we've added new events to the life cycle used by npm run-script. Since running npm version (major|minor|patch) is typically the last thing many developers do before publishing their updated packages, it makes sense to add life cycle hooks to run tests or otherwise preflight the package before doing a full publish. Thanks, as always, to the indefatigable @watilde for yet another great usability improvement for npm!

FEATURELETS

  • b07f7c7 #7906 Add new scripts to allow you to run scripts before and after the npm version command has run. This makes it easy to, for instance, require that your test suite passes before bumping the version by just adding "preversion": "npm test" to the scripts section of your package.json. (@watilde)
  • 8a46136 #8185 When we get a "not found" error from the registry, we'll now check to see if the package name you specified is invalid and if so, give you a better error message. (@thefourtheye)

BUG FIXES

  • 9bcf573 #8324 On Windows, when you've configured a custom node-gyp, run it with node itself instead of using the default open action (which is almost never what you want). (@bangbang93)
  • 1da9b04 #7195 #7260 npm-registry-client@6.4.0: (Re-)allow publication of existing mixed-case packages (part 1). (@smikes)
  • e926783 #7195 #7260 normalize-package-data@2.2.0: (Re-)allow publication of existing mixed-case packages (part 2). (@smikes)

DOCUMENTATION IMPROVEMENTS

DEPENDENCY UPDATES! ALWAYS AND FOREVER!

  • fc52160 #4700 #5044 init-package-json@1.6.0: Make entering an invalid version while running npm init give you an immediate error and prompt you to correct it. (@watilde)
  • 738853e #7763 fs-write-stream-atomic@1.0.3: Fix a bug where errors would not propagate, making error messages unhelpful. (@iarna)
  • 6d74a2d npm-package-arg@4.0.1: Fix tests on windows (@Bacra) and with more recent hosted-git-info. (@iarna)
  • 50f7178 hosted-git-info@2.1.4: Correct spelling in its documentation. (@iarna)
  • d7956ca glob@5.0.7: Fix a bug where unusual error conditions could make further use of the module fail. (@isaacs)
  • 44f7d74 tap@1.1.0: Update to the most recent tap to get a whole host of bug fixes and integration with coveralls. (@isaacs)
  • c21e8a8 nock@2.2.0 (@othiym23)

LICENSE FILES FOR THE LICENSE GOD

SPDX LICENSE UPDATES

v2.10.1 (2015-05-14):

BUG FIXES & DOCUMENTATION TWEAKS

  • dc77520 When getting back a 404 from a request to a private registry that uses a registry path that extends past the root (http://registry.enterprise.co/path/to/registry), display the name of the nonexistent package, rather than the first element in the registry API path. Sorry, Artifactory users! (@hayes)
  • f70dea9 Make clearer that --registry can be used on a per-publish basis to push a package to a non-default registry. (@mischkl)
  • a3e26f5 Did you know that GitHub shortcuts can have commit-ishes included (org/repo#branch)? They can! (@iarna)
  • 0e2c091 Some errors from readPackage were being swallowed, potentially leading to invalid package trees on disk. (@smikes)

DEPENDENCY UPDATES! STILL! MORE! AGAIN!

  • 0b901ad lru-cache@2.6.3: Removed some cruft from the published package. (@isaacs)
  • d713e0b mkdirp@0.5.1: Made compliant with standard, dropped support for Node 0.6, added (Travis) support for Node 0.12 and io.js. (@isaacs)
  • a2d6578 glob@1.0.3: Updated to use tap@1. (@isaacs)
  • 64cd1a5 fstream@ 1.0.6: Made compliant with standard (done by @othiym23, and then debugged and fixed by @iarna), and license changed to ISC. (@othiym23 / @iarna)
  • b527a7c which@1.1.1: Callers can pass in their own PATH instead of relying on process.env. (@isaacs)

v2.10.0 (2015-05-8):

THE IMPLICATIONS ARE MORE PROFOUND THAN THEY APPEAR

If you've done much development in The Enterprise®™, you know that keeping track of software licenses is far more important than one might expect / hope / fear. Tracking licenses is a hassle, and while many (if not most) of us have (reluctantly) gotten around to setting a license to use by default with all our new projects (even if it's just WTFPL), that's about as far as most of us think about it. In big enterprise shops, ensuring that projects don't inadvertently use software with unacceptably encumbered licenses is serious business, and developers spend a surprising (and appalling) amount of time ensuring that licensing is covered by writing automated checkers and other license auditing tools.

The Linux Foundation has been working on a machine-parseable syntax for license expressions in the form of SPDX, an appropriately enterprisey acronym. IP attorney and JavaScript culture hero Kyle Mitchell has put a considerable amount of effort into bringing SPDX to JavaScript and Node. He's written spdx.js, a JavaScript SPDX expression parser, and has integrated it into npm in a few different ways.

For you as a user of npm, this means:

  • npm now has proper support for dual licensing in package.json, due to SPDX's compound expression syntax. Run npm help package.json for details.
  • npm will warn you if the package.json for your project is either missing a "license" field, or if the value of that field isn't a valid SPDX expression (pro tip: "BSD" becomes "BSD-2-Clause" in SPDX (unless you really want one of its variants); "MIT" and "ISC" are fine as-is; the full list is its own package).
  • npm init now demands that you use a valid SPDX expression when using it interactively (pro tip: I mostly use npm init -y, having previously run npm config set init.license=MIT / npm config set init.author.email=foo / npm config set init.author.name=me).
  • The documentation for package.json has been updated to tell you how to use the "license" field properly with SPDX.

In general, this shouldn't be a big deal for anybody other than people trying to run their own automated license validators, but in the long run, if everybody switches to this format, many people's lives will be made much simpler. I think this is an important improvement for npm and am very thankful to Kyle for taking the lead on this. Also, even if you think all of this is completely stupid, just choose a license anyway. Future you will thank past you someday, unless you are djb, in which case you are djb, and more power to you.

  • 8669f7d #8179 Document how to use SPDX in license stanzas in package.json, including how to migrate from old busted license declaration arrays to fancy new compound-license clauses. (@kemitchell)
  • 98ad98c #8197 init-package-json@1.5.0 Ensure that packages bootstrapped with npm init use an SPDX-compliant license expression. (@kemitchell)
  • 2ad3905 #8197 normalize-package-data@2.1.0: Warn when a package is missing a license declaration, or using a license expression that isn't valid SPDX. (@kemitchell)
  • 127bb73 #8197 tar@2.1.1: Switch from BSD to ISC for license, where the latter is valid SPDX. (@othiym23)
  • e9a933a #8197 once@1.3.2: Switch from BSD to ISC for license, where the latter is valid SPDX. (@othiym23)
  • 412401f #8197 semver@4.3.4: Switch from BSD to ISC for license, where the latter is valid SPDX. (@othiym23)

As a corollary to the previous changes, I've put some work into making npm install spew out fewer pointless warnings about missing values in transitive dependencies. From now on, npm will only warn you about missing READMEs, license fields, and the like for top-level projects (including packages you directly install into your application, but we may relax that eventually).

Practically nobody liked having those warnings displayed for child dependencies, for the simple reason that there was very little that anybody could do about those warnings, unless they happened to be the maintainers of those dependencies themselves. Since many, many projects don't have SPDX-compliant licenses, the number of warnings reached a level where they ran the risk of turning into a block of visual noise that developers (read: me, and probably you) would ignore forever.

So I fixed it. If you still want to see the messages about child dependencies, they're still there, but have been pushed down a logging level to info. You can display them by running npm install -d or npm install --loglevel=info.

  • eb18245 Only warn on normalization errors for top-level dependencies. Transitive dependency validation warnings are logged at info level. (@othiym23)

BUG FIXES

  • e40e809 tap@1.0.1: TAP: The Next Generation. Fix up many tests to they work properly with the new major version of node-tap. Look at all the colors! (@isaacs)
  • f9314e9 nock@1.9.0: Minor tweaks and bug fixes. (@pgte)
  • 45c2b1a #8187 npm ls wasn't properly recognizing dependencies installed from GitHub repositories as git dependencies, and so wasn't displaying them as such. (@zornme)
  • 1ab57c3 In some cases, npm help was using something that looked like a regular expression where a glob pattern should be used, and vice versa. (@isaacs)

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)) 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 npm@2.9.1 and verify that things (again?) work correctly in your project.

  • 178a6ad #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)
  • 63b79cc #8084 Ensure that Bitbucket, GitHub, and Gitlab dependencies are installed the same way as non-hosted git dependencies, fixing npm install --link. (@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 #8137 Somehow, we had failed to clearly document the full restrictions on package names. @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)
  • b574076 #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)
  • 1ff636e #8105 Document that the global npmrc goes in $PREFIX/etc/npmrc, instead of $PREFIX/npmrc. (@anttti)
  • c3f2f7c #8127 Document how to use npm run build directly (hint: it's different from npm build!). (@mikemaccana)
  • 873e467 #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)

ENROBUSTIFICATIONMENT

  • 5abfc9c #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)
  • 4b564f0 #8081 Use osenv to parse the environment's PATH in a platform-neutral way. (@watilde)
  • a4b6238 #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 for bringing this to our attention! (@othiym23)

DEPENDENCY UPDATES WAIT FOR NO SOPHONT

  • 000cd8b rimraf@2.3.3: More informative assertions on argument validation failure. (@isaacs)
  • 530a2e3 lru-cache@2.6.2: Revert to old key access-time behavior, as it was correct all along. (@isaacs)
  • d88958c minimatch@2.0.7: Feature detection and test improvements. (@isaacs)
  • 3fa39e4 nock@1.7.1 (@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 #7426 Include local modules in npm outdated and npm update. (@ArnaudRinquin)
  • 2114862 #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)

OTHER MINOR TWEAKS

  • 18ce0ec #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)
  • 9ad2100 #8008 Once again, when considering what to install on npm install, include devDependencies. (@smikes)
  • 5466260 #8003 Clarify the documentation around scopes to make it easier to understand how they support private packages. (@smikes)

DEPENDENCIES WILL NOT STOP UNTIL YOU ARE VERY SLEEPY

  • faf65a7 init-package-json@1.4.2: 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). (@MisumiRize)
  • 7f10f38 editor@1.0.0: 1.0.0 is literally more than 0.1.0 (no change aside from version number). (@substack)
  • 4979af3 #6805 npm-registry-client@6.3.3: Decode scoped package names sent by the registry so they look nicer. (@mmalecki)

v2.8.4 (2015-04-16):

This is the fourth release of npm this week, so it's mostly just landing a few small outstanding PRs on dependencies and some tiny documentation tweaks. npm@2.8.3 is where the real action is.

  • ee2bd77 #7983 tar@2.1.0: Better error reporting in corrupted tar files, and add support for the fromBase flag (rescued from the dustbin of history by @deanmarano). (@othiym23)
  • d8eee6c init-package-json@1.4.1: Add support for a default author, and only add scope to a package name once. (@othiym23)
  • 4fc5d98 lru-cache@2.6.1: Small tweaks to cache value aging and entry counting that are irrelevant to npm. (@isaacs)
  • 1fe5840 #7946 Make npm init text friendlier. (@sandfox)

v2.8.3 (2015-04-15):

TWO SMALL GIT TWEAKS

This is the last of a set of releases intended to ensure npm's git support is robust enough that we can stop working on it for a while. These fixes are small, but prevent a common crasher and clear up one of the more confusing error messages coming out of npm when working with repositories hosted on git.

  • 387f889 #7961 Ensure that hosted git SSH URLs always have a valid protocol when stored in resolved fields in npm-shrinkwrap.json. (@othiym23)
  • 394c2f5 Switch the order in which hosted Git providers are checked to git:, git+https:, then git+ssh: (from git:, git+ssh:, then git+https:) in an effort to go from most to least likely to succeed, to make for less confusing error message. (@othiym23)

v2.8.2 (2015-04-14):

PEACE IN OUR TIME

npm has been having an issue with CouchDB's web server since the release of io.js and Node.js 0.12.0 that has consumed a huge amount of my time to little visible effect. Sam Mikes picked up the thread from me, and after a lot of effort figured out that ultimately there are probably a couple problems with the new HTTP Agent keep-alive handling in new versions of Node. In addition, npm-registry-client was gratuitously sending a body along with a GET request which was triggering the bugs. Sam removed about 10 bytes from one file in npm-registry-client, and this problem, which has been bugging us for months, completely went away.

In conclusion, Sam Mikes is great, and anybody using a private registry hosted on CouchDB should thank him for his hard work. Also, thanks to the community at large for pitching in on this bug, which has been around for months now.

  • 431c3bf #7699 npm-registry-client@6.3.2: Don't send body with HTTP GET requests when logging in. (@smikes)

v2.8.1 (2015-04-12):

CORRECTION: NPM'S GIT INTEGRATION IS DOING OKAY

A helpful bug report led to another round of changes to hosted-git-info, some additional test-writing, and a bunch of hands-on testing against actual private repositories. While the complexity of npm's git dependency handling is nearly fractal (because npm is very complex, and git is even more complex), it's feeling way more solid than it has for a while. We think this is a substantial improvement over what we had before, so give npm@2.8.1 a shot if you have particularly complex git use cases and let us know how it goes.

(NOTE: These changes mostly affect cloning and saving references to packages hosted in git repositories, and don't address some known issues with things like lifecycle scripts not being run on npm dependencies. Work continues on other issues that affect parity between git and npm registry packages.)

  • 66377c6 #7872 hosted-git-info@2.1.2: Pass through credentials embedded in SSH and HTTPs git URLs. (@othiym23)
  • 15efe12 #7872 Use the new version of hosted-git-info to pass along credentials embedded in git URLs. Test it. Test it a lot. (@othiym23)

SCOPED DEPENDENCIES AND PEER DEPENDENCIES: NOT QUITE REESE'S

Big thanks to @ewie for identifying an issue with how npm was handling peerDependencies that were implicitly installed from the package.json files of scoped dependencies. This will be a moot point with the release of npm@3, but until then, it's important that peerDependency auto-installation work as expected.

  • b027319 #7920 Scoped packages with peerDependencies were installing the peerDependencies into the wrong directory. (@ewie)
  • 649e31a #7920 Test peerDependency installs involving scoped packages using npm-package-arg instead of simple path tests, for consistency. (@othiym23)

MAKING IT EASIER TO WRITE NPM TESTS, VERSION 0.0.1

@iarna and I (@othiym23) have been discussing a candidate plan for improving npm's test suite, with the goal of making it easier for new contributors to get involved with npm by reducing the learning curve necessary to be able to write good tests for proposed changes. This is the first substantial piece of that effort. Here's what the commit message for ed7e249 had to say about this work:

It's too difficult for npm contributors to figure out what the conventional style is for tests. Part of the problem is that the documentation in CONTRIBUTING.md is inadequate, but another important factor is that the tests themselves are written in a variety of styles. One of the most notable examples of this is the fact that many tests use fixture directories to store precooked test scenarios and package.json files.

This had some negative consequences:

  • tests weren't idempotent
  • subtle dependencies between tests existed
  • new tests get written in this deprecated style because it's not obvious that the style is out of favor
  • it's hard to figure out why a lot of those directories existed, because they served a variety of purposes, so it was difficult to tell when it was safe to remove them

All in all, the fixture directories were a major source of technical debt, and cleaning them up, while time-consuming, makes the whole test suite much more approachable, and makes it more likely that new tests written by outside contributors will follow a conventional style. To support that, all of the tests touched by this changed were cleaned up to pass the standard style checker.

And here's a little extra context from a comment I left on #7929:

One of the other things that encouraged me was looking at this presentation on technical debt from Pycon 2015, especially slide 53, which I interpreted in terms of difficulty getting new contributors to submit patches to an OSS project like npm. npm has a long ways to go, but I feel good about this change.

THE EVER-BEATING DRUM OF DEPENDENCY UPDATES

  • d90d0b9 #7924 Remove child-process-close, as it was included for Node 0.6 compatibility, and npm no longer supports 0.6. (@robertkowalski)
  • 16427c1 lru-cache@2.5.2: More accurate updating of expiry times when maxAge is set. (@isaacs)
  • 03cce83 nock@1.6.0: Mocked network error handling. (@pgte)
  • f93b1f0 glob@5.0.5: Use path-is-absolute polyfill, allowing newer Node.js and io.js versions to use path.isAbsolute(). (@sindresorhus)
  • a70d694 request@2.55.0: Bug fixes and simplification. (@simov)
  • 2aecc6f columnify@1.5.1: Switch to using babel from 6to5. (@timoxley)

v2.8.0 (2015-04-09):

WE WILL NEVER BE DONE FIXING NPM'S GIT SUPPORT

If you look at the last release's release notes, you will note that they confidently assert that it's perfectly OK to force all GitHub URLs through the same git: -> git+ssh: fallback flow for cloning. It turns out that many users depend on git+https: URLs in their build environments because they use GitHub auth tokens instead of SSH keys. Also, in some cases you just want to be able to explicitly say how a given dependency should be cloned from GitHub.

Because of the way we resolved the inconsistency in GitHub shorthand handling before, this turned out to be difficult to work around. So instead of hacking around it, we completely redid how git is handled within npm and its attendant packages. Again. This time, we changed things so that normalize-package-data and read-package-json leave more of the git logic to npm itself, which makes handling shorthand syntax consistently much easier, and also allows users to resume using explicit, fully-qualified git URLs without npm messing with them.

Here's a summary of what's changed:

  • Instead of converting the GitHub shorthand syntax to a git+ssh:, git:, or git+https: URL and saving that, save the shorthand itself to package.json.
  • If presented with shortcuts, try cloning via the git protocol, SSH, and HTTPS (in that order).
  • No longer prompt for credentials -- it didn't work right with the spinner, and wasn't guaranteed to work anyway. We may experiment with doing this a better way in the future. Users can override this by setting GIT_ASKPASS in their environment if they want to experiment with interactive cloning, but should also set --no-spin on the npm command line (or run npm config set spin=false).
  • EXPERIMENTAL FEATURE: Add support for github:, gist:, bitbucket:, and gitlab: shorthand prefixes. GitHub shortcuts will continue to be normalized to org/repo instead of being saved as github:org/repo, but gitlab:, gist:, and bitbucket: prefixes will be used on the command line and from package.json. BE CAREFUL WITH THIS. package.json files published with the new shorthand syntax can only be read by npm@2.8.0 and later, and this feature is mostly meant for playing around with it. If you want to save git dependencies in a form that older versions of npm can read, use --save-exact, which will save the git URL and resolved commit hash of the head of the branch in a manner similar to the way that --save-exact pins versions for registry dependencies. This is documented (so check npm help install for details), but we're not going to make a lot of noise about it until it has a chance to bake in a little more.

It is @othiym23's sincere hope that this will resolve all of the inconsistencies users were seeing with GitHub and git-hosted packages, but given the level of change here, that may just be a fond wish. Extra testing of this change is requested.

  • 6b0f588 #7867 Use git shorthand and git URLs as presented by user. Support new hosted-git-info shortcut syntax. Save shorthand in package.json. Try cloning via git:, git+ssh:, and git+https:, in that order, when supported by the underlying hosting provider. (@othiym23)
  • 75d4267 #7867 Document new GitHub, GitHub gist, Bitbucket, and GitLab shorthand syntax. (@othiym23)
  • 7d92c75 #7867 When --save-exact is used with git shorthand or URLs, save the fully-resolved URL, with branch name resolved to the exact hash for the commit checked out. (@othiym23)
  • 9220e59 #7867 Ensure that non-prefixed and non-normalized GitHub shortcuts are saved to package.json. (@othiym23)
  • dd398e9 #7867 hosted-git-info@2.1.1: Ensure that gist: shorthand survives being round-tripped through package.json. (@othiym23)
  • 33d1420 #7867 hosted-git-info@2.1.0: Add support for auth embedded directly in git URLs. (@othiym23)
  • 23a1d5a #7867 hosted-git-info@2.0.2: Make it possible to determine in which form a hosted git URL was passed. (@iarna)
  • eaf75ac #7867 normalize-package-data@2.0.0: Normalize GitHub specifiers so they pass through shortcut syntax and preserve explicit URLs. (@iarna)
  • 95e0535 #7867 npm-package-arg@4.0.0: Add git URL and shortcut to hosted git spec and use hosted-git-info@2.0.2. (@iarna)
  • a808926 #7867 realize-package-specifier@3.0.0: Use npm-package-arg@4.0.0 and test shortcut specifier behavior. (@iarna)
  • 6dd1e03 #7867 init-package-json@1.4.0: Allow dependency on read-package-json@2.0.0. (@iarna)
  • 63254bb #7867 read-installed@4.0.0: Use read-package-json@2.0.0. (@iarna)
  • 254b887 #7867 read-package-json@2.0.0: Use normalize-package-data@2.0.0. (@iarna)
  • 0b9f8be #7867 npm-registry-client@6.3.0: Mark compatibility with normalize-package-data@2.0.0 and npm-package-arg@4.0.0. (@iarna)
  • f40ecaa #7867 Extract a common method to use when cloning git repos for testing. (@othiym23)

TEST FIXES FOR NODE 0.8

npm continues to get closer to being completely green on Travis for Node 0.8.

SMALL FIX AND DOC TWEAK

  • 20e9003 tar@2.0.1: Fix regression where relative symbolic links within an extraction root that pointed within an extraction root would get normalized to absolute symbolic links. (@isaacs)
  • 2ef8898 #7879 Better document that npm publish --tag=foo will not set latest to that version. (@linclark)

v2.7.6 (2015-04-02):

GIT MEAN, GIT TUFF, GIT ALL THE WAY AWAY FROM MY STUFF

Part of the reason that we're reluctant to take patches to how npm deals with git dependencies is that every time we touch the git support, something breaks. The last few releases are a case in point. npm@2.7.4 completely broke installing private modules from GitHub, and npm@2.7.5 fixed them at the cost of logging a misleading error message that caused many people to believe that their dependencies hadn't been successfully installed when they actually had been.

This all started from a desire to ensure that GitHub shortcut syntax is being handled correctly. The correct behavior is for npm to try to clone all dependencies on GitHub (whether they're specified with the GitHub organization/repository shortcut syntax or not) via the plain git: protocol first, and to fall back to using git+ssh: if git: doesn't work. Previously, sometimes npm would use git: and git+ssh: in some cases (most notably when using GitHub shortcut syntax on the command line), and use git+https: in others (when the GitHub shortcut syntax was present in package.json). This led to subtle and hard-to-understand inconsistencies, and we're glad that as of npm@2.7.6, we've finally gotten things to where they were before we started, only slightly more consistent overall.

We are now going to go back to our policy of being extremely reluctant to touch the code that handles Git dependencies.

  • b747593 #7630 Don't automatically log all git failures as errors. maybeGithub needs to be able to fail without logging to support its fallback logic. (@othiym23)
  • cd67a0d #7829 When fetching a git remote URL, handle failures gracefully (without assuming standard output exists). (@othiym23)
  • 637c7d1 #7829 When fetching a git remote URL, handle failures gracefully (without assuming standard error exists). (@othiym23)

OTHER SIGNIFICANT FIXES

  • 78005eb #7743 Always quote arguments passed to npm run-script. This allows build systems and the like to safely escape glob patterns passed as arguments to run-scripts with `npm run-script