If I have a library (libA) that uses fooV1 and another (libB) that uses fooV2, there is no reason I should expect those two dependencies to interop with each other (except explicitly stated by the developer).
The solution (that there should be one set of dependencies) is an even worse problem that currently afflicts the Golang community, which they have decided to solve the same way npm has decided to solve it - vendoring.
Now with Golang, if you only have 1 set of dependancies, and one of your libraries depended on an older version - your program just won't compile (unless you update the library to use fooV2) and I'm not sure how thats useful to anyone. Most people will just tell you should have have just versioned that dependency.
IMO while this has contributed to the growth of node the ecosystem, it also stifled the growth of node the platform.
1) Windows' limit of 260 characters per path name is incredibly small for a modern OS and that was true many years ago as well.
2) Npm approach relied on well behaved OSes and file systems allowing long path names. It's not future proof because you don't know on which OS and file system you'll need to run, maybe some limited embedded device.
Ruby's rvm solved that problem with a single directory level and a gem@version naming scheme.
In general, node does this quite often – their memory model also assumes they have infinite memory.
https://msdn.microsoft.com/en-us/library/aa365247(VS.85).asp...
I guess the main thing is that it's one of those 'who cares' problems. The only time I've ever seen this limitation being complained about, it's by people who've had problems with npm.
That directory structure is undoubtedly horrible and is not mirrored by any other piece of software that I've seen.
I think the node_modules directory structure is a novel, though straightforward, solution to the problem of interdependent module versioning. It's very Unix; it reminds me a bit of GNU stow. It makes perfect sense that it will be tweaked in the new npm to be less redundant, but it only really makes sense to tweak systems that already work perfectly. (Otherwise they should be fixed first, then tweaked.) Certainly it's better than having a separate LD_LIBRARY_PATH setting for every command invocation! (even that doesn't fix everything...)
"All direct dependencies are in the node_modules directory, full-stop" is a pretty simple rule. Really, that's the only rule, and that's all of it. You don't need to worry about second-order dependencies, because those are direct dependencies of some other module, which means... they are in that module's node_modules directory.
Apart from that there is a backwards-compatible way of using longer paths, which is prefixing with \\?\. Since MAX_PATH is a hard-coded constant there can only be an opt-in way of dealing with the problem. Sadly many application or framework developers these days still don't opt in.
It also creates the problem that if Application A can create such paths and Application B cannot read them, you'll be annoyed too. And Application A might just disable long path support to mitigate the problem, leaving the whole state as it is.
Recently that is where you'll have heard about it a lot, but people have been hitting the problem for years. I've hit it in a couple of distinct contexts in my time.
You hardly hear about it generally because people moan a bit then work around it so the problem goes away until next time, and sometimes people don't even moan about it because it is such an old problem they just think "oh, that again, better make my directory/file names and/or paths a bit shorter" and get on with their day.
The difference between this and with npm over recent times (causing the greater noise around the issue) is that twofold:
* linux/similar people hitting the problem in the wild for the first time (they've probably heard about it, but never had to deal with it) because their code is getting used on Windows which was much more a rare occurrence for them in the past, and being incredulous that such a problem exists in this decade
* Windows people wanting to use node and similar cool new tech on their preferred and/or mandated platform but hitting issues due to this problem in their environment (and in some cases being incredulous that someone wouldn't consider the implications of the limitation it in their design)
If you work on the sysadmin side of things, this comes up almost every time with directories on network shares. Explorer, cmd and PowerShell can't handle them and you need to resort to using robocopy or 3rd party tools like FastCopy. To delete stuff you often have to resort to hacks like robocopy mirroring an empty directory into the path before deleting it.
This criticism is a bit misplaced here, since the whole reason for this limitation is due to backward compatibility with older versions of Windows (and software written for older versions).
It's not like this is a new change in Windows; it's been there for ages.
[1] https://github.com/joyent/node/issues/6960