3 ms·

First of all, npm 2's infinite nesting of dependency was a terrible design from the beginning. It was always broken (This is why on our windows build servers we

by Khao 11y ago

First of all, npm 2's infinite nesting of dependency was a terrible design from the beginning. It was always broken (This is why on our windows build servers we need to do all sorts of stupid workaround to make npm work). There is no other decent package manager that nests dependencies within dependencies like that, every other package manager out there has a flat structure with packages and their version, so 2 versions of a same package can co-exist with no issues. By fixing this huge flaw in their design, I thought there would be an increase in performance! In the end, they made it even worse. It makes no sense that fixing their flawed design would result in a 3x worse performance for doing the same task.

atonparker 11y ago
NPM 2 was and is not broken. There are ~200,000 packages on the NPM registry, and ~2,700,000,00 downloads in the last month. In the past four years it has done wonderful things for node.js and javascript development in general. The nested dependency tree worked great on *nix systems. Was the max path on Windows annoying? Of course it was. But stop pretending like it completely prevented you from accomplishing anything. And if you were deploying to a Windows server why did you pick an ecosystem and package manager that has always made it clear that Windows is a second class citizen? There are always trade offs. Now NPM 3 has worked around the utterly idiotic max path on Windows at the cost of slower installs. That's also annoying. It's also temporary. Just wait a little, and keep using NPM 2 if speed is your top concern.