NPM 2.x is actually very slow.<p>Part of that is just the monstrous number of files involved. For example, one of our projects has 48 dependencies, which installs 24,421 files under node_modules. NPM could probably benefit from managing each dependency as an archive.<p>We do atomic deploys and try to make them reproducible, so for each deploy we do a fresh install from npm-shrinkwrap.json, but even when all the modules are in NPM&#x27;s local cache it&#x27;s very slow at copying everything.<p>Unfortunately, NPM doesn&#x27;t version the node_modules folder (a package becomes .&#x2F;node_modules&#x2F;mypackage&#x2F;...)), so you can&#x27;t reuse it. The NPM cache <i>is</i> versioned ($cachedir&#x2F;mypackage&#x2F;3.23&#x2F;...), but can&#x27;t be used directly. It would be much better to skip the cache altogether, and have node_modules embed version strings (.&#x2F;node_modules&#x2F;mypackage-3.23&#x2F;...). Then you could easily share the folder across builds.<p>NPM is also pretty brittle. We frequently have deploys fail because of transient network errors (repository timing out or similar) that cause NPM to fall over. The dreaded mysterious &quot;npm ERR cb() never called&quot; error still hits us weekly.<p>(Speaking of reproducible builds: NPM lets people unpublish packages. Sometimes old versions just disappear, presumably because they were unpublished. 6 months later you want to deploy a certain app, and you find it depends on some package X, which deep in its dependency graph relies on package Y 0.3, but 0.3 is gone from npmjs.com, so you have to upgrade for no reason at all.)