Skip to content

Latest commit

 

History

History
4490 lines (3867 loc) · 245 KB

CHANGELOG.md

File metadata and controls

4490 lines (3867 loc) · 245 KB
Raw

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

  • 423d8f7 #8704 Add the ability to disable the new progress bar with --no-progress (@iarna)

AND BUG FIXES

  • b3ee452 #9038 We previously disabled the use of the new fs.access API on Windows, but the bug we were seeing is fixed in [email protected] so we now use fs.access if you're using that version or greater. (@iarna)

  • b181fa3 #8921 #8637 Rejigger how we validate modules for install. This allow is to fix a problem where arch/os checking wasn't being done at all. It also made it easy to add back in a check that declines to install a module in itself unless you force it. (@iarna)

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

  • As usual, we've ported all the npm@2 goodies in this week's v2.13.3 release.

v2.13.3 (2015-07-23):

I'M SAVING THE GOOD JOKES FOR MORE INTERESTING RELEASES

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

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

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

IT'S THE LITTLE THINGS THAT MATTER

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

WHAT DOES THIS BUTTON DO?

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

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

THE SEMVER MAJOR VERSION APOCALYPSE IS UPON US

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

*BUMP*

And some other version bumps for good measure.

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

SO MANY LINKS YOU COULD MAKE A CHAIN

  • 6d69ec9 #8967 Removing a module linked into your globals would result in having all of its subdeps removed. Since the npm release process does exactly this, it burned me -every- -single- -week-. =D While we're here, we also removed extraneous warns that used to spill out when you'd remove a symlink. (@iarna)

  • fdb360f #8874 Linking scoped modules was failing outright, but this fixes that and updates our tests so we don't do it again. (@iarna)

WE'LL TRY NOT TO CRACK YOUR WINDOWS

  • 9fafb18 #8701 npm@3 introduced permissions checks that run before it actually tries to do something. This saves you from having an install fail half way through. We did this using the shiny new fs.access function available in node 0.12 and io.js, with fallback options for older nodes. Unfortunately the way we implemented the fallback caused racey problems for Windows systems. This fixes that by ensuring we only ever run any one check on a directory once. BUT it turns out there are bugs in fs.access on Windows. So this ALSO just disables the use of fs.access on Windows entirely until that settles out. (@iarna)

ZOOM ZOOM, DEP UPDATES

MERGED FORWARD

v2.13.2 (2015-07-16):

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

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

Rebecca: No Way! Again?

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

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

LET'S GIT INKY

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

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

Rebecca: What should we use instead?!

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

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

NEWS FLASH! DOCUMENTATION IMPROVEMENTS!

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

STAY FRESH~

Kat: That's it for npm core changes!

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

Kat: See you all next week!

Both: Stay Freeesh~

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

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

  • 9badfd6 #8608 Make global installs and uninstalls MUCH faster by only reading the directories of modules referred to by arguments. (@iarna
  • 075a5f0 #8660 Failed optional deps would still result in the optional deps own dependencies being installed. We now find them and fail them out of the tree. (@iarna
  • c9fbbb5 #8863 The "no compatible version found" error message was including only the version requested, not the name of the package we wanted. Ooops! (@iarna
  • 32e6bbd #8806 The "uninstall" lifecycle was being run after all of a module's dependencies has been removed. This reverses that order-- this means "uninstall" lifecycles can make use of the package's dependencies. (@iarna

MERGED FORWARD

v2.13.1 (2015-07-09):

KAUAI WAS NICE. I MISS IT.

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

MAKE OURSELVES HAPPY

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

MAKE TRAVIS HAPPY

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

MAKE npm outdated HAPPY

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

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

  • 0030ade #8685 Windows would hang when trying to clone git repos (@euprogramador)
  • b259bcc #8786 Windows permissions checks would cause installations to fail under some circumstances. We're disabling the checks entirely for this release. I'm hoping to check back with this next week to get a Windows friendly fix in. (@iarna)

