v3.10.3

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.

BUM SYMLINKS BURN NO MORE

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 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.)

• ca92ac4 npm/read-package-tree#6 read-package-tree@5.1.5: Make bad symlinks be non-fatal errors when reading the tree off disk. (@watilde)

BETTER UNICODE DETECTION

• 6c3f7f0 has-unicode@2.0.1: Fix unicode detection on a number of Linux distributions. (@Darkhogg) (@gagern)

DOCUMENTATION FIXES

• b9243ee #13127 Remove extra backtick from npm ls documentation. (@shvaikalesh)
• e05c0c2 iarna/has-unicode#3 iarna/has-unicode#4 #13084 Correct changelog entry for shrinkwrap lifecycle order. (@SimenB)
• 823994f #13080 Describe using npm pack to see a dry run of publication results in the npm publish documentation. (@laughinghan)

DEPENDENCY UPDATES

• e44d2db aproba@1.0.4: Documentation updates and minor refactoring. (@iarna)

v3.10.2

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.

• fbefb86 7779e9f #13105 Disable progress bar in adduser and init.
• 6a33b2c #13115 Ensure that errors reading the package tree for outdated does not result in crashs. (@iarna)

v3.10.1

v3.10.1 (2016-06-17):

There are two very important bug fixes and one long-awaited (and signifcant!) 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 ~npm@3.8.7 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 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.

• 8802f6c #5082 fstream@1.0.10: Ensure that entries are collected after a paused stream resumes. (@rvagg)
• c189723 #5082 Remove the warning introduced in npm@3.10.0, because it should no longer be necessary. (@othiym23)

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.

• 1b6ceca #13088 Partially restore npm's own version of the fstream-npm function applyIgnores to ensure that the dependencies of bundledDependencies are included in published packages. (@iarna)

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 maintenace 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.

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

v2.15.8

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 ~npm@3.8.7 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 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.

• 2c49265 #5082 fstream@1.0.10: Ensure that entries are collected after a paused stream resumes. (@rvagg)
• 92e4344 #5082 Remove the warning introduced in npm@3.10.0, because it should no longer be necessary. (@othiym23)

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 maintenace 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)

v3.10.0

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.

• 4e52cef #13077 Warn when using Node 6+. (@othiym23)

NEW LIFECYCLE SCRIPT: shrinkwrap

• e8c80f2 #10744 You can now add preshrinkwrap, shrinkwrap and postshrinkwrap to your package.json scripts section. They are run when you run npm shrinkwrap or npm install --save with an npm-shrinkwrap.json present in your module directory.

  preshrinkwrap is run prior to generating the new npm-shrinkwrap.json and the other two are run after. (@SimenB)

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.

• 6789978 #13075 npmlog@3.1.2: Update to the latest npmlog, which includes the new and improved progress bar layout. (@iarna)

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:

• ASCII – The fallback theme which is always available.
• colorASCII – Inverts the color of the completed portion of the progress bar. The default on Windows and usually on Linux. (Color support is determined by looking at the TERM environment variable.)
• brailleSpinner – A braille based spinner and other unicode enhancements. MacOS only.
• colorBrailleSpinner – The default on MacOS, a combination of the above two.

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.

• 63f153c #13075 Consistently make sure that the progress bar is hidden before we try to write to stdout. (@iarna)
• 8da79fa #13075 Be more methodical about disabling progress bars before running external commands. (@iarna)

REPLACE process.nextTick WITH asap ASAP

• 5873b56 254ad7e #12754 Use asap in preference over process.nextTick to avoid recursion warnings. Under the hood asap uses setImmediate when available and falls back to process.nextTick when it's not. Versions of node that don't support setImmediate have a version of process.nextTick that actually behaves like the current setImmediate. (@lxe)

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

• 8f3e111 c0b0ed1 #10800 Remove install pruning stage–this was obsoleted by making the installer keep itself up to date as it goes along. This is NOT related to npm prune. (@iarna)

MAKE OUTDATED MORE WIDELY LEGIBLE

• 21c60e9 #12843 In `npm outdated, stop coloring the Location and Package Type columns. Previously they were colored dark gray, which was hard to read for some users. (@tribou)

DOCUMENTATION UPDATE

• eb0a72e #12983 Describe how to run the lifecycle scripts of dependencies. How you do this changed with npm v2. (@Tapppi)

DEPENDENCY UPDATES

• da743dc which@1.2.10: Fix bug where unnecessary special case path handling for Windows could produce unexpected results on Unix systems. (@isaacs)
• 4533bd5 npm-user-validate@0.1.4: Validate the length...

v2.15.7

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.

• dff00ce #13077 Warn when using Node 6+. (@othiym23)

PACKAGING CHANGES

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

DOCUMENTATION CHANGES

