"Fossies" - the Fresh Open Source Software Archive

Member "Atom/resources/app/apm/node_modules/npm/CHANGELOG.md" (25 Nov 2016, 220155 Bytes) of archive /windows/misc/atom-windows.zip:


As a special service "Fossies" has tried to format the requested source page into HTML format (assuming markdown format). Alternatively you can here view or download the uninterpreted source code file. A member file download can also be achieved by clicking within a package contents listing on the according byte size field.

v3.10.5 (2016-07-05)

This is a fix to this week's testing release to correct the update of node-gyp which somehow got mangled.

v3.10.4 (2016-06-30)

Hey y'all! This release includes a bunch of fixes we've been working on as we continue on our big-bug push. There's still a lot of it left to do, but once this is done, things should just generally be more stable, installs should be more reliable and correct, and we'll be able to move on to more future work. We'll keep doing our best! 🙌

RACES AS WACKY AS REDLINE

Races are notoriously hard to squash, and tend to be some of the more common recurring bugs we see on the CLI. [@julianduque](https://github.com/julianduque) did some pretty awesome sleuthing work to track down a cache race and helpfully submitted a patch. There were some related races in the same area that also got fixed at around the same time, mostly affecting Windows users.

SHRINKWRAP IS COMPLICATED BUT IT'S BETTER NOW

[@iarna](https://github.com/iarna) did some heroic hacking to refactor a bunch of shrinkwrap-related bits and fixed some resolution and pathing issues that were biting users. The code around that stuff got more readable/maintainable in the process, too!

OTHER BUGFIXES

DEPENDENCY UPDATES

DOCUMENTATION FIXES

v3.10.3 (2016-06-23)

Given that we had not one, but two updates to our RC this past week, it should come as no surprise that this week's full release is a bit lighter. We have some documentation patches and a couple of bug fixes via dependency updates.

If you haven't yet checked out last week's release, v3.10.0 and the two follow up releases v3.10.1 and v3.10.2, you really should do so. They're the most important releases we've had in quite a while, fixing a bunch of critical bugs (including an issue impacting publishing with Node.js 6.x) and of course, bringing in the new and improved progress bar.

There's been a bug lurking where broken symlinks in your node_modules folder could cause all manner of mischief, from crashes to empty npm ls results. The intrepid [@watilde](https://github.com/watilde) tracked this down for us.

This addresses the root cause of the outdated crasher we protected against earlier this week in #13115.

This also fixes #9564, the problem where a bad symlink in your global modules would result in an empty result when you ran npm ls -g.

This ALSO likely fixes numerous "Missing argument #1" errors. (But surely not all of them as that's actually just a generic arity and type-validation failure.)

BETTER UNICODE DETECTION

DOCUMENTATION FIXES

DEPENDENCY UPDATES

v3.10.2 (2016-06-17):

This is a quick hotfix release with two small bug fixes. First, there was an issue where the new progress bar would overwrite interactive prompts, that is, those found in npm login and npm init. Second, if the directory you were running npm outdated on was a bad link or otherwise had unrecoverable errors then npm would crash instead of printing the error.

v3.10.1 (2016-06-17):

There are two very important bug fixes and one 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.

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 fstream@1.0.10 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.

ERK

Because the interaction between fstream, fstream-ignore, fsream-npm, and node-tar is so complex, it's proven difficult to add support for npm features like bundledDependencies without duplicating some logic within npm's code base. While fixing a completely unrelated bug, we "cleaned up" some of this seemingly duplicated code, and in the process removed the code that ensured that the dependencies of bundledDependencies are themselves bundled. We've brought that code back into the code base (without reopening #9642), and added a test to ensure that this regression can't recur.

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.

v3.10.0 (2016-06-16):

Do we have a release for you! We have our first new lifecycle since version, a new progress bar and a bunch of bug fixes. I'm really excited about this release, let me tell you!!

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.

NEW LIFECYCLE SCRIPT: shrinkwrap

preshrinkwrap and shrinkwrap is run prior to generating the new npm-shrinkwrap.json and postshrinkwrap is run after. ([@SimenB](https://github.com/SimenB))

NEW PROGRESS BAR

Install with new progress bar

Install with new progress bar

We have a new progress bar and a bunch of related improvements!

BLOCKING BLOCKING

!!WARNING!! As a part of this change we now explicitly set process.stdout and process.stderr to be blocking if they are ttys, using set-blocking. This is necessary to ensure that we can fully erase the progress bar before we start writing other things out to the console.

Prior to Node.js 6.0.0, they were already blocking on Windows, and MacOS. Meanwhile, on Linux they were always non-blocking but had large (64kb) buffers, which largely made this a non-issue there. Starting with Node.js 6.0.0 they became non-blocking on MacOS and that caused some unexpected issues (see nodejs/node#6456).

If you are a Linux user, it's plausible that this might have a performance impact if your terminal can't keep up with output rate. If you experience this, we want to know! Please file an issue at our issue tracker.

BETTER LAYOUT

Let's start by talking about what goes into the new progress bar:

⸨░░░░░░░░░░⠂⠂⠂⠂⠂⠂⠂⠂⸩ ⠹ loadExtraneous: verb afterAdd /Users/rebecca/.npm/null/0.0.0/package/package.json written
 ↑‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾  ↑ ‾‾‾‾‾‾‾‾‾↑‾‾‾‾   ‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾↑‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
 percent complete     spinner    current thing we're doing     most recent log line

The spinner is intended as an activity indicator–it moves whenever npm sends something to its logs. It also spins at a constant speed while waiting on the network.

The current thing we're doing relates to how we track how much work has been done. It's the name of the unit of work we most recently started or completed some of. Sometimes these names are more obvious than others and that's something we'll look at improving over time.

And finally, the most recent log line is exactly that, it's the most recent line that you would have seen if you were running with --loglevel=silly or were watching the npm-debug.log. These are written to be useful to the npm developers above all else, so they may sometimes be a little cryptic.

MORE PERFORMANT

The underlying code for the progress bar was rewritten, in part with performance in mind. Previously whenever you updated the progress bar it would check an internal variable for how long it had been since the last update and if it had been long enough, it would print out what you gave it. With the new progress bar we do updates at a fixed interval (with setInterval) and "updating" the progress bar just updates some variables that will be used when the next tick of the progress bar happens. Currently progress bar updates happen every 50ms, although that's open to tuning.

WIDE(R) COMPATIBILITY

I spent a lot of time working our Unicode support. There were a few issues that plagued us:

Previously one of the characters we used was ambiguous width which means that it was possible to configure your terminal to display it as full width. If you did this, the output would be broken because we assumed it was a half width character. We no longer use any of these characters.

Previously, we defaulted to using Unicode on Windows. This isn't a safe assumption, however, as folks in non-US locales often use other code pages for their terminals. Windows doesn't provide* any facility available to Node.js for determining the current code page, so we no longer try to use Unicode on Windows.

* The facilities it does provide are a command line tool and a windows system call. The former isn't satisfactory for speed reasons and the latter can't be accessed from a JS-only Node.js program.

FOR THE FUTURE: THEMES

The new version of the progress bar library supports plugable themes. Adding support to npm shouldn't be too difficult. The built in themes are:

LESS GARBLED OUTPUT

As a part of landing this I've also taken the opportunity to more systematically disable the progress bar prior to printing to stdout or running external commands (in particular: git). This should ensure that the progress bar doesn't get left on screen after something else prints something. We also are now much more zealous about erasing the progress bar on exit, so if you Ctrl-C out of an install we'll still cleanup the progress bar.

REPLACE process.nextTick WITH asap ASAP

FIXES AND REFACTORING

Sometimes the installer would get it into its head that it could move or remove things that it really shouldn't have. While the reproducers for this were often a bit complicated (the core reproducer involved five symlinks(!)), it turns out this is an easy scenario to end up in if your project has a bunch of small modules and you're linking them while developing them.

Fixing this ended up involving doing an important and overdue rewrite of how the installer keeps track of (and interrogates) the relationships between modules. This likely fixes other related bugs, and in the coming weeks we'll verify and close them as we find them. There are a whole slew of commits related to this rewrite, and if you'd like to learn more check out the PR where I describe what I did in detail: #12775

MAKE OUTDATED MORE WIDELY LEGIBLE

DOCUMENTATION UPDATE

DEPENDENCY UPDATES

v3.9.6 (2016-06-02):

SMALL OUTPUT TWEAK

DOC UPDATES

DEPENDENCY UPDATES

v3.9.5 (2016-05-27):

Just a quick point release. We had an issue where I (Kat) included the .nyc_output/ directory in npm@3.9.3 and npm@3.9.4. The issue got reported right after that second release (#12873), and now there's this small point release that's there to fix the issue sooner.

v3.9.4 (2016-05-26):

Hey all! It's that time again!

This week continues our current big-bug squashing push, although there's none that are ready to release quite yet -- we're working on it!

It's also worth noting that we're entering the main part of conference season, so you can probably expect a bit of a dev slowdown as a lot of us wombats attend or speak at the various conferences. Remember npm.camp is happening in 2 months and the lineup is looking pretty great! Tickets are still on sale. Come hang out with us! WOO FUN! 🎉😸

BUGFIX

DOC UPDATES

DEP UPDATES

TEST IMPROVEMENTS

So it turns out, t.comment in tap is actually pretty nice! There's also a couple other test improvements by Rebecca landing here.

v3.9.3 (2016-05-19):

This week continues our big-bug squashing adventure! Things are churning along nicely, and we've gotten a lot of fantastic contributions from the community. Please keep it up!

A quick note on last week's release: We had a small npm shrinkwrap-related crasher in npm@3.9.1, so once this release goes out, v3.9.2 is going to be npm@latest. Please update if you ended up in with that previous version!

Remember we have a weekly team meeting, and you can suggest agenda items in the GitHub issue. Keep an eye out for the #npmweekly tag on Twitter, too, and join the conversation! We'll do our best to address questions y'all send us. ✌

FIXES

NOTABLE DEPENDENCY UPDATES

OTHER DEPENDENCY UPDATES

v3.9.2 (2016-05-17)

This is a quick patch release. The previous release, 3.9.1, introduced a bug where npm would crash given a combination of specific package tree on disk and a shrinkwrap.

v3.9.1 (2016-05-12)

HI all! We have bug fixes to a couple of the hairy corners of npm, in the form of shrinkwraps and bundled dependencies. Plus some documentation improvements and our lodash deps bot a bump.

This is our first week really focused on getting the big bugs list down. Our work from this week will be landing next week, and I can't wait to tell you about that! (It's about symlinks!)

SHRINKWRAP FIX

BUNDLED DEPENDENCIES FIX

DOCS IMPROVEMENTS

DEPENDENCY UPDATES

v3.9.0 (2016-05-05)

Wow! This is a big release week! We've completed the fixes that let the test suite pass on Windows, plus more general bug fixes we found while fixing things on Windows. Plus a warning to help folks work around a common footgun. PLUS an improvement to how npm works with long cache timeouts.

INFINITE CACHE A LITTLE BETTER

WARNING: FOOTGUN

WINDOWS CI

We have Windows CI setup now! We still have to tweak it a little bit around paths to the git binaries, but it's otherwise ready!

COVERAGE DATA

Not only do our tests produce coverage reports after they run now, we also automatically update Coveralls with results from Travis CI runs.

EVERYONE BUGS

WINDOWS BUGS

WINDOWS REFACTORING

FIX WINDOWS TESTS

As I said before, our tests are passing on Windows! 🎉

DEPENDENCY UPDATES

v3.8.9 (2016-04-28)

Our biggest news this week is that we got the Windows test suite passing! It'll take a little longer to get it passing in our Windows CI but that's coming soon too.

That means we'll be shifting gears away from tests to fixing Big Bugs™ again. Join us at our team meeting next Tuesday to learn more about that.

BUG FIXES AND REFACTORING

This makes the error code you get on Windows match that from MacOS/Linux if you try to read a package.json from a path that includes a file, not a folder. ([@zkat](https://github.com/zkat))

v3.8.8 (2016-04-21)

Hi all! Long time no see! We've been heads-down working through getting our test suite passing on Windows. Did you know that we have Windows CI now running over at Appveyor? In the meantime, we've got a bunch of dependency updates, some nice documentation improvements and error messages when your package.json contains invalid JSON. (Yeah, I thought we did that last one before too!)

BAD JSON IS BAD

DOCUMENTATION

TESTS

DEPENDENCY UPDATES

Also, stop converting local module/tarballs into full paths in this module. We do already do that in realize-package-specifier, which is more appropriate as it knows what package we're installing relative to. ([@zkat](https://github.com/zkat)) * ada2e93 realize-package-specifier@3.0.3: Require the new npm-package-arg, plus fix a case where specifiers that were maybe a tag, maybe a local filename were resolved differently than those that were definitely a local filename. ([@zkat](https://github.com/zkat)) ([@iarna](https://github.com/iarna)) * adc515b fs-vacuum@1.2.9: A fix for AIX where a non-empty directory can cause fs.rmDir to fail with EEXIST instead of ENOTEMPTY and three new tests ([@richardlau](https://github.com/richardlau))

Code cleanup, CI & dependency updates. ([@othiym23](https://github.com/othiym23)) * ef53a46 tap@5.7.1 ([@isaacs](https://github.com/isaacs)) * df1f2e4 request@2.72.0: Fix crashes when response headers indicate gzipped content but the body is empty. Add support for the deflate content encoding. ([@simov](https://github.com/simov)) * 776c599 readable-stream@2.1.0: Adds READABLE_STREAM env var that, if set to disable, will make readable-stream use the local native node streams instead. ([@calvinmetcalf](https://github.com/calvinmetcalf)) * 10d6d55 normalize-git-url@3.0.2: Add support git+file:// type URLs. ([@zkat](https://github.com/zkat)) * 75017ae lodash.union@4.3.0 ([@jdalton](https://github.com/jdalton))

v3.8.7 (2016-04-07)

IMPROVED DIAGNOSTICS

IMPROVE AUTO-INCLUDES

With npm@3 such extraneously bundled modules would not be ordinarily used, as things in node_modules in packages are ignored entirely if the package isn't marked as bundling modules.

Because of this npm@3 behavior, the files-and-ignores test failed to catch this as it was testing install output not what got packed. That has also been fixed. ([@glenjamin](https://github.com/glenjamin))

DOCUMENTATION UPDATES

DEPENDENCY UPDATES

v3.8.6 (2016-03-31)

Heeeeeey y'all.

Kat here! Rebecca's been schmoozing with folks at Microsoft Build, so I'm doing the npm@3 release this week.

Speaking of Build, it looks like Microsoft is doing some bash thing. This might be really good news for our Windows users once it rolls around. We're keeping an eye out and feeling hopeful. 🙆

As far as the release goes: 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!

FIXES

DOC UPDATES

DEP BUMPS

v3.8.5 (2016-03-24)

Like my esteemed colleague [@zkat](https://github.com/zkat) said in this week's LTS release notes, this week is another small release but we are continuing to work on our Windows efforts.

You may also be interested in reading the LTS process and policy that [@othiym23](https://github.com/othiym23) put together recently. If you have any feedback, we would love to hear.

Well then, don't do that.

ERR MODULE LIST TOO LONG

ELIMINATE UNUSED MODULE

DOCUMENTATION IMPROVEMENTS

FEWER NETWORK TESTS

v3.8.4 (2016-03-24)

Was erroneously released with just a changelog typo correction and was otherwise the same as 3.8.3.

v3.8.3 (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.

PERFORMANCE IMPROVEMENTS

The updated are-we-there-yet changes how it tracks how complete things are to be much more efficient. The summary is that are-we-there-yet was refactored to remove an expensive tree walk.

The result for you should be faster installs when working with very large trees.

Previously are-we-there-yet computed this when you asked by passing the request down its tree of progress indicators, totaling up the results. In doing so, it had to walk the entire tree of progress indicators.

By contrast, are-we-there-yet now updates a running total when a change is made, bubbling that up the tree from whatever branch made progress. This bubbling was already going on so there was nearly no cost associated with taking advantage of it.

DUCT TAPE FOR BUGS

TypeError: Cannot read property 'target' of null

This doesn't fix the bugs, but it does at least make the installer less likely to explode. ([@thefourtheye](https://github.com/thefourtheye))

DOC FIXES

DEPENDENCY UPDATES

TEST FIXES FOR THE SELF TESTS

v3.8.2 (2016-03-10):

HAVING TROUBLE INSTALLING C MODULES ON ANDROID?

This release includes an updated node-gyp with fixes for Android.

NPM LOGOUT CLEANS UP BETTER

HELP MORE HELPFUL

MORE COMPLETE CONFIG LISTINGS

DEPTH LIMITED PARSEABLE DEP LISTINGS

PROGRESS FOR THE (NON) UNICODE REVOLUTION

npm view --json, NOW ACTUALLY JSON

DOCUMENTATION CHANGES

GLOB FOR THE GLOB THRONE

v3.8.1 (2016-03-03):

This week the install summary got better, killing your npm process now also kills the scripts it was running and a rarely used search flag got documented.

Our improvements on the test suite on Windows are beginning to pick up steam, you can follow along by watching the PR.

BETTER INSTALL SUMMARIES

This fixes an issue where npm install --production <module> would result in npm exiting with an error code. The --production flag would make npm ls filter out <module> as it wasn't saved to the package.json and thus wasn't a production dependency. The install report is limited to show just the modules installed, so with that filtered out nothing is available. With nothing available npm ls would set npm to exit with an error code. ([@ixalon](https://github.com/ixalon)) * 99337b4 #11600 Make the report of installed modules really only show those modules that were installed. Previously it selected which modules from your tree to display based on name@version which worked great when your tree was deduped but would list things it hadn't touched when there were duplicates. ([@iarna](https://github.com/iarna))

SCRIPTS BETTER FOLLOW THE LEADER

SEARCHING SPECIFIC REGISTRIES

LODASH UPDATES

v3.8.0 (2016-02-25):

This week brings a quality of life improvement for some Windows users, and an important knob to be tuned for folks experiencing network problems.

LIMIT CONCURRENT REQUESTS

We've long known that npm's tendency to try to request all your dependencies simultaneously upset some network hardware (particular, consumer grade routers & proxies of all sorts). One of the reasons that we're planning to write our own npm specific version of request is to be able to more easily control this sort of thing.

But fortunately, you don't have to wait for that. [@misterbyrne](https://github.com/misterbyrne) took a look at our existing code and realized it could be added painlessly TODAY. The new default maximum is 50, instead of Infinity. If you're having network issues you can try setting that value down to something lower (if you do, please let us know... the default is subject to tuning).

WINDOWS GIT BASH

We think it's pretty keen too, we were making it really hard to actually upgrade if you were using it. NO MORE!

DOCUMENTATION IMPROVEMENTS

DEPENDENCY UPDATES

v3.7.5 (2016-02-22):

A quick fixup release because when I updated glob, I missed the subdep copies of itself that it installed deeper in the tree. =/

This only effected people trying to update to 3.7.4 from npm@2 or npm@1. Updates from npm@3 worked fine (as it fixes up the missing subdeps during installation).

OH MY GLOB

v3.7.4 (2016-02-18):

I'm ([@iarna](https://github.com/iarna)) back from vacation in the frozen wastes of Maine! This release sees a couple of bug fixes, some documentation updates, a bunch of dependency updates and improvements to our test suite.

FIXES FOR update, FIXES FOR ls

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

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 isn't ordinarily an issue with npm@3 as it produces mostly flat trees, but you may be surprised to learn that npm's own distribution isn't flat, due to needing to be compatible with npm@1.2, which ships with node@0.8!

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.

INTERNAL TEST IMPROVEMENTS

The npm core 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.

DEPENDENCY UPDATES

v3.7.3 (2016-02-11):

Hey all! We've got a pretty small release this week -- just documentation updates and a couple of dependencies. This release also includes a particular dependency upgrade that makes it so we're exclusively using the latest version of graceful-fs, which'll make it so things keep working with future Node.js releases.

A certain internal Node.js API was deprecated and slated for future removal from Node Core. This API was critical for versions of graceful-fs@<4, before a different approach was used to achieve similar ends. By upgrading this library, and making sure all our dependencies are also updated, we've ensured npm will continue to work once the API is finally removed. Older versions of npm, on the other hand, will simply not work on future versions of Node.js.

DEPENDENCY UPGRADES

EVERYONE GETTING SOCKS LIKE IT'S OPRAH'S SHOW

v3.7.2 (2016-02-04):

This week, the CLI team has been busy working on rewriting tests to support getting coverage reports going and running all of our tests on Windows. Meanwhile, we've got a bunch of dependency updates and one or two other things.

TESTS WENT INTO HIDING

Last week we took a patch from [@substack](https://github.com/substack) to stop the installer from reordering arrays in an installed module's package.json... but somehow I dropped the test when I was rebasing.

DOCUMENTATION FIXES

DEPENDENCY UPDATES

lodash saw updates across most of its modules this week with browser campatibility fixes that don't really impact us.

v3.7.1 (2016-02-01):

Super quick Monday patch on last week's release.

If you ever wondered why we release things to the npm@next tag for a week before promoting them to npm@latest, this is it!

RELEASE TRAIN VINDICATED (again)

v3.7.0 (2016-01-29):

Hi all! This week brings us some important performance improvements, support for git submodules(!) and a bunch of bug fixes.

PERFORMANCE

gauge, the module responsible for drawing npm's progress bars, had an embarrassing bug in its debounce implementation that resulted in it, on many systems, actually being slower than if it hadn't been debouncing. This was due to it destroying and then creating a timer object any time it got an update while waiting on its minimum update period to elapse. This only was a measurable slowdown when sending thousands of updates a second, but unfortunately parts of npm's logging do exactly that. This has been patched to eliminate that churn, and our testing shows the progress bar as being eliminated as a source of slow down.

Meanwhile, are-we-there-yet is the module that tracks just how complete our big asynchronous install process is. [@STRML](https://github.com/STRML) spent some time auditing its source and made a few smaller performance improvements to it. Most impactful was eliminating a bizarre bit of code that was both binding to AND closing over the current object. I don't have any explanation for how that crept in. =D

We were also using lodash's cloneDeep on package.json data which is definitely overkill, seeing as package.json data has all the restrictions of being json. The fix for this is just swapping that out for something that does a pair of JSON.stringify/JSON.parse, which is distinctly more speedy.

NEW FEATURE: GIT SUBMODULE SUPPORT

Long, long requested– the referenced issue is from 2011– we're finally getting rudimentary git submodule support.

ROBUSTNESS

BUG FIXES

DOCS IMPROVEMENTS

DEPENDENCY UPDATES

v3.6.0 (2016-01-20):

Hi all! This is a bigger release, in part 'cause we didn't have one last week. The most important thing you need to know is that when npm@3.6.0 replaces npm@3.5.4 as next, npm@3.5.4 WILL NOT be moved on to latest. This is due to a packaging error that tickles bugs in some earlier releases and makes upgrades to it from those versions break the install.

NEW FEATURES‼

3.5.4 WAS NOT SO GREAT

The npm@3.5.4 package was missing some dependencies. Specifically, glob and has-unicode had major release updates which meant that subdeps that relied on older major versions couldn't use the npm supplied versions any more, and so they needed their own copies.

This went undetected because the actions necessary to run the tests (which check for this sort of thing) resolved the missing modules.

Further, it didn't have symptoms when upgrading from most versions of npm. Unfortunately, some versions had bugs that were tickled by this and resulted in broken upgrades, most notably, npm@3.3.12, the version that's been in Node.js 5.

WHEN MISSING PATHS ARE OK

This showed up as an error where you would see something like: npm warn gentlyRm not removing /path/to/thing as it wasn't installed by /path/to/other/thing But it totally was installed by it. ([@iarna](https://github.com/iarna))

BETTER NODE PRE-RELEASE SUPPORT

Historically, if you used a pre-release version of Node.js, you would get dozens and dozens of warnings when EVERY engine check failed across all of your modules, because >= 0.10.0 doesn't match prereleases.

You might find this stream of redundent warnings undesirable. I do.

We've moved this into a SINGLE warning you'll get about using a pre-release version of Node.js and now suppress those other warnings.

BUG FIXES

DOC CHANGES

DEPENDENCY UPDATES

v3.5.4 (2016-01-07):

I hope you all had fantastic winter holidays, if it's winter where you are and if there are holidays‼ We went a few weeks without releases because staff was taking time away from work here and there. A new year has come and we're back now, and refreshed and ready to dig in!

This week brings us a bunch of documentation improvements and some module updates. The core team's focus continues to be on improving tests, particularly with Windows, so there's not too much to call out here.

DOCUMENTATION IMPROVEMENTS

A FEW MODULE UPDATES

FIX NPM'S TESTS ON 0.8

This doesn't impact you as a user of npm, and ordinarily that means we wouldn't call it out here, but if you've ever wanted to contribute, having that green travis badge makes it a lot easier to do so with confidence!

0.8 http streams have a bug, where if they're paused with data in their buffers when the socket closes, they call end before emptying those buffers, which results in the entire pipeline ending and thus the point that applied backpressure never being able to trigger a resume.

We work around this by piping into a pass through stream that has unlimited buffering. The pass through stream is from readable-stream and is thus a current streams3 implementation that is free of these bugs even on 0.8. ([@iarna](https://github.com/iarna))

v3.5.3 (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

NOW PAINT IN SOME NICE DOCS CHANGES

LAND YOUR DEPENDENCY UPGRADES IN PAIRS SO EVERYONE HAS A FRIEND

v3.5.2 (2015-12-03):

Weeeelcome to another npm release! The short version is that we fixed some ENOENT and some modules that resulted in modules going missing. We also eliminated the use of MD5 in our code base to help folks using Node.js in FIPS mode. And we fixed a bad URL in our license file.

FIX URL IN LICENSE

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

ENOENT? MORE LIKE ENOMOREBUGS

The headliner this week was uncovered by the fixes to bundled dependency handling over the past few releases. What had been a frustratingly intermittent and hard to reproduce bug became something that happened every time in Travis. This fixes another whole bunch of errors where you would, while running an install have it crash with an ENOENT on rename, or the install would finish but some modules would be mysteriously missing and you'd have to install a second time.

What's going on was a bit involved, so bear with me:

npm@3 generates a list of actions to take against the tree on disk. With the exception of lifecycle scripts, it expects these all to be able to act independently without interfering with each other.

This means, for instance, that one should be able to upgrade b in a→b→c without having npm reinstall c.

That works fine by the way.

But it also means that the move action should be able to move b in a→b→c@1.0.1 to a→d→b→c@1.0.2 without moving or removing c@1.0.1 and while leaving c@1.0.2 in place if it was already installed.

That is, the move action moves an individual node, replacing itself with an empty spot if it had children. This is not, as it might first appear, something where you move an entire branch to another location on the tree.

When moving b we already took care to leave c@1.0.1 in place so that other moves (or removes) could handle it, but we were stomping on the destination and so c@1.0.2 was being removed.

There was also a bug with remove where it was pruning the entire tree at the remove point, prior to running moves and adds.

This was fine most of the time, but if we were moving one of the deps out from inside it, kaboom.

After all that, we shouldn't be upgrading the add of a bundled package to a move. Moves save us from having to extract the package, but with a bundled dependency it's included in another package already so that doesn't gain us anything.

While I was in there, I also took some time to improve diagnostics to make this sort of thing easier to track down in the future:

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

v3.5.1 (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 npm@3.4.1, which is where the split between the CLI's code and the terms of use for the registry was first made more clear.

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](https://github.com/jakub-g) did us all a favor and relaxed the check for npm completion to support MINGW bash. Thanks, Jakub!

THE ONGOING SAGA OF BUNDLED DEPENDENCIES

npm@3.5.0 fixed up a serious issue with how npm@3.4.1 (and potentially npm@3.4.0 and npm@3.3.12) handled the case in which dependencies bundled into a package tarball are handled improperly when one or more of their own dependencies are older than what's latest on the registry. Unfortunately, in fixing that (quite severe) regression (see npm@3.5.0's release notes' for details), we introduced a new (small, and fortunately cosmetic) issue where npm superfluously warns you about bundled dependencies being stale. We have now fixed that, and hope that we haven't introduced any other regressions in the process. :D

MAKE NODE-GYP A LITTLE BLUER

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.

v3.5.0 (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](https://github.com/zkat)'s hard work.

During our final testing before the release, our ace support team member [@snopeks](https://github.com/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.

NON-OPTIONAL INSTALLS, DEFINITELY NON-OPTIONAL

We do this by walking up through all of our ancestors until we either hit an optional dependency or the top of the tree. If we hit the top, we know to give the error.

If you installed a module by hand but didn't --save it, your module won't have the top of the tree as an anscestor and so this code was failing to abort the install with an error

This updates the logic so that hitting the top OR a module that was requested by the user will trigger the error message. ([@iarna](https://github.com/iarna))

To that end, we've moved warnings about failed optional deps to the show after your install completes. ([@iarna](https://github.com/iarna))

OVERRIDING BUNDLING

This fixes that. It also reworks our bundled module support to be much closer to being in line with how we handle non-bundled modules and we're hopeful this will reduce any future errors around them. The new structure is hopefully much easier to reason about anyway. ([@iarna](https://github.com/iarna))

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:

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.

0.8 + npm <1.4 COMPATIBLE? SURE WHY NOT

Hey, you found the feature we added!

Second, --global-style which will install modules in your node_modules folder with the same layout as global modules. Only your direct dependencies will show in node_modules and everything they depend on will be flattened in their node_modules folders. This obviously will elminate some deduping. ([@iarna](https://github.com/iarna))

TYPOS IN THE LICENSE, OH MY

v3.4.1 (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 (preferrably 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. Worse, if all your versions were prerelease versions it would just refuse to install anything. (We fixed that in npm@3.2.2 with e4a38080.)

BUGS

LICENSE CLARIFICATION

CLOSER TO GREEN TRAVIS

v3.4.0 (2015-11-05):

A NEW FEATURE

This was a group effort, with [@isaacs](https://github.com/isaacs) dropping the implementation in back in August. Then, a few days ago, [@ashleygwilliams](https://github.com/ashleygwilliams) wrote up docs and just today [@othiym23](https://github.com/othiym23) wrote a test.

It's a handy shortcut to update a dependency and then make sure tests still pass.

This new command:

npm install-test x

is the equivalent of running:

npm install x && npm test

BUG FIXES VIA DEPENDENCY UPDATES

DOCUMENTATION FIXES

DEPENDENCY UPDATES FOR THEIR OWN SAKE

v3.3.12 (2015-11-02):

Hi, a little hot-fix release for a bug introduced in 3.3.11. The ENOENT fix last week (f0e2088) broke upgrades of modules that have bundled dependencies (like npm, augh!)

v3.3.11 (2015-10-29):

This is a dependency update week, so that means no PRs from our lovely users. Look for those next week. As it happens, the dependencies updated were just devdeps, so nothing for you all to worry about.

But the bug fixes, oh geez, I tracked down some really long standing stuff this week!! The headliner is those intermittent ENOENT errors that no one could reproduce consistently? I think they're nailed! But also pretty important, the bug where hapi would install w/ a dep missing? Squashed!

EEEEEEENOENT

PARTIAL SHRINKWRAPS, NO LONGER A BAD DAY

fun-time ├── need-fun@1 └── need-time └── need-fun@2

Now, the fun-time author also distributes a shrinkwrap, but it only includes the need-fun@1 in it.

Resolving dependencies would look something like this:

  1. Require need-fun@1: Use version from shrinkwrap (ignoring version)
  2. Require need-time: User version in package.json
    1. Require need-fun@2: Use version from shrinkwrap, which oh hey, is already installed at the top level, so no further action is needed.

Which results in this tree:

fun-time ├── need-fun@1 └── need-time

We're ignoring the version check on things specified in the shrinkwrap so that you can override the version that will be installed. This is because you may want to use a different version than is specified by your dependencies' dependencies' package.json files.

To fix this, we now only allow overrides of a dependency version when that dependency is a child (in the tree) of the thing that requires it. This means that when we're looking for need-fun@2 we'll see need-fun@1 and reject it because, although it's from a shrinkwrap, it's parent is fun-time and the package doing the requiring is need-time.

([@iarna](https://github.com/iarna))

STRING package.bin AND NON-NPMJS REGISTRIES

v3.3.10 (2015-10-22):

Hey you all! Welcome to a busy bug fix and PR week. We've got changes to how npm install replaces dependencies during updates, improvements to shrinkwrap behavior, and all sorts of doc updates.

In other news, npm@3 landed in node master in preparation for node@5 with 41923c0.

UPDATED DEPS NOW MAKE MORE SENSE

SHRINKWRAP + DEV DEPS NOW RESPECTED

FANTASTIC DOCUMENTATION UPDATES

NEW STANDARD HAS ALWAYS BEEN STANDARD

v3.3.9 (2015-10-15):

This week sees a few small changes ready to land:

TRAVIS NODE 0.8 BUILDS REJOICE

SMALL ERROR MESSAGE IMPROVEMENT

DEPENDENCY UPDATES

v3.3.8 (2015-10-12):

This is a small update release, we're reverting 22a3af0 from last week's release, as it is resulting in crashes. We'll revisit this PR during this week.

v3.3.7 (2015-10-08):

So, as Kat mentioned in last week's 2.x release, we're now swapping weeks between accepting PRs and doing dependency updates, in an effort to keep release management work from taking over our lives. This week is a PR week, so we've got a bunch of goodies for you.

Relatedly, this week means 3.3.6 is now latest and it is WAY faster than previous 3.x releases. Give it or this a look!

OPTIONAL DEPS, MORE OPTIONAL

BAD NAME, NO CRASH

MISCELLANEOUS BUG FIXES

DOCUMENTATION UPDATES

v3.3.6 (2015-09-30):

I have the most exciting news for you this week. YOU HAVE NO IDEA. Well, ok, maybe you do if you follow my twitter.

Performance just got 5 bazillion times better (under some circumstances, ymmv, etc). So– my test scenario is our very own website. In npm@2, on my macbook running npm ls takes about 5 seconds. Personally it's more than I'd like, but it's entire workable. In npm@3 it has been taking 50 seconds, which is appalling. But after doing some work on Monday isolating the performance issues I've been able to reduce npm@3's run time back down to 5 seconds.

Other scenarios were even worse, there was one that until now in npm@3 that took almost 6 minutes, and has been reduced to 14 seconds.

In other news, look for us this Friday and Saturday at the amazing Open Source and Feelings conference, where something like a third of the company will be attending.

And finally a dependency update

And some subdep updates

v3.3.5 (2015-09-24):

Some of you all may not be aware, but npm is ALSO a company. I tell you this 'cause npm-the-company had an all-staff get together this week, flying in our remote folks from around the world. That was great, but it also basically eliminated normal work on Monday and Tuesday.

Still, we've got a couple of really important bug fixes this week. Plus a lil bit from the now LTS 2.x branch.

ATTENTION WINDOWS USERS

If you previously updated to npm 3 and you try to update again, you may get an error messaging telling you that npm won't install npm into itself. Until you are at 3.3.5 or greater, you can get around this with npm install -f -g npm.

STACK OVERFLOWS ON PUBLISH

I've patched this by keeping track of your metadata by closing over the variables in question instead, and I've further restricted gathering and tracking the metadata to times when it's actually needed. (Which is only if you need bundled modules.) ([@iarna](https://github.com/iarna))

LESS CRASHY ERROR MESSAGES ON BAD PACKAGES

ONE DEPENDENCY UPDATE

AND ONE SUBDEPENDENCY

v3.3.4 (2015-09-17):

This is a relatively quiet release, bringing a few bug fixes and some module updates, plus via the 2.14.5 release some forward compatibility fixes with versions of Node that aren't yet released.

NO BETA NOTICE THIS TIME!!

But, EXCITING NEWS FRIENDS, this week marks the exit of npm@3 from beta. This means that the week of this release, v3.3.3 will become latest and this version (v3.3.4) will become next!!

CRUFT FOR THE CRUFT GODS

What I call "cruft", by which I mean, files sitting around in your node_modules folder, will no longer produce warnings in npm ls nor during npm install. This brings npm@3's behavior in line with npm@2.

BETTER ERROR MESSAGE

MODULE UPDATES

SUB DEP MODULE UPDATES

v3.3.3 (2015-09-10):

This short week brought us brings us a few small bug fixes, a doc change and a whole lotta dependency updates.

Plus, as usual, this includes a forward port of everything in npm@2.14.4.

BETA BUT NOT FOREVER

THIS IS BETA SOFTWARE. npm@3 will remain in beta until we're confident that it's stable and have assessed the effect of the breaking changes on the community. During that time we will still be doing npm@2 releases, with npm@2 tagged as latest and next. We'll also be publishing new releases of npm@3 as npm@v3.x-next and npm@v3.x-latest alongside those versions until we're ready to switch everyone over to npm@3. We need your help to find and fix its remaining bugs. It's a significant rewrite, so we are sure there still significant bugs remaining. So do us a solid and deploy it in non-critical CI environments and for day-to-day use, but maybe don't use it for production maintenance or frontline continuous deployment just yet.

REMOVE INSTALLED BINARIES ON WINDOWS

So waaaay back at the start of August, I fixed a bug with #9198. That fix made it so that if you had two modules installed that both installed the same binary (eg gulp & gulp-cli), that removing one wouldn't remove the binary if it was owned by the other.

It did this by doing some hocus-pocus that, turns out, was Unix-specific, so on Windows it just threw up its hands and stopped removing installed binaries at all. Not great.

So today we're fixing that– it let us maintain the same safety that we added in #9198, but ALSO works with Windows.

API DOCUMENTATION HAS BEEN SACRIFICED THE API GOD

The documentation of the internal APIs of npm is going away, because it would lead people into thinking they should integrate with npm by using it. Please don't do that! In the future, we'd like to give you a suite of stand alone modules that provide better, more stand alone APIs for your applications to build on. But for now, call the npm binary with process.exec or process.spawn instead.

We never meant to have this be a restriction in the first place and it was only just discovered with the recent node 4.0.0 release candidate.

graceful-fs update

We're updating all of npm's deps to use the most recent graceful-fs. This turns out to be important for future not yet released versions of node, because older versions monkey-patch fs in ways that will break in the future. Plus it ALSO makes use of process.binding which is an internal API that npm definitely shouldn't have been using. We're not done yet, but this is the bulk of them.

DEPENDENCY UPDATES

THE DEPENDENCIES OF OUR DEPENDENCIES ARE OUR DEPENDENCIES UPDATES

v3.3.2 (2015-09-04):

PLEASE HOLD FOR THE NEXT AVAILABLE MAINTAINER

This is a tiny little maintenance release, both to update dependencies and to keep npm@3 up to date with changes made to npm@2. [@othiym23](https://github.com/othiym23) is putting out this release (again) as his esteemed colleague [@iarna](https://github.com/iarna) finishes relocating herself, her family, and her sizable anime collection all the way across North America. It contains all the goodies in npm@2.14.3 and one other dependency update.

BETA WARNINGS FOR FUN AND PROFIT

THIS IS BETA SOFTWARE. npm@3 will remain in beta until we're confident that it's stable and have assessed the effect of the breaking changes on the community. During that time we will still be doing npm@2 releases, with npm@2 tagged as latest and next. We'll also be publishing new releases of npm@3 as npm@v3.x-next and npm@v3.x-latest alongside those versions until we're ready to switch everyone over to npm@3. We need your help to find and fix its remaining bugs. It's a significant rewrite, so we are sure there still significant bugs remaining. So do us a solid and deploy it in non-critical CI environments and for day-to-day use, but maybe don't use it for production maintenance or frontline continuous deployment just yet.

That said, it's getting there! It will be leaving beta very soon!

ONE OTHER DEPENDENCY UPDATE

v3.3.1 (2015-08-27):

Hi all, this npm@3 update brings you another round of bug fixes. The headliner here is that npm update works again. We're running down the clock on blocker 3.x issues! Shortly after that hits zero we'll be promoting 3.x to latest!!

And of course, we have changes that were brought forward from 2.x. Check out the release notes for 2.14.1 and 2.14.2.

BETA WARNINGS FOR FUN AND PROFIT

THIS IS BETA SOFTWARE. npm@3 will remain in beta until we're confident that it's stable and have assessed the effect of the breaking changes on the community. During that time we will still be doing npm@2 releases, with npm@2 tagged as latest and next. We'll also be publishing new releases of npm@3 as npm@v3.x-next and npm@v3.x-latest alongside those versions until we're ready to switch everyone over to npm@3. We need your help to find and fix its remaining bugs. It's a significant rewrite, so we are sure there still significant bugs remaining. So do us a solid and deploy it in non-critical CI environments and for day-to-day use, but maybe don't use it for production maintenance or frontline continuous deployment just yet.

NPM UPDATE, NOW AGAIN YOUR FRIEND

MORE VERBOSING FOR YOUR VERBOSE LIFECYCLES

AND SOME OTHER BUG FIXES…

SOME DEP UPDATES

SOME DEPS OF DEPS UPDATES

v3.3.0 (2015-08-13):

This is a pretty EXCITING week. But I may be a little excitable– or possibly sleep deprived, it's sometimes hard to tell them apart. =D So Kat really went the extra mile this week and got the client side support for teams and orgs out in this week's 2.x release. You can't use that just yet, 'cause we have to turn on some server side stuff too, but this way it'll be there for you all the moment we do! Check out the details over in the 2.14.0 release notes!

But we over here in 3.x ALSO got a new feature this week, check out the new --only and --also flags for better control over when dev and production dependencies are used by various npm commands.

That, and some important bug fixes round out this week. Enjoy everyone!

NEVER SHALL NOT BETA THE BETA

THIS IS BETA SOFTWARE. EXCITING NEW BETA WARNING!!! Ok, I fibbed, EXACTLY THE SAME BETA WARNINGS: npm@3 will remain in beta until we're confident that it's stable and have assessed the effect of the breaking changes on the community. During that time we will still be doing npm@2 releases, with npm@2 tagged as latest and next. We'll also be publishing new releases of npm@3 as npm@v3.x-next and npm@v3.x-latest alongside those versions until we're ready to switch everyone over to npm@3. We need your help to find and fix its remaining bugs. It's a significant rewrite, so we are sure there still significant bugs remaining. So do us a solid and deploy it in non-critical CI environments and for day-to-day use, but maybe don't use it for production maintenance or frontline continuous deployment just yet.

ONLY ALSO DEV

Hey we've got a SUPER cool new feature for you all, thanks to the fantastic work of [@davglass](https://github.com/davglass) and [@bengl](https://github.com/bengl) we have --only=prod, --only=dev, --also=prod and --also=dev options. These apply in various ways to: npm install, npm ls, npm outdated and npm update.

So for instance:

npm install --only=dev

Only installs dev dependencies. By contrast:

npm install --only=prod

Will only install prod dependencies and is very similar to --production but differs in that it doesn't set the environment variables that --production does.

The related new flag, --also is most useful with things like:

npm shrinkwrap --also=dev

As shrinkwraps don't include dev deps by default. This replaces passing in --dev in that scenario.

And that leads into the fact that this deprecates --dev as its semantics across commands were inconsistent and confusing.

DON'T TOUCH! THAT'S NOT YOUR BIN

THERE'S AN END IN SIGHT

OOPS DIDN'T MEAN TO FIX THAT

Well, not just yet. This was scheduled for next week, but it snuck into 2.x this week.

v3.2.2 (2015-08-08):

Lot's of lovely bug fixes for npm@3. I'm also suuuuper excited that I think we have a handle on stack explosions that effect a small portion of our users. We also have some tantalizing clues as to where some low hanging fruit may be for performance issues.

And of course, in addition to the npm@3 specific bug fixes, there are some great one's coming in from npm@2! [@othiym23](https://github.com/othiym23) put together that release this week– check out its release notes for the deets.

AS ALWAYS STILL BETA

THIS IS BETA SOFTWARE. Just like the airline safety announcements, we're not taking this plane off till we finish telling you: npm@3 will remain in beta until we're confident that it's stable and have assessed the effect of the breaking changes on the community. During that time we will still be doing npm@2 releases, with npm@2 tagged as latest and next. We'll also be publishing new releases of npm@3 as npm@v3.x-next and npm@v3.x-latest alongside those versions until we're ready to switch everyone over to npm@3. We need your help to find and fix its remaining bugs. It's a significant rewrite, so we are sure there still significant bugs remaining. So do us a solid and deploy it in non-critical CI environments and for day-to-day use, but maybe don't use it for production maintenance or frontline continuous deployment just yet.

BUG FIXES

DEP VERSION BUMPS

v3.2.1 (2015-07-31):

AN EXTRA QUIET RELEASE

A bunch of stuff got deferred for various reasons, which just means more branches to land next week!

Don't forget to check out Kat's 2.x release for other quiet goodies.

AS ALWAYS STILL BETA

THIS IS BETA SOFTWARE. Yes, we're still reminding you of this. No, you can't be excused. npm@3 will remain in beta until we're confident that it's stable and have assessed the effect of the breaking changes on the community. During that time we will still be doing npm@2 releases, with npm@2 tagged as latest and next. We'll also be publishing new releases of npm@3 as npm@v3.x-next and npm@v3.x-latest alongside those versions until we're ready to switch everyone over to npm@3. We need your help to find and fix its remaining bugs. It's a significant rewrite, so we are sure there still significant bugs remaining. So do us a solid and deploy it in non-critical CI environments and for day-to-day use, but maybe don't use it for production maintenance or frontline continuous deployment just yet.

MAKING OUR TESTS TEST THE THING THEY TEST

MY PACKAGE.JSON WAS ALREADY IN THE RIGHT ORDER

DEV DEP UPDATE

v3.2.0 (2015-07-24):

MORE CONFIG, BETTER WINDOWS AND A BUG FIX

This is a smallish release with a new config option and some bug fixes. And lots of module updates.

BETA BETAS ON

THIS IS BETA SOFTWARE. Yes, we're still reminding you of this. No, you can't be excused. npm@3 will remain in beta until we're confident that it's stable and have assessed the effect of the breaking changes on the community. During that time we will still be doing npm@2 releases, with npm@2 tagged as latest and next. We'll also be publishing new releases of npm@3 as npm@v3.x-next and npm@v3.x-latest alongside those versions until we're ready to switch everyone over to npm@3. We need your help to find and fix its remaining bugs. It's a significant rewrite, so we are sure there still significant bugs remaining. So do us a solid and deploy it in non-critical CI environments and for day-to-day use, but maybe don't use it for production maintenance or frontline continuous deployment just yet.

NEW CONFIGS, LESS PROGRESS

AND BUG FIXES

AND A WHOLE BUNCH OF SUBDEP VERSIONS

These are all development dependencies and semver-compatible subdep upgrades, so they should not have visible impact on users.

MERGED FORWARD

v3.1.3 (2015-07-17):

Rebecca: So Kat, I hear this week's other release uses a dialog between us to explain what changed?

Kat: Well, you could say that…

Rebecca: I would! This week I fixed more npm@3 bugs!

Kat: That sounds familiar.

Rebecca: Eheheheh, well, before we look at those, a word from our sponsor…

BETA IS AS BETA DOES

THIS IS BETA SOFTWARE. Yes, we're still reminding you of this. No, you can't be excused. npm@3 will remain in beta until we're confident that it's stable and have assessed the effect of the breaking changes on the community. During that time we will still be doing npm@2 releases, with npm@2 tagged as latest and next. We'll also be publishing new releases of npm@3 as npm@v3.x-next and npm@v3.x-latest alongside those versions until we're ready to switch everyone over to npm@3. We need your help to find and fix its remaining bugs. It's a significant rewrite, so we are sure there still significant bugs remaining. So do us a solid and deploy it in non-critical CI environments and for day-to-day use, but maybe don't use it for production maintenance or frontline continuous deployment just yet.

Rebecca: Ok, enough of the dialoguing, that's Kat's schtick. But do remember kids, betas hide in dark hallways waiting to break your stuff, stuff like…

WE'LL TRY NOT TO CRACK YOUR WINDOWS

ZOOM ZOOM, DEP UPDATES

MERGED FORWARD

v3.1.2

SO VERY BETA RELEASE

So, v3.1.1 managed to actually break installing local modules. And then immediately after I drove to an island for the weekend. 😁 So let's get this fixed outside the usual release train!

Fortunately it didn't break installing global modules and so you could swap it out for another version at least.

DISCLAIMER MEANS WHAT IT SAYS

THIS IS BETA SOFTWARE. Yes, we're still reminding you of this. No, you can't be excused. npm@3 will remain in beta until we're confident that it's stable and have assessed the effect of the breaking changes on the community. During that time we will still be doing npm@2 releases, with npm@2 tagged as latest and next. We'll also be publishing new releases of npm@3 as npm@v3.x-next and npm@v3.x-latest alongside those versions until we're ready to switch everyone over to npm@3. We need your help to find and fix its remaining bugs. It's a significant rewrite, so we are sure there still significant bugs remaining. So do us a solid and deploy it in non-critical CI environments and for day-to-day use, but maybe don't use it for production maintenance or frontline continuous deployment just yet.

THIS IS IT, THE REASON

v3.1.1

RED EYE RELEASE

Rebecca's up too late writing tests, so you can have npm@3 bug fixes! Lots of great new issues from you all! ❤️️ Keep it up!

YUP STILL BETA, PLEASE PAY ATTENTION

THIS IS BETA SOFTWARE. Yes, we're still reminding you of this. No, you can't be excused. npm@3 will remain in beta until we're confident that it's stable and have assessed the effect of the breaking changes on the community. During that time we will still be doing npm@2 releases, with npm@2 tagged as latest and next. We'll also be publishing new releases of npm@3 as npm@v3.x-next and npm@v3.x-latest alongside those versions until we're ready to switch everyone over to npm@3. We need your help to find and fix its remaining bugs. It's a significant rewrite, so we are sure there still significant bugs remaining. So do us a solid and deploy it in non-critical CI environments and for day-to-day use, but maybe don't use it for production maintenance or frontline continuous deployment just yet.

BOOGS

MERGED FORWARD

v3.1.0 (2015-07-02):

This has been a brief week of bug fixes, plus some fun stuff merged forward from this weeks 2.x release. See the 2.13.0 release notes for details on that.

You all have been AWESOME with all the npm@3 bug reports! Thank you and keep up the great work!

NEW PLACE, SAME CODE

Remember how last week we said npm@3 would go to 3.0-next and latest tags? Yeaaah, no, please use npm@v3.x-next and npm@v3.x-latest going forward.

I dunno why we said "suuure, we'll never do a feature release till we're out of beta" when we're still forward porting npm@2.x features. ¯\_(ツ)_/¯

If you do accidentally use the old tag names, I'll be maintaining them for a few releases, but they won't be around forever.

YUP STILL BETA, PLEASE PAY ATTENTION

THIS IS BETA SOFTWARE. npm@3 will remain in beta until we're confident that it's stable and have assessed the effect of the breaking changes on the community. During that time we will still be doing npm@2 releases, with npm@2 tagged as latest and next. We'll also be publishing new releases of npm@3 as npm@v3.x-next and npm@v3.x-latest alongside those versions until we're ready to switch everyone over to npm@3. We need your help to find and fix its remaining bugs. It's a significant rewrite, so we are sure there still significant bugs remaining. So do us a solid and deploy it in non-critical CI environments and for day-to-day use, but maybe don't use it for production maintenance or frontline continuous deployment just yet.

BUGS ON THE WINDOWS

SO MANY BUGS SQUASHED, JUST CALL US RAID

NEW VERSION

Just the one. Others came in via the 2.x release. Do check out its changelog, immediately following this message.

v3.0.0 (2015-06-25):

Wow, it's finally here! This has been a long time coming. We are all delighted and proud to be getting this out into the world, and are looking forward to working with the npm user community to get it production-ready as quickly as possible.

npm@3 constitutes a nearly complete rewrite of npm's installer to be easier to maintain, and to bring a bunch of valuable new features and design improvements to you all.

[@othiym23](https://github.com/othiym23) and [@isaacs](https://github.com/isaacs) have been talking about the changes in this release for well over a year, and it's been the primary focus of [@iarna](https://github.com/iarna) since she joined the team.

Given that this is a near-total rewrite, all changes listed here are [@iarna](https://github.com/iarna)'s work unless otherwise specified.

NO, REALLY, READ THIS PARAGRAPH. IT'S THE IMPORTANT ONE.

THIS IS BETA SOFTWARE. npm@3 will remain in beta until we're confident that it's stable and have assessed the effect of the breaking changes on the community. During that time we will still be doing npm@2 releases, with npm@2 tagged as latest and next. We'll also be publishing new releases of npm@3 as npm@3.0-next and npm@3.0-latest alongside those versions until we're ready to switch everyone over to npm@3. We need your help to find and fix its remaining bugs. It's a significant rewrite, so we are sure there still significant bugs remaining. So do us a solid and deploy it in non-critical CI environments and for day-to-day use, but maybe don't use it for production maintenance or frontline continuous deployment just yet.

BREAKING CHANGES

peerDependencies

grunt, gulp, and broccoli plugin maintainers take note! You will be affected by this change!

This shifts the responsibility for fulfilling peer dependencies from library / framework / plugin maintainers to application authors, and is intended to get users out of the dependency hell caused by conflicting peerDependency constraints. npm's job is to keep you out of dependency hell, not put you in it.

engineStrict

As with the peer dependencies change, this is about shifting control from module authors to application authors. It turns out engineStrict was very difficult to understand even harder to use correctly, and more often than not just made modules using it difficult to deploy.

npm view

KNOWN BUGS

Again, this is a BETA RELEASE, so not everything is working just yet. Here are the issues that we already know about. If you run into something that isn't on this list, let us know!

NEW FEATURES

The multi-stage installer!

But now it executes each of those steps at the same time for all packages, waiting for all of one stage to complete before moving on. This eliminates many race conditions and makes the code easier to reason about.

This fixes, for instance:

Install: it looks different!

You'll now get a tree much like the one produced by npm ls that highlights in orange the packages that were installed. Similarly, any removed packages will have their names prefixed by a -.

Also, npm outdated used to include the name of the module in the Location field:

Package                Current  Wanted  Latest  Location
deep-equal             MISSING   1.0.0   1.0.0  deep-equal
glob                     4.5.3   4.5.3  5.0.10  rimraf > glob

Now it shows the module that required it as the final point in the Location field:

Package                Current  Wanted  Latest  Location
deep-equal             MISSING   1.0.0   1.0.0  npm
glob                     4.5.3   4.5.3  5.0.10  npm > rimraf

Previously the Location field was telling you where the module was on disk. Now it tells you what requires the module. When more than one thing requires the module you'll see it listed once for each thing requiring it.

Install: it works different!
Flat, flat, flat!

Your dependencies will now be installed maximally flat. Insofar as is possible, all of your dependencies, and their dependencies, and THEIR dependencies will be installed in your project's node_modules folder with no nesting. You'll only see modules nested underneath one another when two (or more) modules have conflicting dependencies.

This has some implications for the behavior of other commands:

And bundling of dependencies when packing or publishing changes too:

As a demonstration of our confidence in our own work, npm's own dependencies are now flattened, deduped, and bundled in the npm@3 style. This means that npm@3 can't be packed or published by npm@2, which is something to be aware of if you're hacking on npm.

Shrinkwraps: they are a-changin'!

First of all, they should be idempotent now (#5779). No more differences because the first time you install (without npm-shrinkwrap.json) and the second time (with npm-shrinkwrap.json).

And finally, enjoy this shrinkwrap bug fix:

The Age of Progress (Bars)!

TINY JEWELS

The bottom is where we usually hide the less interesting bits of each release, but each of these are small but incredibly useful bits of this release, and very much worth checking out:

ZARRO BOOGS