If possible, all of your dependencies, and their dependencies, and their dependencies will be installed in your project’s node_modules folder without nesting. Your dependencies will now be installed flat – by default. 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. If they themselves required modules, they’d be installed in node_modules//node_modules. Previously, your project’s required modules would be installed in node_modules. The Problem: Nested Modules & Race Conditions This case study describes the development of a small upgrader script, enabling Node developers on Windows to easily upgrade their npm version.

This is a huge deal for those of us who built and maintain big Node projects on Windows. This resulted in a bunch of hard-to-debug race conditions and other problems which, from the outside, looked like black, evil magic.īoth issues will soon be history – we’re now looking at the first build of a nearly complete rewrite of Node’s package manager, which will end both of these major issues. 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. Despite it’s popularity, 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.

Windows upgrade npm