• 470ae86 #12983 Describe how to run the lifecycle scripts of dependencies. How you do this changed with npm v2. (@Tapppi)
• 9cedf37 #12776 Remove mention of <pkg> arg for run-script. (@fibo)
• 55b8424 #12840 Remove sexualized language from comment. (@geek)
• d6bf0c3 #12802 Small grammar fix in doc/cli/npm.md. (@andresilveira)

DEPENDENCY UPDATES

• 2c2c568 readable-stream@2.1.4: Brought up to date with Node 6.1.0's streams implementation. (@calvinmetcalf)
• d682e64 npm/npm-user-validate#8 npm-user-validate@0.1.4: Add a maximum length limit for usernames based on the (arbitrary) limit imposed by the primary npm registry. (@aredridel)
• 448b65b which@1.2.10: Remove unused dependency is-absolute, bug fixes. (@isaacs)
• 7d15434 require-inject@1.4.0: Add requireInject.withEmptyCache and requireInject.installGlobally.andClearCache to support loading modules to be injected with an empty cache. (@iarna)
• 31845c0 init-package-json@1.9.4: Replace use of reserved identifier package in, uh, the package. (@adius)
• d73ef3e glob@7.0.4: Use userland fs.realpath implementation to get glob working under Node 6. (@isaacs)
• b47da85 inflight@1.0.5: Correct link to package repository, add "files" stanza. (@iarna, @jamestalmage)
• 04815e4 npm/npmlog#32 npmlog@2.0.4: Add "files" stanza to package.json. (@jamestalmage)
• 9e29ad2 wrappy@1.0.2: Add "files" stanza to package.json. (@jamestalmage)
• 44af4d4 abbrev@1.0.9 (@jorrit)
• 6c977c0 npm-registry-client@7.1.2: Add support for newer versions of npmlog. (@iarna)

v3.9.6

SMALL OUTPUT TWEAK

• 0bdc9d1 #12879 The usage output for npm commands was somehow under the impression that the singular form of aliases is aliase. This has been corrected to show alias instead. (@intelliot)

DOC UPDATES

• f771b49 #12933 Add config.gypi to list of files that are always ignored in the package.json manpage. (@Jokero)

DEPENDENCY UPDATES

• 61c1d9c #12926 Removed unused dependency lodash.isarray. (@mmalecki)
• 168ed28 #12926 Removed unused dependency lodash.keys. (@mmalecki)

v3.9.5

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.

• f96aea0 #12878 Ignore .nyc_output to avoid an accidental publish or commit filled with code coverage data. (@TheAlphaNerd)

v3.9.4

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

• cac0038 #12845 Progress bar during tarball packing now prints pack:packagename instead of pack:[object Object]. (@iarna)

DOC UPDATES

• 0b81622 #12840 Remove sexualized language from comment in code. (@geek)
• d6dff24 #12802 Small grammar fix in cli/npm.md. (@andresilveira)
• cb38e0f #12782 Documents that NOTICE files started getting included after npm/fstream-npm#17. (@SimenB)
• 70a3ae4 #12776 npm run-script used to have a <pkg> argument that allowed you to target specific packages' scripts. This was removed as one of the breaking changes for npm@2. This patch removes a mention of that argument, which really doesn't exist anymore. (@fibo)

DEP UPDATES

• 4a4470d aproba@1.0.3 (@iarna)

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.

• 9fd04dd #12851 Rewrite shrinkwrap-prod-dependency-also test to use common.npm (@iarna)
• 3bc4a8e #12851 Clean up rm-linked test. (@iarna)
• bf7f7f2 #12851 Clean up outdated-symlink test. (@iarna)
• ca0baa4 #12851 Improve diagnostics for shrinkwrap-scoped-auth test. (@iarna)
• fbec9fd #12851 Rewrite shrinkwrap-dev-dependency test to use common.npm. (@iarna)

v3.9.3

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

• 42d71be #12685 When using npm ls <pkg> without a semver specifier, npm ls would skip any packages in your tree that matched by name, but had a prerelease version in their package.json. This patch fixes it so npm ls does a simple name match unless you use the npm ls <pkg>@<version> format. (@zkat)
• c698ae6 #12685 Added some tests for more basic npm ls functionality. (@zkat)

NOTABLE DEPENDENCY UPDATES

• 3a6fe23 npm/fstream-npm#17 fstream-npm@1.1.0: fstream-npm always includes NOTICE files now. (@kemitchell)
• df04e05 #10013 read-package-tree@5.1.4: Fixes an issue where npm install would fail if your node_modules was symlinked. (@iarna)
• 584676f npm/init-package-json#62 init-package-json@1.9.4: Stop using package for a variable, which defeats some bundlers and linters. (@adius)
• 935a7e3 readable-stream@2.1.3: Node 6 build and buffer-related updates. (@calvinmetcalf)

OTHER DEPENDENCY UPDATES

• 4c4609e inflight@1.0.5 (@zkat)
• 7a3030d hosted-git-info@2.1.5 (@zkat)
• 5ed4b58 which@1.2.9 (@isaacs)