Skip to content

Latest commit

 

History

History
5344 lines (4543 loc) · 292 KB

CHANGELOG-2.md

File metadata and controls

5344 lines (4543 loc) · 292 KB
Raw

v2.15.12 (2017-03-24):

This version brings the latest node-gyp to a soon to be released Node.js 4.x. The node-gyp update is particularly important to Windows folks due to its addition of Visual Studio 2017 support.

v2.15.11 (2016-09-08):

On we go with our monthly release cadence! This week is pretty much all dependency updates and some documentation changes, as can be expected by now.

Note that npm@4 will almost certainly be released next month! It's not final what we'll end up doing as far as LTS support goes, but the current thinking is that, considering how small and resource-constrained our team is, support for npm@2 will be reduced to essentially maintenance, so we can better focus on npm@3 as the new LTS version (which will go into node@6), and npm@4 as our next main development version.

DOCUMENTATION UPDATES

DEPENDENCY UPDATES

v2.15.10 (2016-08-11):

Hi all, today's our first release coming out of the new monthly release cadence. See below for details. We're all recovered from conferences now and raring to go! For LTS we see some bug fixes, documentation improvements and a host of dependency updates.

The most dramatic bug fix is probably the inclusion of scoped modules in bundled dependencies. Prior to this release and v3.10.7, npm had ignored scoped modules found in bundleDependencies entirely.

NEW RELEASE CADENCE

Releasing npm has been, for the most part, a very prominent part of our weekly process process. As part of our efforts to find the most effective ways to allocate our team's resources, we decided last month that we would try and slow our releases down to a monthly cadence, and see if we found ourselves with as much extra time and attention as we expected to have. Process experiments are useful for finding more effective ways to do our work, and we're at least going to keep doing this for a whole quarter, and then measure how well it worked out. It's entirely likely that we'll switch back to a more frequent cadence, specially if we find that the value that weekly cadence was providing the community is not worth sacrificing for a bit of extra time. Does this affect you significantly? Let us know!

WINDOWS CORNER CASES

  • 405c404 #13023 Fixed a Windows issue with the cache where callbacks could be called more than once. (@zkat)

  • bf348dc #13023 Fixed a Windows corner case with correct-mkdir where if SUDO_UID or SUDO_GID were set then we would try to chown things even though that can't work on Windows. (@zkat)

RACES IN THE CACHE

  • 68f29f1 #12669 Ignore ENOENT errors on chownr while adding packages to cache. This change works around problems with race conditions and local packages. (@julianduque)

BETTER GIT ENVIRONMENT WHITELISTING

DOCUMENTATION

DEPENDENCIES

v2.15.9 (2016-06-30):

What's this? An LTS release? Yes, that is indeed so. Small, as usual, and as LTSs should be, really, but a release nonetheless!

The star of the show is an updated node-gyp with some goodies. The rest is just docs and some CI stuff.

Happy hacking!

DEPENDENCY UPDATE!

CI TWEAKS

  • bee83b8 Globally install rimraf on CI to make the LTS self-install work better. (@othiym23)
  • 6b8c0ab This new Travis configuration only runs coverage checks against Node.js LTS, which speeds up all the other test runs. By, like, a lot. Also, the entire file has been extensively commented, so the next time we need to mess with it, we'll be able to better remember why all the weird bits are there. (@othiym23)

DOCUMENTATION FIXES

v2.15.8 (2016-06-17):

There's a very important bug fix and a long-awaited (and significant!) deprecation in this hotfix release. Hold on.

WHOA

When Node.js 6.0.0 was released, the CLI team noticed an alarming upsurge in bugs related to important files (like README.md) not being included in published packages. The new bugs looked much like #5082, which had been around in one form or another since April, 2014. #5082 used to be a very rare (and obnoxious) bug that the CLI team hadn't had much luck reproducing, and we'd basically marked it down as a race condition that arose on machines using slow and / or rotating-media-based hard drives.

Under 6.0.0, the behavior was reliable enough to be nearly deterministic, and made it very difficult for publishers using .npmignore files in combination with "files" stanzas in package.json to get their packages onto the registry without one or more files missing from the packed tarball. The entire saga is contained within the issue, but the summary is that an improvement to the performance of fs.realpath() made it much more likely that the packing code would lose the race.

Fixing this has proven to be very difficult, in part because the code used by npm to produce package tarballs is more complicated than, strictly speaking, it needs to be. @evanlucas contributed a patch that passed the tests in a special test suite that I (@othiym23) created (with help from @addaleax), but only after we'd released the fixed version of that package did we learn that it actually made the problem worse in other situations in npm proper. Eventually, @rvagg put together a more durable fix that appears to completely address the errant behavior under Node.js 6.0.0. That's the patch included in this release. Everybody should chip in for redback insurance for Rod and his family; he's done the community a huge favor.

Does this mean the long (2+ year) saga of #5082 is now over? At this point, I'm going to quote from my latest summary on the issue:

The CLI team (mostly me, with input from the rest of the team) has decided that the overall complexity of the interaction between fstream, fstream-ignore, fstream-npm, and node-tar has grown more convoluted than the team is comfortable (maybe even capable of) supporting.

  • While I believe that @rvagg's (very targeted) fix addresses this issue, I would be shocked if there aren't other race conditions in npm's packing logic. I've already identified a couple other places in the code that are most likely race conditions, even if they're harder to trigger than the current one.
  • The way that dependency bundling is integrated leads to a situation in which a bunch of logic is duplicated between fstream-npm and lib/utils/tar.js in npm itself, and the way fstream's extension mechanism works makes this difficult to clean up. This caused a nasty regression (#13088, see below) as of ~[email protected] where the dependencies of bundledDependencies were no longer being included in the built package tarballs.
  • The interaction between .npmignore, .gitignore, and files is hopelessly complicated, scattered in many places throughout the code. We've been discussing making the ignores and includes logic clearer and more predictable, and the current code fights our efforts to clean that up.

So, our intention is still to replace fstream, fstream-ignore, and fstream-npm with something much simpler and purpose-built. There's no real reason to have a stream abstraction here when a simple recursive-descent filesystem visitor and a synchronous function that can answer whether a given path should be included in the packed tarball would do the job adequately.