SO MANY BUGS SQUASHED, JUST CALL US RAID

  • 0848698 #8686 Stop leaving progress bar cruft on the screen during publication (@ajcrites)
  • 57c3cea #8695 Remote packages with shrinkwraps made npm cause node + iojs to explode and catch fire. NO MORE. (@iarna)
  • 2875ba3 #8723 I uh, told you that engineStrict checking had gone away last week. TURNS OUT I LIED. So this is making that actually be true. (@iarna)
  • 28064e5 #3358 Consistently allow Unicode BOMs at the start of package.json files. Previously this was allowed some of time, like when you were installing modules, but not others, like running npm version or installing w/ --save. (@iarna)
  • 3cb6ad2 #8736 npm@3 wasn't running the "install" lifecycle in your current (toplevel) module. This broke modules that relied on C compilation. BOO. (@iarna)
  • 68da583 #8766 To my great shame, npm link package wasn't working AT ALL if you didn't have package already installed. (@iarna)
  • edd7448 [email protected]: This update makes read-package-tree not explode when there's bad data in your node_modules folder. npm@2 silently ignores this sort of thing. (@iarna)
  • 0bb08c8 #8778 RELATEDLY, we now show any errors from your node_modules folder after your installation completes as warnings. We're also reporting these in npm ls now. (@iarna)
  • 6c248ff #8779 Hey, you know how we used to complain if your package.json was missing stuff? Well guess what, we are again. I know, I know, you can thank me later. (@iarna)
  • d6f7c98 So, when we were rolling back after errors we had untested code that tried to undo moves. Being untested it turns out it was very broken. I've removed it until we have time to do this right. (@iarna)

NEW VERSION

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

v2.13.0 (2015-07-02):

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

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

YES HELLO THIS IS NPM REGISTRY SORRY NO DOG HERE

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

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

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

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

ALL YOUR FILE DESCRIPTORS ARE BELONG TO US

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

READ THE FINE DOCS. THEY'VE IMPROVED

MORE NUMBERS! MORE VALUE!

OH AND ONE MORE THING

v2.12.1 (2015-06-25):

HEY WHERE DID EVERYBODY GO

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

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

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

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

WHEW! ALL DONE FIXING GIT FOREVER!

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

Sighs audibly.

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

YEP, THERE ARE STILL DEPENDENCY UPGRADES

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 and @isaacs have been talking about the changes in this release for well over a year, and it's been the primary focus of @iarna since she joined the team.

Given that this is a near-total rewrite, all changes listed here are @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 [email protected] and [email protected] 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!

  • #6930 (#6565) peerDependencies no longer cause anything to be implicitly installed. Instead, npm will now warn if a packages peerDependencies are missing, but it's up to the consumer of the module (i.e. you) to ensure the peers get installed / are included in package.json as direct dependencies or devDependencies of your package.
  • #3803 npm also no longer checks peerDependencies until after it has fully resolved the tree.

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
  • #6931 The rarely-used package.json option engineStrict has been deprecated for several months, producing warnings when it was used. Starting with npm@3, the value of the field is ignored, and engine violations will only produce warnings. If you, as a user, want strict engines field enforcement, just run npm config set engine-strict true.

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
  • 77f1aec With npm view (aka npm info), always return arrays for versions, maintainers, etc. Previously npm would return a plain value if there was only one, and multiple values if there were more. (@KenanY)

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!

  • #8575 Circular deps will never be removed by the prune-on-uninstall code.
  • #8588 Local deps where the dep name and the name in the package.json differ don't result in an error.
  • #8637 Modules can install themselves as direct dependencies. npm@2 declined to do this.
  • #8660 Dependencies of failed optional dependencies aren't rolled back when the optional dependency is, and then are reported as extraneous thereafter.

NEW FEATURES

The multi-stage installer!

  • #5919 Previously the installer had a set of steps it executed for each package and it would immediately start executing them as soon as it decided to act on a package.

    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:

  • #6926 (#5001, #6170) install and postinstall lifecycle scripts now only execute after all the module with the script's dependencies are installed.
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!
  • #6928 (#2931 #2950) npm install when you have an npm-shrinkwrap.json will ensure you have the modules specified in it are installed in exactly the shape specified no matter what you had when you started.
  • #6913 (#1341 #3124 #4956 #6349 #5465) npm install when some of your dependencies are missing sub-dependencies will result in those sub-dependencies being installed. That is, npm install now knows how to fix broken installs, most of the time.
  • #5465 If you directly npm install a module that's already a subdep of something else and your new version is incompatible, it will now install the previous version nested in the things that need it.
  • a2b50cf #5693 When installing a new module, if it's mentioned in your npm-shrinkwrap.json or your package.json use the version specifier from there if you didn't specify one yourself.
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.

  • #3697 This will hopefully eliminate most cases where windows users ended up with paths that were too long for Explorer and other standard tools to deal with.
  • #6912 (#4761 #4037) This also means that your installs will be deduped from the start.
  • #5827 This deduping even extends to git deps.
  • #6936 (#5698) Various commands are dedupe aware now.

