Basically, it's about "we can't use lib x because it will break lib y" - this already happens in java and I would consider java being very conservative and slow-progressing.
Now, imagine how quickly is javascript evolving, libraries, frameworks, etc.
Solution to dependency hell is a major reason why node.js succeeded (along with browserify/webpack) unlike anything with flat dependencies (bower)
It's one of the biggest problems in fronted development right now and it's something conceivably can be addressed by the... well, let's call it "guiding structural paradigm" for the lack of a less pretentious term.
I don't know, in my frontend experience dependency hell is less about conflicting dependencies and more about literally installing 690 packages after one `npm install <package>`.
Fixes need to happen in the broader npm ecosystem, not the standard for creating reusable components.
Now, imagine how quickly is javascript evolving, libraries, frameworks, etc.
Solution to dependency hell is a major reason why node.js succeeded (along with browserify/webpack) unlike anything with flat dependencies (bower)