What's not yet clear is whether we'll need to replace node-tar in the process. node-tar is a very robust implementation of tar (it handles, like, everything), and it also includes some very important tweaks to prevent several classes of security exploits involving maliciously crafted packages. However, its packing API involves passing in an fstream instance, so we'd either need to produce something that follows enough of fstream's contract for node-tar to keep working, or swap node-tar out for something like tar-stream (and then ensuring that our use of tar-stream is secure, which could involve security patches for either npm or tar-stream).

The testing and review of [email protected] that the team has done leads us to believe that this bug is fixed, but I'm feeling more than a little paranoid about fstream now, so it's important that people keep a close eye on their publishes for a while and let us know immediately if they notice any irregularities.

GOODBYE, FAITHFUL FRIEND

At NodeConf Adventure 2016 (RIP in peace, Mikeal Rogers's NodeConf!), the CLI team had an opportunity to talk to representatives from some of the larger companies that we knew were still using Node.js 0.8 in production. After asking them whether they were still using 0.8, we got back blank stares and questions like, "0.8? You mean, from four years ago?" After establishing that being able to run npm in their legacy environments was no longer necessary, the CLI team made the decision to drop support for 0.8. (Faithful observers of our team meetings will have known this was the plan for NodeConf since the beginning of 2016.)

In practice, this means only what's in the commit below: we've removed 0.8 from our continuous integration test matrix below, and will no longer be habitually testing changes under Node 0.8. We may also give ourselves permission to use setImmediate() in test code. However, since the project still supports Node.js 0.10 and 0.12, it's unlikely that patches that rely on ES 2015 functionality will land anytime soon.

Looking forward, the team's current plan is to drop support for Node.js 0.10 when its LTS maintenance window expires in October, 2016, and 0.12 when its maintenance / LTS window ends at the end of 2016. We will also drop support for Node.js 5.x when Node.js 6 becomes LTS and Node.js 7 is released, also in the October-December 2016 timeframe.

(Confused about Node.js's LTS policy? Don't be! If you look at this diagram, it should make all of the preceding clear.)

If, in practice, this doesn't work with distribution packagers or other community stakeholders responsible for packaging and distributing Node.js and npm, please reach out to us. Aligning the npm CLI's LTS policy with Node's helps everybody minimize the amount of work they need to do, and since all of our teams are small and very busy, this is somewhere between a necessity and non-negotiable.

  • 4a1ecc0 Remove 0.8 from the Node.js testing matrix, and reorder to match real-world priority, with comments. (@othiym23)

v2.15.7 (2016-06-16):

It pains me greatly that we haven't been able to fix #5082 yet, but warning you away from potentially publishing incomplete packages takes priority over feeling cheesy about landing a warning to help keep y'all out of trouble, so here you go (please read this next bit (please clap)):

DANGER: PUBLISHING ON NODE 6.0.0

Publishing and packing are buggy under Node versions greater than 6.0.0. Please use Node.js LTS (4.4.x) to publish packages. See #5082 for details and current status.

PACKAGING CHANGES

  • 1877171 #12873 Ignore .nyc_output. This will help avoid an accidental publish or commit filled with code coverage data. (@TheAlphaNerd)

DOCUMENTATION CHANGES

DEPENDENCY UPDATES

v2.15.6 (2016-05-12):

I have a couple of doc fixes and a shrinkwrap fix for you all this week.

PEER DEPENDENCIES AND SHRINKWRAPS

  • 55c998a #5135 Fix a bug where peerDependencies & shrinkwraps didn't play nice together. (Where the peerDependency resolver would end up installing its dep when it wasn't needed.) (@majgis)

NPM AND node-gyp DOCS IMPROVEMENTS

v2.15.5 (2016-05-05):

This is a minor LTS release, bringing dependencies up to date and updating our CI matrix to match what we support.

Some of the dependency updates come out of our getting the development branch's tests passing on Windows and so bring in fixes for a few Windows related corner cases.

CI UPDATES

DEPENDENCY UPDATES

v2.15.4 (2016-04-21):

Gosh, it's been a peaceful couple of weeks!

Overall, the CLI team has been focused on the project to get the test suite passing on Windows. Our efforts should be paying off soon -- there's only a couple of tests left!

It's very unlikely those particular changes will make their way into our current npm@2 LTS release, I think, but it will help npm@3 a lot, as well as whatever version makes it into node@6, which will eventually be the next Node.js LTS.

As far as this week goes, we've got a couple of dep updates and doc fixes. Always happy to see community contributions flying in. 💚

DEP UPDATE MAGIC

  • b178c4a [email protected]: Minor project-related tweaks -- no license changes. (@shinnn)
  • 1adf179 [email protected]: Fixes file:// URLs on Windows. Turns out stuff like file://C:\hello is actually fairly weird for a URL (it's not actually a valid URL, but we're just gonna pretend.😉) (@zkat)
  • 9cfd56c [email protected]: This one goes out to our fans at Big Blue: There was an AIX-specific issue where fs.rmDir was failing with EEXIST instead of ENOTEMPTY with non-empty directories. (@richardlau)

HOORAY DOC CONTRIBUTIONS

No seriously, we love these. Keep 'em comin'!

  • 2afe8bf #12415 Clarify that the --cert and --key options are actual certs and keys, not paths to files containing them. (@rvedotrc)
  • 3522560 #12107 Document npm login as an alias to npm adduser. People are still surprised by this so often. (@gnerkus)

v2.15.3 (2016-03-31):

Hiiiiiii!~👋

We're really happy to be getting more and more community contributions! Keep it up! We really appreciate folks trying to help us, and we'll do our best to help point you in the right direction. Even things like documentation are a huge help. And remember -- you get socks for it, too!🎁

This week is as quiet as usual, aside from fixing a regression to npm deprecate you might want to pay attention to! Other than that, just docs and deps, as any good LTS release train should be. 🙆

FIXME

DOCS

DEPS

v2.15.2 (2016-03-24):

It's always nice to see new contributors. 💚

This week sees another small release, but we're still chugging along on our Windows efforts.

There's also some small process changes to our LTS process relatively recently that you might wanna know about! 💁

For one, the 2.x branch was removed in favor of just lts. If you're making PRs exclusively against npm's LTS, please use that name from now on. 2.x was deleted.

Also, @othiym23 put some time into writing down our LTS process and policy. Check it out and ping us if you have questions or comments about it!

In general, we're trying to make sure all our policy and such for our contributors is written down, and we hope it makes it easier in general for y'all. Forrest is also working on a shiny new Contributor's Guide right now, but we'll link to that in the (near?) future, when it's ready to roll out.

TESTS

  • 1d0e468 #11931 Removes a bunch of old, disabled tests that have just been sitting around, doing nothing. (@othiym23)
  • 7ae8aa1 #11987 There was a failure in the outdated-symlink test caused by using the default registry instead of the mock registry tests. (@yodeyer)

DOCS

  • b2649fb #12006 Access was Team and Team was Access, but someone from the community rolled around and corrected it for us. Thanks a bunch! (@yaelz)

v2.15.1 (2016-03-17):

SECURITY ADVISORY: BEARER TOKEN DISCLOSURE

This release includes the fix for a vulnerability that could cause the unintentional leakage of bearer tokens.

Here are details on this vulnerability and how it affects you.

DETAILS

Since 2014, npm’s registry has used HTTP bearer tokens to authenticate requests from the npm’s command-line interface. A design flaw meant that the CLI was sending these bearer tokens with every request made by logged-in users, regardless of the destination of their request. (The bearers only should have been included for requests made against a registry or registries used for the current install.)

An attacker could exploit this flaw by setting up an HTTP server that could collect authentication information, then use this authentication information to impersonate the users whose tokens they collected. This impersonation would allow them to do anything the compromised users could do, including publishing new versions of packages.

With the fixes we’ve released, the CLI will only send bearer tokens with requests made against a registry.

THINK YOU'RE AT RISK? REGENERATE YOUR TOKENS

If you believe that your bearer token may have been leaked, invalidate your current npm bearer tokens and rerun npm login to generate new tokens. Keep in mind that this may cause continuous integration builds in services like Travis to break, in which case you’ll need to update the tokens in your CI server’s configuration.

WILL THIS BREAK MY CURRENT SETUP?

Maybe.

npm’s CLI team believes that the fix won’t break any existing registry setups. Due to the large number of registry software suites out in the wild, though, it’s possible our change will be breaking in some cases.

If so, please file an issue describing the software you’re using and how it broke. Our team will work with you to mitigate the breakage.

CREDIT & THANKS

Thanks to Mitar, Will White & the team at Mapbox, Max Motovilov, and James Taylor for reporting this vulnerability to npm.

BACK TO YOUR REGULARLY SCHEDULED PROGRAMMING

Aside from that, it's another one of those releases again! Docs and tests, it turns out, have a pretty easy time getting into LTS releases, and boring is exactly how LTS should be. 💁

DOCS

  • 981c89c #11820 The basic explanation for how npm link works was a bit confusing, and somewhat incorrect. It should be clearer now. (@rhgb)
  • 35b2b45 #11787 The verison alias for npm version no longer shows up in the command list when you do npm -h. (@doug-wade)
  • 1c9d00f #11786 Add a comment to the npm-scope.md docs about npm@>=2 being required in order to use scoped packaged. (@doug-wade)
  • 7d64fb1 #11762 Roll back patch that previously advised people to use --depth Infinity instead of --depth 9999. Just keep using --depth 9999. (@GriffinSchneider)

TESTS

  • 98a9ee4 #11912 Did you know npm can install itself? npm install -g npm is the way to upgrade! Turns out that one of the tests that verified this functionality got rewritten as part of our recent push for better tests, and in the process omitted a detail about how the test ran. We're testing that corner case again, now, by moving the install folder to /tmp, where the original legacy test ran. (@iarna)

v2.15.0 (2016-03-10):

WHY IS THIS SEMVER-MINOR I THOUGHT THIS WAS LTS

A brief note about LTS this week!

npm, as you may know if you're using this 2.x branch, has an LTS process for releases. We also try and play nice with Node.js' own LTS release process. That means we generally try to avoid things like minor version bumps on our 2.x branch (which is also tagged lts in the dist-tags).

That said, we had a minor-bump update recently for [email protected] which added a maxsockets option to allow users to configure the number of concurrent sockets that npm would keep open at a time -- a setting that has the potential to help a bunch for people with fussy routers or internet connections that aren't very happy with Node.js applications' usual concurrency storm. This change was done to npm-registry-client, which we don't have a parallel LTS-tracking branch for.

After talking it over, we ended up deciding that this was a reasonable enough addition to LTS, even though it's technically a semver-minor bump, taking into account both its potential for bugfixing (specially on 2.x!) and the general hassle it would be to maintain another branch for npm-registry-client.

DOC PATCH IS HERE TOO

  • 0ae9f74 #11748 Add command aliases as a separate section in documentation for npm subcommands. (@watilde)

DEP UPDATES

v2.14.22 (2016-03-03):

This week is all documentation improvements. In case you hadn't noticed, we love doc patches. We love them so much, we give socks away if you submit documentation PRs!

These folks are all getting socks if they ask for them. The socks are super-sweet. Do you have yours yet? 👣

v2.14.21 (2016-02-25):

Good news, everyone! There's a new LTS release with a few shinies here and there!

USE THIS ONE INSTEAD

We had some cases where the versions of npm and node used in some scripting situations were different than the ideal, or what folks actually expected. These should be particularly helpful to our Windows friends! <3

  • 02813c5 #9253 Fix a bug where, when running lifecycle scripts, if the Node.js binary you ran npm with wasn't in your PATH, npm wouldn't use it to run your scripts. (@segrey and @narqo)
  • a985dd5 #11526 Prefer locally installed npm in Git Bash -- previous behavior was to use the global one. This was done previously for other shells, but not for Git Bash. (@destroyerofbuilds)

SOCKS FOR THE SOCK GOD

INTERNAL TEST IMPROVEMENTS

The npm CLI team's time recently has been sunk into npm's many years of tech debt. Specifically, we've been working on improving the test suite. This isn't user visible, but in future should mean a more stable, easier to contribute to npm. Ordinarily we don't report these kinds of changes in the change log, but I thought I might share this week as this chunk is bigger than usual.

These patches were previously released for npm@3, and then ported back to npm@2 LTS.

  • 437c537 #11613 Fix up one of the tests after rebasing the legacy test rewrite to npm@2. (@zkat)
  • 55abd0c #11613 Test that the package.json files section and .npmignore do what they're supposed to. (@zkat)
  • a2b99b6 #11613 Test that npm's distribution binary is complete and can be installed and used. (@iarna)
  • 8a8c36c #11613 Test that environment variables are properly passed into scripts. (@iarna)
  • a95b550 #11613 Test that we don't leak auth info into the environment. (@iarna)
  • a1c1c52 #11613 Remove all the relatively cryptic legacy tests and creates new tap tests that check the same functionality. The legacy tests were tests that were originally a shell script that was ported to javascript early in npm's history. (@iarna and @zkat)
  • 9d89581 #11613 [email protected]: Add a package that provides a tool to generate fixtures from folders and, relatedly, a module that an create and tear down filesystem fixtures easily. (@iarna)

v2.14.20 (2016-02-18):

Hope y'all are having a nice week! As usual, it's a fairly limited release. The most notable thing is some dependency updates that might help the Node.js CI setup for Windows run a little better, even if we have some work to do on that path length things, still.

WHITTLING AWAY AT PATH LENGTHS

So for all of you who don't know -- Node.js does, in fact, support long Windows paths. Unfortunately, depending on the tool and the Windows version, a lot of external tooling does not. This means, for example, that some (all?) versions of Windows Explorer can literally never delete npm from their system entirely because of deeply-nested npm dependencies. Which is pretty gnarly.

Incidentally, if you run into that in particularly, you can use rimraf to remove such files 💁.

The latest victim of this issue was the Node.js CI setup for testing on Windows, which uses some tooling or another that croaks on the usual path length limit for that OS: 255 characters.

This issue, of course, is largely not a problem as of npm@3, with its flat trees, but it still occasionally and viciously bites LTS.

We've taken another baby step towards alleviating this in this release by updating a couple of dependencies that were preventing npmlog from deduping, and then doing a dedupe on that and gauge. Hopefully it helps.

OTHER DEP STUFF

@wyze, DOCUMENTATION HERO OF THE PEOPLE, GETS THEIR OWN HEADER

v2.14.19 (2016-02-11):

Really tiny micro-release this week! The main thing to note is a dependency update that means we no longer have graceful-fs@3 in our dependency tree. This has some implications for being able to run on future Node.js releases, so better to get this out the door. 😁

DEPS

DOCS

  • 69a2d59 #11391 Fixed versions of shrinkwrap.json in examples in documentation for npm shrinkwrap, which did not quite match up. (@xcatliu)

v2.14.18 (2016-02-04):

Clearly our docs are perfect after all those wonderful PRs, 'cause this week's gonna be all about dependency updates. Note: There is a small security-related fix included here!

SECURITY-RELATED DEPENDENCY UPDATE

OTHER DEPENDENCY UPDATES

v2.14.17 (2016-01-28):

Another week, another small LTS release!

BETTER ERROR REPORTING YAY

So as it turns out, when stuff goes wrong, it's actually nice to give people a better clue rather than just say "oh well 😏".

  • 5b8ccb9 #11289 There is an obscure feature that lets you monkey-patch npm when it starts up. If the module being required with this feature failed, it would previous just make npm error out– this reduces that to a warning. (@evanlucas)
  • 556e42a #11300 Report symlinked packages as 'linked' in the output for npm outdated. (@halhenke)
  • 3842317 #11290 Suppress warnings about pre-release node versions. This should get node's CI passing on non-Windows platforms without needing to modify the node version to get rid of the pre-release suffix. (@iarna)

EVERYONE WANTS THOSE NPM SOCKS, GEEZE

Did you know that you can get npm socks for contributing to our docs? I bet these people do, and now so do you!

v2.14.16 (2016-01-21):

Good to see you all again! It's been a while since we had an LTS release, and the team continues to work hard to both get the issue tracker under control, and get our test suite to be awesome and reliable.

This is also the first LTS release of this year.

We're gonna have an interesting time -- most of our focus this year will be around stability and maintainability of the CLI, so you might actually end up seeing a number of updates even over here, just for the sake of making sure we're stable, that bugs get fixed, and tests have proper coverage.

What better way to start this effort, then, than getting Travis tests green, fix a few things here and there, and tweak a bunch of documentation? 😁

FIX ALL THE BUGS AND TWEAK ALL THE THINGS

DOCS DOCS DOCS

We got a TON of lovely documentation patches, too! Thanks all for submitting!

I REALLY LIKE GREEN. CAN YOU TELL?

So Travis is all green now on npm@2, thanks to the removal of nock and a few other test suite tweaks. This is a fantastic step towards making sure we can all have confidence in our test suite! 🎉

v2.14.15 (2015-12-10):

Did you know that Bob Ross reached the rank of master sergeant in the US Air Force before becoming perhaps the most soothing painter of all time?

TWO HAPPY LITTLE BUG FIXES

  • f482664 #10505 npm ls --json --depth=0 now respects the depth parameter, when it is zero and when it is not zero. (@MarkReeder)
  • 529fa1f #9099 I had always thought you could run npm version from subdirectories in your project, which is great, because now you can. I guess I was just ahead of my time. (@ekmartin)

NOW PAINT IN SOME NICE DOCS CHANGES

  • 1fc7f2b #10546 Goodbye, FAQ! You were cheeky and fun until you weren't! Don't worry: npm still loves everyone, especially you! (@ashleygwilliams)
  • 7fe6950 #10570 Update documentation URLs to be HTTPS everywhere sensible. No HTTP shall be spared! (@rsp)
  • 96ebb90 #10650 Correctly note that there are two lifecycle scripts run by an install phase in an example, instead of three. (@eymengunay)
  • 5196893 #10687 npm outdated's output can be a little puzzling sometimes. I've attempted to make it clearer, with some examples, of what's going on with "wanted" and "latest" in more cases. (@othiym23)
  • 8e6712d #10700 Hey, do you remember when search.npmjs.org was a thing? I think I do? The last time I used it was in like 2012, and it's gone now, so remove it from the docs. (@gagern)
  • 27d2612 [email protected]: Include BNF for SemVer expression grammar (which is also now included in npm help semver). (@isaacs)

LAND YOUR DEPENDENCY UPGRADES IN PAIRS SO EVERYONE HAS A FRIEND

v2.14.14 (2015-12-03):

FIX URL IN LICENSE

The license incorrectly identified the registry URL as registry.npmjs.com and this has been corrected to registry.npmjs.org.

NO MORE MD5

We updated modules that had been using MD5 for non-security purposes. While this is perfectly safe, if you compile Node in FIPS-compliance mode it will explode if you try to use MD5. We've replaced MD5 with Murmur, which conveys our intent better and is faster to boot.

DEPENDENCY UPDATES

v2.14.13 (2015-11-25):

THE npm CLI !== THE npm REGISTRY !== npm, INC.

npm-the-CLI is licensed under the terms of the Artistic License 2.0, which is a liberal open-source license that allows you to take this code and do pretty much whatever you like with it (that is, of course, not legal language, and if you're doing anything with npm that leaves you in doubt about your legal rights, please seek the review of qualified counsel, which is to say, not members of the CLI team, none of whom have passed the bar, to my knowledge). At the same time the primary registry the CLI uses when looking up and downloading packages is a commercial service run by npm, Inc., and it has its own Terms of Use.

Aside from clarifying the terms of use (and trying to make sure they're more widely known), the only recent changes to npm's licenses have been making the split between the CLI and registry clearer. You are still free to do whatever you like with the CLI's source, and you are free to view, download, and publish packages to and from registry.npmjs.org, but now the existing terms under which you can do so are more clearly documented. Aside from the two commits below, see also the release notes for [email protected], which is where the split between the CLI's code and the terms of use for the registry was first made more clear.

  • 1f3e936 #10532 Clarify that registry.npmjs.org is the default, but that you're free to use the npm CLI with whatever registry you wish. (@kemitchell)
  • 6733539 #10532 Having semi-duplicate release information in README.md was confusing and potentially inaccurate, so remove it. (@kemitchell)

EASE UP ON WINDOWS BASH USERS

It turns out that a fair number of us use bash on Windows (through MINGW or bundled with Git, plz – Cygwin is still a bridge too far, for both npm and Node.js). @jakub-g did us all a favor and relaxed the check for npm completion to support MINGW bash. Thanks, Jakub!

MAKE NODE-GYP A LITTLE BLUER

WE LIKE SPDX AND ALL BUT IT'S NOT ACTUALLY A DIRECT DEP, SORRY

  • 1f4b4bb Removed spdx as a direct npm dependency, since we don't actually need it at that level, and updated subdeps for validate-npm-package-license (@othiym23)

A BOUNTEOUS THANKSGIVING CORNUCOPIA OF DOC TWEAKS

These are great! Keep them coming! Sorry for letting them pile up so deep, everybody. Also, a belated Thanksgiving to our Canadian friends, and a happy Thanksgiving to all our friends in the USA.

v2.14.12 (2015-11-19):

TEEN ORCS AT THE GATES

This week heralds the general release of the primary npm registry's new support for private packages for organizations. For many potential users, it's the missing piece needed to make it easy for you to move your organization's private work onto npm. And now it's here! The functionality to support it has been in place in the CLI for a while now, thanks to @zkat's hard work.

During our final testing before the release, our ace support team member @snopeks noticed that there had been some drift between the CLI team's implementation and what npm was actually preparing to ship. In the interests of everyone having a smooth experience with this extremely useful new feature, we quickly made a few changes to square up the CLI and the web site experiences.

A BRIEF NOTE ON NPM'S BACKWARDS COMPATIBILITY

We don't often have much to say about the changes we make to our internal testing and tooling, but I'm going to take this opportunity to reiterate that npm tries hard to maintain compatibility with a wide variety of Node versions. As this change shows, we want to ensure that npm works the same across:

  • Node.js 0.8
  • Node.js 0.10
  • Node.js 0.12
  • the latest io.js release
  • Node.js 4 LTS
  • Node.js 5

Contributors who send us pull requests often notice that it's very rare that our tests pass across all of those versions (ironically, almost entirely due to the packages we use for testing instead of any issues within npm itself). We're currently beginning an effort, lasting the rest of 2015, to clean up our test suite, and not only get it passing on all of the above versions of Node.js, but working solidly on Windows as well. This is a compounding form of technical debt that we're finally paying down, and our hope is that cleaning up the tests will produce a more robust CLI that's a lot easier to write patches for.

TYPOS IN THE LICENSE, OH MY

v2.14.11 (2015-11-12):

ASK FOR NOTHING, GET LATEST

When you run npm install foo, you probably expect that you'll get the latest version of foo, whatever that is. And good news! That's what this change makes it do.

We think this is what everyone wants, but if this causes problems for you, we want to know! If it proves problematic for people we will consider reverting it (preferably before this becomes npm@latest).

Previously, when you ran npm install foo we would act as if you typed npm install foo@*. Now, like any range-type specifier, in addition to matching the range, it would also have to be <= the value of the latest dist-tag. Further, it would exclude prerelease versions from the list of versions considered for a match.

This worked as expected most of the time, unless your latest was a prerelease version, in which case that version wouldn't be used, to everyone's surprise.

LICENSE CLARIFICATION

CLOSER TO GREEN TRAVIS

A BUG FIX

A DEPENDENCY UPGRADE

v2.14.10 (2015-11-05):

There's nothing in here that that isn't in the [email protected] release notes, but all of the commit shasums have been adjusted to be correct. Enjoy!

BUG FIXES VIA DEPENDENCY UPDATES

DOCUMENTATION FIXES

DEPENDENCY UPDATES FOR THEIR OWN SAKE

v2.14.9 (2015-10-29):

There's still life in npm@2, but for now, enjoy these dependency upgrades! Also, @othiym23 says hi! waves @zkat has her hands full, and @iarna's handling npm@3, so I'm dealing with npm@2 and the totally nonexistent weird bridge [email protected] LTS release that may or may not be happening this week.

CAN'T STOP WON'T STOP UPDATING THOSE DEPENDENCIES

DEVDEPENDENCIES TOO, I GUESS, IT'S COOL

v2.14.8 (2015-10-08):

SLOWLY RECOVERING FROM FEELINGS

OS&F is definitely my favorite convention I've gone to. Y'all should check it out next year! Rebecca and Kat are back, although Forrest is out at &yet conf.

This week sees another tiny LTS release with non-code-related patches -- just CI/release things.

Meanwhile, have you heard? npm@3 is much faster now! Go upgrade with npm install -g npm@latest and give it a whirl if you haven't already!

IF YOU CHANGE CASING ON A FILE, YOU ARE NOT MY FRIEND

Seriously. I love me some case-sensitive filesystems, but a lot of us have to deal with git and its funky support for case normalizing systems. Have mercy and just don't bother if all you're changing is casing, please? Otherwise, I have to do this little dance to prevent horrible conflicts.

IDK. OUR CI DOESN'T EVEN FULLY WORK YET BUT SURE

Either way, it's nice to make sure we're running stuff on the latest Node. 4.2 is getting released very soon, though (this week?), and that'll be the first official LTS release!

v2.14.7 (2015-10-01):

MORE RELEASE STAGGERING?!

Hi all, and greetings from Open Source & Feelings!

So we're switching gears a little with how we handle our weekly releases: from now on, we're going to stagger release weeks between dependency bumps and regular patches. So, this week, aside from a doc change, we'll be doing only version bumps. Expect actual patches next week!

TOTALLY FOLLOWING THE RULES ALREADY

So I snuck this in, because it's our own @snopeks' first contribution to the main npm repo. She's been helping with building support documents for Orgs, and contributed her general intro guide to the new feature so you can read it with npm help orgs right in your terminal!

JUST. ONE. MORE.

  • 9a502ca Use unique package name in tests to work around weird test-state-based failures. (@iarna)

OKAY ACTUALLY THE THING I WAS SUPPOSED TO DO

Anyway -- here's your version bump! :)

v2.14.6 (2015-09-24):

¯\_(ツ)_/¯

Since 2.x is LTS now, you can expect a slowdown in overall release sizes. On top of that, we had our all-company-npm-internal-conf thing on Monday and Tuesday so there wasn't really time to do much at all.

Still, we're bringing you a couple of tiny little changes this week!

  • 7b7da13 #9471 When the port for a tarball is different than the registry it's in, but the hostname is the same, the protocol is now allowed to change, too. (@fastest963)
  • 6643ada [email protected]: Use application/json as the default content type when making json requests. (@simov)

v2.14.5 (2015-09-17):

NPM IS DEAD. LONG LIVE NPM

That's right folks. As of this week, npm@next is npm@3, which means it'll be npm@latest next week! There's some really great shiny new things over there, and you should really take a look.

Many kudos to @iarna for her hard work on npm@3!

Don't worry, we'll keep 2.x around for a while (as LTS), but you won't see many, if any, new features on this end. From now on, we're going to use latest-2 and next-2 as the dist tags for the npm@2 branch.

OKAY THAT'S FINE CAN I DEPRECATE THINGS NOW?

Yes! Specially if you're using scoped packages. Apparently, deprecating them never worked, but that should be better now. :)

WTF IS node-waf

idk. Some old thing. We don't talk about it anymore.

  • cf1b39f #9584 Fix ancient references to node-waf in the docs to refer to the node-gyp version of things. (@KenanY)

THE graceful-fs AND node-gyp SAGA CONTINUES

Last week had some sweeping graceful-fs upgrades, and this takes care of one of the stragglers, as well as bumping node-gyp. node@4 users might be excited about this, or even node@<4 users who previously had to cherry-pick a bunch of patches to get the latest npm working.

DEPS! DEPS! MORE DEPS! OK STOP DEPS

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:

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

OTHER PATCHES

MORE DEPENDENCIES!

DOC UPDATES

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:

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

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 [email protected]:

  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 [email protected] as soon as possible. If you believe you may have inadvertently leaked your credentials, upgrade to [email protected] 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 [email protected]: 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

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 [email protected]: 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

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.

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)

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

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.

READ THE FINE DOCS. THEY'VE IMPROVED

MORE NUMBERS! MORE VALUE!

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?"?

[email protected] 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 [email protected] and go straight to [email protected]. 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://[email protected]: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.

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

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

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

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

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

DOCUMENTATION IMPROVEMENTS

DEPENDENCY UPDATES! ALWAYS AND FOREVER!

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!

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.

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 [email protected]: 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 [email protected]: 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 [email protected] 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

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

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. [email protected] is where the real action is.

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.

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 [email protected] 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.)

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

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 [email protected] 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.

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 [email protected]: 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. [email protected] completely broke installing private modules from GitHub, and [email protected] 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 [email protected], 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 <script> -- `. This is a tricky change to test, and may be reverted or moved to `npm@3` if it turns out it breaks things for users. ([@mantoni](https://github.com/mantoni))
  • da015ee #7074 [email protected]: read-package-json no longer caches package.json files, which trades a very small performance loss for the elimination of a large class of really annoying race conditions. See #7074 for the grisly details. (@othiym23)
  • dd20f57 [email protected]: Only add the @ to scoped package names if it's not already there when reading from the filesystem (@watilde), and support inline validation of package names (@michaelnisi).

SMALL FIXES AND DEPENDENCY UPGRADES

v2.7.5 (2015-03-26):

SECURITY FIXES

  • 300834e [email protected]: Normalize symbolic links that point to targets outside the extraction root. This prevents packages containing symbolic links from overwriting targets outside the expected paths for a package. Thanks to Tim Cuthbertson and the team at Lift Security for working with the npm team to identify this issue. (@othiym23)
  • 0dc6875 [email protected]: Package versions can be no more than 256 characters long. This prevents a situation in which parsing the version number can use exponentially more time and memory to parse, leading to a potential denial of service. Thanks to Adam Baldwin at Lift Security for bringing this to our attention. (@isaacs)

BUG FIXES

DEPENDENCY UPDATES

DOCUMENTATION FIXES

v2.7.4 (2015-03-20):

BUG FIXES

DEPENDENCY UPDATES

A NEW REGRESSION TEST

  • 3703b0b Add regression test for npm version to ensure message property in config continues to be honored. (@dannyfritz)

v2.7.3 (2015-03-16):

HAHA WHOOPS LIL SHINKWRAP ISSUE THERE LOL

  • 1549106 #7641 Due to 448efd0, running npm shrinkwrap --dev caused production dependencies to no longer be included in npm-shrinkwrap.json. Whoopsie! (@othiym23)

v2.7.2 (2015-03-12):

NPM GASTROENTEROLOGY

  • fb0ac26 #7579 Only block removing files and links when we're sure npm isn't responsible for them. This change is hard to summarize, because if things are working correctly you should never see it, but if you want more context, just go read the commit message, which lays it all out. (@othiym23)
  • 051c473 #7552 bundledDependencies are now properly included in the installation context. This is another fantastically hard-to-summarize bug, and once again, I encourage you to read the commit message if you're curious about the details. The snappy takeaway is that this unbreaks many use cases for ember-cli. (@othiym23)

LESS DRAMATIC CHANGES

  • fcd9247 #7597 Awk varies pretty dramatically from platform to platform, so use Perl to generate the AUTHORS list instead. (@KenanY)
  • 721b17a #7598 npm install --save really isn't experimental anymore. (@RichardLitt)

DEPENDENCY REFRESH

v2.7.1 (2015-03-05):

GITSANITY

  • 6823807 #7121 npm install --save for Git dependencies saves the URL passed in, instead of the temporary directory used to clone the remote repo. Fixes using Git dependencies when shrinkwrapping. In the process, rewrote the Git dependency caching code. Again. No more single-letter variable names, and a much clearer workflow. (@othiym23)
  • c8258f3 #7486 When installing Git remotes, the caching code was passing in the function gitEnv instead of the results of invoking it. (@functino)
  • c618eed #2556 Make it possible to install Git dependencies when using --link by not linking just the Git dependencies. (@smikes)

WHY DID THIS TAKE SO LONG.

  • abdd040 [email protected]: Provide more helpful error messages when JSON parse errors are encountered by using a more forgiving JSON parser than JSON.parse. (@smikes)

BUGS & TWEAKS

###E TYPSO & CLARFIICATIONS

dId yuo know that submiting fxies for doc tpyos is an exclelent way to get strated contriburting to a new open-saurce porject?

v2.7.0 (2015-02-26):

SOMETIMES SEMVER MEANS "SUBJECTIVE-EMPATHETIC VERSIONING"

For a very long time (maybe forever?), the documentation for npm run-script has said that npm restart will only call npm stop and npm start when there is no command defined as npm restart in package.json. The problem with this documentation is that npm run-script was apparently never wired up to actually work this way.

Until now.

If the patch below were landed on its own, free of context, it would be a breaking change. But, since the "new" behavior is how the documentation claims this feature has always worked, I'm classifying it as a patch-level bug fix. I apologize in advance if this breaks anybody's deployment scripts, and if it turns out to be a significant regression in practice, we can revert this change and move it to npm@3, which is allowed to make breaking changes due to being a new major version of semver.

  • 2f6a1df #1999 Only run stop and start scripts (plus their pre- and post- scripts) when there's no restart script defined. This makes it easier to support graceful restarts of services managed by npm. (@watilde / @scien)

A SMALL FEATURE WITH BIG IMPLICATIONS

  • 145af65 #4887 Replace calls to the node-gyp script bundled with npm by passing the --node-gyp=/path/to/node-gyp option to npm. Swap in pangyp or a version of node-gyp modified to work better with io.js without having to touch npm's code! (@ackalker)

@WATILDE'S NPM USABILITY CORNER

Following [email protected]'s unexpected fix of many of the issues with npm update -g simply by making --depth=0 the default for npm outdated, friend of npm @watilde has made several modest changes to npm's behavior that together justify bumping npm's minor version, as well as making npm significantly more pleasant to use:

  • 448efd0 #2853 Add support for --dev and --prod to npm ls, so that you can list only the trees of production or development dependencies, as desired. (@watilde)
  • a0a8777 #7463 Split the list printed by npm run-script into lifecycle scripts and scripts directly invoked via npm run-script. (@watilde)
  • a5edc17 #6749 [email protected]: Support for passing scopes to npm init so packages are initialized as part of that scope / organization / team. (@watilde)

SMALLER FEATURES AND FIXES

It turns out that quite a few pull requests had piled up on npm's issue tracker, and they included some nice small features and fixes:

  • f33e8b8 #7354 Add --if-present flag to allow e.g. CI systems to call (semi-) standard build tasks defined in package.json, but don't raise an error if no such script is defined. (@jussi-kalliokoski)
  • 7bf85cc #4005 #6248 Globally unlink a package when npm rm / npm unlink is called with no arguments. (@isaacs)
  • a2e04bd #7294 Ensure that when depending on git+<proto> URLs, npm doesn't keep tacking additional git+ prefixes onto the front. (@twhid)
  • 0f87f5e #6422 When depending on GitHub private repositories, make sure we construct the Git URLS correctly. (@othiym23)
  • 50f461d #4595 Support finding compressed manpages. It's still up to the system to figure out how to display them, though. (@pshevtsov)
  • 44da664 #7465 When calling git, log the full command, with all arguments, on error. (@thriqon)
  • 9748d5c Add parent to error on ETARGET error. (@davglass)
  • 37038d7 #4663 Remove hackaround for Linux tests, as it's evidently no longer necessary. (@mmalecki)
  • d7b7853 #2612 Add support for path completion on npm install, which narrows completion to only directories containing package.json files. (@deestan)
  • 628fcdb Remove all command completion calls to -/short, because it's been removed from the primary registry for quite some time, and is generally a poor idea on any registry with more than a few hundred packages. (@othiym23)
  • 3f6061d #6659 Instead of removing zsh completion global, make it a local instead. (@othiym23)

DOCUMENTATION TWEAKS

  • 5bc70e6 #7417 Provide concrete examples of how the new npm update defaults work in practice, tied to actual test cases. Everyone interested in using npm update -g now that it's been fixed should read these documents, as should anyone interested in writing documentation for npm. (@smikes)
  • 8ac6f21 #6543 Clarify npm-scripts warnings to de-emphasize dangers of using install scripts. (@zeke)
  • ebe3b37 #6711 Note that git tagging of versions can be disabled via --no-git-tag-verson. (@smikes)
  • 2ef5771 #6711 Document git-tag-version configuration option. (@KenanY)
  • 95e59b2 Document that NODE_ENV=production behaves analogously to --production on npm install. (@stefaneg)
  • 687117a #7463 Document the new script grouping behavior in the man page for npm run-script. (@othiym23)
  • 536b2b6 Rescue one of the the disabled tests and make it work properly. (@smikes)

DEPENDENCY UPDATES

v2.6.1 (2015-02-19):

v2.6.0 (2015-02-12):

A LONG-AWAITED GUEST

DEPRECATIONS

  • c8e08e6 #6565 Warn that peerDependency behavior is changing and add a note to the docs. (@othiym23)
  • 7c81a5f #7171 Warn that engineStrict in package.json will be going away in the next major version of npm (coming soon!) (@othiym23)

BUG FIXES & TWEAKS

Also typos and other documentation issues were addressed by @rutsky, @imurchie, @marcin-wosinek, @marr, @amZotti, and @karlhorky. Thank you, everyone!

v2.5.1 (2015-02-06):

This release doesn't look like much, but considerable effort went into ensuring that npm's tests will pass on io.js 1.1.0 and Node 0.11.16 / 0.12.0 on both OS X and Linux.

NOTE: there are no actual changes to npm's code in [email protected]. Only test code (and the upgrade of request to the latest version) has changed.

[email protected]:

MINOR DEPENDENCY TWEAK

v2.5.0 (2015-01-29):

SMALL FEATURE I HAVE ALREADY USED TO MAINTAIN NPM ITSELF

  • 9d61e96 npm outdated --long now includes a column showing the type of dependency. (@watilde)

BUG FIXES & TWEAKS

[email protected]:

v2.4.1 (2015-01-23):

bridge that doesn't meet in the middle

Let's accentuate the positive: the dist-tag endpoints for npm dist-tag {add,rm,ls} are now live on the public npm registry.

v2.4.0 (2015-01-22):

REGISTRY 2: ACCESS AND DIST-TAGS

NOTE: This week's registry-2 commands are leading the implementation on registry.npmjs.org a little bit, so some of the following may not work for another week or so. Also note that npm access has documentation and subcommands that are not yet finished, because they depend on incompletely specified registry API endpoints. Things are coming together very quickly, though, so expect the missing pieces to be filled in the coming weeks.

NOT EXACTLY SELF-DEPRECATING

BUG FIX AND TINY FEATURE

v2.3.0 (2015-01-15):

REGISTRY 2: OH MY STARS! WHO AM I?

BETTER REGISTRY METADATA CACHING

HOW MUCH IS THAT WINDOWS IN THE DOGGY?

THRILLING BUG FIXES

v2.2.0 (2015-01-08):

v2.1.18 (2015-01-01):

v2.1.17 (2014-12-25):

merry npm xmas

Working with @phated, I discovered that npm still had some lingering race conditions around how it handles Git dependencies. The following changes were intended to remedy to these issues. Thanks to @phated for all his help getting to the bottom of these.

Other changes:

v2.1.16 (2014-12-22):

v2.1.15 (2014-12-18):

v2.1.14 (2014-12-13):

v2.1.13 (2014-12-11):

v2.1.12 (2014-12-04):

v2.1.11 (2014-11-27):

v2.1.10 (2014-11-20):

v2.1.9 (2014-11-13):

v2.1.8 (2014-11-06):

v2.1.7 (2014-10-30):

v2.1.6 (2014-10-23):

v2.1.5 (2014-10-16):

OUTDATED DEPENDENCY CLEANUP JAMBOREE

v2.1.4 (2014-10-09):

TEST CLEANUP EXTRAVAGANZA:

v2.1.3 (2014-10-02):

BREAKING CHANGE FOR THE SQRT(i) PEOPLE ACTUALLY USING npm submodule:

  • 1e64473 rm -rf npm submodule command, which has been broken since the Carter Administration (@isaacs)

BREAKING CHANGE IF YOU ARE FOR SOME REASON STILL USING NODE 0.6 AND YOU SHOULD NOT BE DOING THAT CAN YOU NOT:

Other changes:

v2.1.2 (2014-09-29):

v2.1.1 (2014-09-26):

v2.1.0 (2014-09-25):

NEW FEATURE:

Other changes:

v2.0.2 (2014-09-19):

v2.0.1 (2014-09-18):

v2.0.0 (2014-09-12):

BREAKING CHANGES:

  • 4378a17 [email protected]: prerelease versions no longer show up in ranges; ^0.x.y behaves the way it did in semver@2 rather than semver@3; docs have been reorganized for comprehensibility (@isaacs)
  • c6ddb64 npm now assumes that node is newer than 0.6 (@isaacs)

Other changes:

v2.0.0-beta.3 (2014-09-04):

v2.0.0-beta.2 (2014-08-29):

SPECIAL LABOR DAY WEEKEND RELEASE PARTY WOOO

v2.0.0-beta.1 (2014-08-28):

v2.0.0-beta.0 (2014-08-21):

v2.0.0-alpha.7 (2014-08-14):

v2.0.0-alpha.6 (2014-08-07):

BREAKING CHANGE:

  • ea547e2 Bump semver to version 3: ^0.x.y is now functionally the same as =0.x.y. (@isaacs)

Other changes:

v2.0.0-alpha-5 (2014-07-22):

This release bumps up to 2.0 because of this breaking change, which could potentially affect how your package's scripts are run:

Other changes: