Despite it's awesomeness, there were always two major issues with running Node.js on Windows: First and foremost, the operating system maintains a maximum length for path names, which clashes with Node's traditional way of nesting modules in node_modules. The second issue was a bit more subtle: The npm 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. This resulted in a bunch of hard-to-debug race conditions and other problems which, from the outside, looked like black, evil magic.
Both issues will soon be history - we're now looking at the first build of npm@3, a nearly complete rewrite of Node's package manager, which will end both of these major issues. This is a huge deal for those of us who built and maintain big Node projects on Windows.
There be dragons
Before you install npm@3 and use it in production, be warned that this is still beta software, with potentially a bunch of breaking changes and unknown bugs. Obviously, the whole node community and npm are working hard to get it production-ready as quickly as possible. To quote npm: "During that time we will still be doing npm@2 releases, with npm@2 tagged as latest and next. We'll also be publishing new releases of npm@3 as npm@3.0-next and npm@3.0-latest alongside those versions until we're ready to switch everyone over to npm@3."
Flat Module Installation
Previously, your project's required modules would be installed in node_modules. If they themselves required modules, they'd be installed in node_modules/{package}/node_modules. The problem is obvious here, but it was surprisingly hard to work around - solutions involving npm shrinkwrap and module-flattening techniques existed, but it wasn't pretty.
Your dependencies will now be installed flat - by default. If possible, all of your dependencies, and their dependencies, and their dependencies will be installed in your project's node_modules folder without nesting. Nesting will only occur when two or more modules have conflicting dependencies.
Moving forward, deduping is the standard - and a bunch of commands are dedupe-aware by default. The command npm ls will now show you a tree of module requirements and no longer how they are organized on disk. Conveniently, npm uninstall removes a package and all it's requirements - previously, it just removed those packages that were in its node_modules folder. In summary: I'm so excited about this improvement that I want to throw a chair through a window.
Multi-Stage Installing
From time to time, we at Microsoft working in the Open Source world had to deal with random race conditions. And when I write "from time to time", I mean "all the fricking time". Npm issue #5919 is now finally done, changing the way installation works. Rebecca Turner from npm has been pivotal for the new multi-stage installer (which carefully waits for steps and processes to finish before moving on).
While none of these changes look super sexy, I want you all to rejoice every single time you run a big npm build (ideally involving a bunch of nasty native code) and don't run into race condition and lock-file weirdness. Chances are that you should thank Rebecca for that.
Using it Today
Again, it's beta software. But if nobody's using it, we won't find issues. So go ahead and play with it - you can install it using this small upgrade tool.