This has some implications for the behavior of other commands:

  • npm uninstall removes any dependencies of the module that you specified that aren't required by any other module. Previously, it would only remove those that happened to be installed under it, resulting in left over cruft if you'd ever deduped.
  • npm ls now shows you your dependency tree organized around what requires what, rather than where those modules are on disk.
  • #6937 npm dedupe now flattens the tree in addition to deduping.

And bundling of dependencies when packing or publishing changes too:

  • #2442 bundledDependencies no longer requires that you specify deduped sub deps. npm can now see that a dependency is required by something bundled and automatically include it. To put that another way, bundledDependencies should ONLY include things that you included in dependencies, optionalDependencies or devDependencies.
  • #5437 When bundling a dependency that's both a devDependency and the child of a regular dependency, npm bundles the child dependency.

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

  • #6781 Second, if you save your changes to package.json and you have npm-shrinkwrap.json, then it will be updated as well. This applies to all of the commands that update your tree:
    • npm install --save
    • npm update --save
    • npm dedupe --save (#6410)
    • npm uninstall --save
  • #4944 (#5161 #5448) Third, because node_modules folders are now deduped and flat, shrinkwrap has to also be smart enough to handle this.

And finally, enjoy this shrinkwrap bug fix:

  • #3675 When shrinkwrapping a dependency that's both a devDependency and the child of a regular dependency, npm now correctly includes the child.
The Age of Progress (Bars)!
  • #6911 (#1257 #5340 #6420) The spinner is gone (yay? boo? will you miss it?), and in its place npm has progress bars, so you actually have some sense of how long installs will take. It's provided in Unicode and non-Unicode variants, and Unicode support is automatically detected from your environment.

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:

  • 9ebe312 Build system maintainers, rejoice: npm does a better job of cleaning up after itself in your temporary folder.
  • #6942 Check for permissions issues prior to actually trying to install anything.
  • Emit warnings at the end of the installation when possible, so that they'll be on your screen when npm stops.
  • #3505 npm --dry-run: You can now ask that npm only report what it would have done with the new --dry-run flag. This can be passed to any of the commands that change your node_modules folder: install, uninstall, update and dedupe.
  • 81b46fb npm now knows the correct URLs for npm bugs and npm repo for repositories hosted on Bitbucket and GitLab, just like it does for GitHub (and GitHub support now extends to projects hosted as gists as well as traditional repositories).
  • 5be4008a npm has been cleaned up to pass the standard style checker. Forrest and Rebecca both feel this makes it easier to read and understand the code, and should also make it easier for new contributors to put merge-ready patches. (@othiym23)

ZARRO BOOGS

  • 6401643 Make sure the global install directory exists before installing to it. (@thefourtheye)
  • #6158 When we remove modules we do so inside-out running unbuild for each one.
  • 960a765 The short usage information for each subcommand has been brought in sync with the documentation. (@smikes)

v2.12.0 (2015-06-18):

REMEMBER WHEN I SAID THAT THING ABOUT PERMISSIONS?

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

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

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

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

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

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

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

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

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

SMALLISH BUG FIXES

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

SMALLERISH DOCUMENTATION TWEAKS

WELL, I GUESS THERE ARE MORE DEPENDENCY UPGRADES

v2.11.3 (2015-06-11):

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

TESTS IN 0.8 FAIL LESS

THE TREADMILL OF UPDATES NEVER CEASES

v2.11.2 (2015-06-04):

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

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

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

QUALITY OF LIFE HAS NEVER BEEN BETTER

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

WORDS HAVE NEVER BEEN QUITE THIS READABLE

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

VERSION NUMBERS HAVE NEVER BEEN BIGGER

v2.11.1 (2015-05-28):

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

CONFERENCE WIFI CAN'T STOP THESE BUG FIXES

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

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

v2.11.0 (2015-05-21):

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

FEATURELETS

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

BUG FIXES

DOCUMENTATION IMPROVEMENTS

DEPENDENCY UPDATES! ALWAYS AND FOREVER!

LICENSE FILES FOR THE LICENSE GOD

SPDX LICENSE UPDATES

v2.10.1 (2015-05-14):

BUG FIXES & DOCUMENTATION TWEAKS

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

DEPENDENCY UPDATES! STILL! MORE! AGAIN!

v2.10.0 (2015-05-8):

THE IMPLICATIONS ARE MORE PROFOUND THAN THEY APPEAR

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

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

For you as a user of npm, this means:

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

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

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

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

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

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

BUG FIXES

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

v2.9.1 (2015-04-30):

WOW! MORE GIT FIXES! YOU LOVE THOSE!

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

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

DOCUMENTATION FIXES AND TWEAKS

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

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

ENROBUSTIFICATIONMENT

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

DEPENDENCY UPDATES WAIT FOR NO SOPHONT

v2.9.0 (2015-04-23):

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

NANOFEATURES

  • 2799322 #7426 Include local modules in npm outdated and npm update. (@ArnaudRinquin)
  • 2114862 #8014 The prefix used before the version on version tags is now configurable via tag-version-prefix. Be careful with this one and read the docs before using it. (@kkragenbrink)

OTHER MINOR TWEAKS

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

DEPENDENCIES WILL NOT STOP UNTIL YOU ARE VERY SLEEPY

v2.8.4 (2015-04-16):

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

v2.8.3 (2015-04-15):

TWO SMALL GIT TWEAKS

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

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

v2.8.2 (2015-04-14):

PEACE IN OUR TIME

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

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

v2.8.1 (2015-04-12):

CORRECTION: NPM'S GIT INTEGRATION IS DOING OKAY

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

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

SCOPED DEPENDENCIES AND PEER DEPENDENCIES: NOT QUITE REESE'S

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

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

MAKING IT EASIER TO WRITE NPM TESTS, VERSION 0.0.1

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

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

This had some negative consequences:

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

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

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

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

THE EVER-BEATING DRUM OF DEPENDENCY UPDATES

v2.8.0 (2015-04-09):

WE WILL NEVER BE DONE FIXING NPM'S GIT SUPPORT

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

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

Here's a summary of what's changed:

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

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

TEST FIXES FOR NODE 0.8

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

SMALL FIX AND DOC TWEAK

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

v2.7.6 (2015-04-02):

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

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

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

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

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

OTHER SIGNIFICANT FIXES

  • 78005eb #7743 Always quote arguments passed to npm run-script. This allows build systems and the like to safely escape glob patterns passed as arguments to run-scripts with `npm run-script <script> -- `. This is a tricky change to test, and may be reverted or moved to `npm@3` if it turns out it breaks things for users. ([@mantoni](https://github.com/mantoni))
  • da015ee #7074 [email protected]: read-package-json no longer caches package.json files, which trades a very small performance loss for the elimination of a large class of really annoying race conditions. See #7074 for the grisly details. (@othiym23)
  • dd20f57 [email protected]: Only add the @ to scoped package names if it's not already there when reading from the filesystem (@watilde), and support inline validation of package names (@michaelnisi).

SMALL FIXES AND DEPENDENCY UPGRADES

v2.7.5 (2015-03-26):

SECURITY FIXES

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

BUG FIXES

DEPENDENCY UPDATES

DOCUMENTATION FIXES

v2.7.4 (2015-03-20):

BUG FIXES

DEPENDENCY UPDATES

A NEW REGRESSION TEST

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

v2.7.3 (2015-03-16):

HAHA WHOOPS LIL SHINKWRAP ISSUE THERE LOL

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

v2.7.2 (2015-03-12):

NPM GASTROENTEROLOGY

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

LESS DRAMATIC CHANGES

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

DEPENDENCY REFRESH

v2.7.1 (2015-03-05):

GITSANITY

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

WHY DID THIS TAKE SO LONG.

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

BUGS & TWEAKS

###E TYPSO & CLARFIICATIONS

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

v2.7.0 (2015-02-26):

SOMETIMES SEMVER MEANS "SUBJECTIVE-EMPATHETIC VERSIONING"

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

Until now.

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

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

A SMALL FEATURE WITH BIG IMPLICATIONS

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

@WATILDE'S NPM USABILITY CORNER

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

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

SMALLER FEATURES AND FIXES

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

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

DOCUMENTATION TWEAKS

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

DEPENDENCY UPDATES

v2.6.1 (2015-02-19):

v2.6.0 (2015-02-12):

A LONG-AWAITED GUEST

DEPRECATIONS

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

BUG FIXES & TWEAKS

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

v2.5.1 (2015-02-06):

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

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

[email protected]:

MINOR DEPENDENCY TWEAK

v2.5.0 (2015-01-29):

SMALL FEATURE I HAVE ALREADY USED TO MAINTAIN NPM ITSELF

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

BUG FIXES & TWEAKS

[email protected]:

v2.4.1 (2015-01-23):

bridge that doesn't meet in the middle

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

v2.4.0 (2015-01-22):

REGISTRY 2: ACCESS AND DIST-TAGS

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

NOT EXACTLY SELF-DEPRECATING

BUG FIX AND TINY FEATURE

v2.3.0 (2015-01-15):

REGISTRY 2: OH MY STARS! WHO AM I?

BETTER REGISTRY METADATA CACHING

HOW MUCH IS THAT WINDOWS IN THE DOGGY?

THRILLING BUG FIXES

v2.2.0 (2015-01-08):

v2.1.18 (2015-01-01):

v2.1.17 (2014-12-25):

merry npm xmas

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

Other changes:

v2.1.16 (2014-12-22):

v2.1.15 (2014-12-18):

v2.1.14 (2014-12-13):

v2.1.13 (2014-12-11):

v2.1.12 (2014-12-04):

v2.1.11 (2014-11-27):

v2.1.10 (2014-11-20):

v2.1.9 (2014-11-13):

v2.1.8 (2014-11-06):

v2.1.7 (2014-10-30):

v2.1.6 (2014-10-23):

v2.1.5 (2014-10-16):

OUTDATED DEPENDENCY CLEANUP JAMBOREE

v2.1.4 (2014-10-09):

TEST CLEANUP EXTRAVAGANZA:

v2.1.3 (2014-10-02):

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

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

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

Other changes:

v2.1.2 (2014-09-29):

v2.1.1 (2014-09-26):

v2.1.0 (2014-09-25):

NEW FEATURE:

Other changes:

v2.0.2 (2014-09-19):

v2.0.1 (2014-09-18):

v2.0.0 (2014-09-12):

BREAKING CHANGES:

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

Other changes:

v1.4.28 (2014-09-12):

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

v1.4.27 (2014-09-04):

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

SPECIAL LABOR DAY WEEKEND RELEASE PARTY WOOO

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

v1.4.26 (2014-08-28):

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

v1.4.25 (2014-08-21):

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

v1.4.24 (2014-08-14):

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

BREAKING CHANGE:

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

Other changes:

v1.4.23 (2014-07-31):

  • 8dd11d1 update several dependencies to avoid using semvers starting with 0.

v1.4.22 (2014-07-31):

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

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

Other changes:

v1.5.0-alpha-4 (2014-07-18):

  • fall back to _auth config as default auth when using default registry (@isaacs)
  • support for 'init.version' for those who don't want to deal with semver 0.0.x oddities (@rvagg)
  • be06213 remove residual support for win log level (@aterris)

v1.5.0-alpha-3 (2014-07-17):

v1.4.21 (2014-07-14):

v1.5.0-alpha-2 (2014-07-01):

v1.4.20 (2014-07-02):

v1.5.0-alpha-1 (2014-07-01):

v1.5.0-alpha-0 (2014-07-01):

v1.4.19 (2014-07-01):

v1.4.18 (2014-06-29):

v1.4.17 (2014-06-27):

  • replace escape codes with ansicolors (@othiym23)
  • Allow to build all the docs OOTB. (@GeJ)
  • Use core.longpaths on win32 git - fixes #5525 (@bmeck)
  • [email protected] (@isaacs)
  • Consolidate color sniffing in config/log loading process (@isaacs)
  • add verbose log when project config file is ignored (@isaacs)
  • npmconf: Float patch to remove 'scope' from config defs (@isaacs)
  • doc: npm-explore can't handle a version (@robertkowalski)
  • Add user-friendly errors for ENOSPC and EROFS. (@voodootikigod)
  • bump tar and fstream deps (@isaacs)
  • Run the npm-registry-couchapp tests along with npm tests (@isaacs)

v1.2.8000 (2014-06-17):

  • Same as v1.4.16, but with the spinner disabled, and a version number that starts with v1.2.

v1.4.16 (2014-06-17):

v1.4.15 (2014-06-10):

v1.4.14 (2014-06-05):

  • char-spinner: update to not bork windows (@isaacs)

v1.4.13 (2014-05-23):

  • Fix npm install on a tarball. (ed3abf1, #5330, @othiym23)
  • Fix an issue with the spinner on Node 0.8. (9f00306, @isaacs)
  • Re-add npm.commands.cache.clean and npm.commands.cache.read APIs, and document npm.commands.cache.* as npm-cache(3). (e06799e, @isaacs)

v1.4.12 (2014-05-23):

  • remove normalize-package-data from top level, de-^-ify inflight dep (@isaacs)
  • Always sort saved bundleDependencies (@isaacs)
  • add inflight to bundledDependencies (@othiym23)

v1.4.11 (2014-05-22):

  • fix npm ls labeling issue
  • [email protected]
  • default repository to https:// instead of git://
  • addLocalTarball: Remove extraneous unpack (@isaacs)
  • Massive cache folder refactor (@othiym23 and @isaacs)
  • Busy Spinner, no http noise (@isaacs)
  • Per-project .npmrc file support (@isaacs)
  • [email protected], Refactor config/uid/prefix loading process (@isaacs)
  • Allow once-disallowed characters in passwords (@isaacs)
  • Send npm version as 'version' header (@isaacs)
  • fix cygwin encoding issue (Karsten Tinnefeld)
  • Allow non-github repositories with npm repo (@evanlucas)
  • Allow peer deps to be satisfied by grandparent
  • Stop optional deps moving into deps on update --save (@timoxley)
  • Ensure only matching deps update with update --save* (@timoxley)
  • Add support for prerelease, preminor, prepatch to npm version

v1.4.10 (2014-05-05):

  • Don't set referer if already set
  • fetch: Send referer and npm-session headers
  • run-script: Support --parseable and --json
  • list runnable scripts (@evanlucas)
  • Use marked instead of ronn for html docs

v1.4.9 (2014-05-01):

  • Send referer header (with any potentially private stuff redacted)
  • Fix critical typo bug in previous npm release

v1.4.8 (2014-05-01):

  • Check SHA before using files from cache
  • adduser: allow change of the saved password
  • Make npm install respect config.unicode
  • Fix lifecycle to pass Infinity for config env value
  • Don't return 0 exit code on invalid command
  • cache: Handle 404s and other HTTP errors as errors
  • Resolve ~ in path configs to env.HOME
  • Include npm version in default user-agent conf
  • npm init: Use ISC as default license, use save-prefix for deps
  • Many test and doc fixes

v1.4.7 (2014-04-15):

v1.4.6 (2014-03-19):

v1.4.5 (2014-03-18):

v1.4.4 (2014-02-20):

  • Add npm t as an alias for npm test (which is itself an alias for npm run test, or even npm run-script test). We like making running your tests easy. (14e650b, @isaacs)

v1.4.3 (2014-02-16):

v1.4.2 (2014-02-13):

v1.4.1 (2014-02-13):

v1.4.0 (2014-02-12):

v1.3.26 (2014-02-02):

v1.3.25 (2014-01-25):

  • Remove gubblebum blocky font from documentation headers. (6940c9a, @isaacs)

v1.3.24 (2014-01-19):

  • Make the search output prettier, with nice truncated columns, and a --long option to create wrapping columns. (20439b2 and 3a6942d, @timoxley)
  • Support multiple packagenames in npm docs. (823010b, @timoxley)
  • Fix the npm adduser bug regarding "Error: default value must be string or number" again. (b9b4248, @isaacs)
  • Fix scripts entries containing whitespaces on Windows. (80282ed, @robertkowalski)
  • Fix npm update for Git URLs that have credentials in them (93fc364, @danielsantiago)
  • Fix npm install overwriting npm link-ed dependencies when they are tagged Git dependencies. (af9bbd9, @evanlucas)
  • Remove npm prune --production since it buggily removed some dependencies that were necessary for production; see #4509. Hopefully it can make its triumphant return, one day. (1101b6a, @isaacs)

Dependency updates:

v1.3.23 (2014-01-03):

  • Properly handle installations that contained a certain class of circular dependencies. (5dc93e8, @substack)

v1.3.22 (2013-12-25):

  • Fix a critical bug in npm adduser that would manifest in the error message "Error: default value must be string or number." (fba4bd2, @isaacs)
  • Allow npm bugs in the current directory to open the current package's bugs URL. (d04cf64, @evanlucas)
  • Several fixes to various error messages to include more useful or updated information. (1e6f2a7, ff46366, 8b4bb48; @rlidwka, @evanlucas)

v1.3.21 (2013-12-17):

  • Fix a critical bug that prevented publishing due to incorrect hash calculation. (4ca4a2c, @dominictarr)

v1.3.20 (2013-12-17):

  • Fixes a critical bug in v1.3.19. Thankfully, due to that bug, no one could install npm v1.3.19 :)

v1.3.19 (2013-12-16):

  • Adds atomic PUTs for publishing packages, which should result in far fewer requests and less room for replication errors on the server-side.

v1.3.18 (2013-12-16):

  • Added an --ignore-scripts option, which will prevent package.json scripts from being run. Most notably, this will work on npm install, so e.g. npm install --ignore-scripts will not run preinstall and prepublish scripts. (d7e67bf, @sqs)
  • Fixed a bug introduced in 1.3.16 that would manifest with certain cache configurations, by causing spurious errors saying "Adding a cache directory to the cache will make the world implode." (966373f, @domenic)
  • Re-fixed the multiple download of URL dependencies, whose fix was reverted in 1.3.17. (a362c3f, @spmason)

v1.3.17 (2013-12-11):

  • This release reverts 644c2ff, which avoided re-downloading URL and shinkwrap dependencies when doing npm install. You can see the in-depth reasoning in d8c907e; the problem was, that the patch changed the behavior of npm install -f to reinstall all dependencies.
  • A new version of the no-re-downloading fix has been submitted as #4303 and will hopefully be included in the next release.

v1.3.16 (2013-12-11):

  • Git URL dependencies are now updated on npm install, fixing a two-year old bug (5829ecf, @robertkowalski). Additional progress on reducing the resulting Git-related I/O is tracked as #4191, but for now, this will be a big improvement.
  • Added a --json mode to npm outdated to give a parseable output. (0b6c9b7, @yyx990803)
  • Made npm outdated much prettier and more useful. It now outputs a color-coded and easy-to-read table. (fd3017f, @quimcalpe)
  • Added the --depth option to npm outdated, so that e.g. you can do npm outdated --depth=0 to show only top-level outdated dependencies. (1d184ef, @yyx990803)
  • Added a --no-git-tag-version option to npm version, for doing the usual job of npm version minus the Git tagging. This could be useful if you need to increase the version in other related files before actually adding the tag. (59ca984, @evanlucas)
  • Made npm repo and npm docs work without any arguments, adding them to the list of npm commands that work on the package in the current directory when invoked without arguments. (bf9048e, @robertkowalski; 07600d0, @wilmoore). There are a few other commands we still want to implement this for; see #4204.
  • Pass through the GIT_SSL_NO_VERIFY environment variable to Git, if it is set; we currently do this with a few other environment variables, but we missed that one. (c625de9, @arikon)
  • Fixed npm dedupe on Windows due to incorrect path separators being used (7677de4, @mcolyer).
  • Fixed the npm help command when multiple words were searched for; it previously gave a ReferenceError. (6a28dd1, @dereckson)
  • Stopped re-downloading URL and shrinkwrap dependencies, as demonstrated in #3463 (644c2ff, @spmason). You can use the --force option to force re-download and installation of all dependencies.