Personally I don't like tooling that magically does transitive dependency management - it creates the problem of bloat by making it too easy to add stuff - stuff that typically never gets removed.
Doing dependency management at the shared library level rather than source level, also results in massive bloat - you might only need one call for a library, but the whole library and all it's dependences, and their dependencies etc etc get pulled in - a ridiculous mess - then you have the whole different versions of libraries problem.
Things like npm, maven etc are the problem, not a solution in my view.
Dependency management is a tremendous quality of life improvement, but you're not wrong: deep webs of dependency suck.
The Java ecosystem is a better about this than npm, but good public libraries need to make the aesthetic choice to keep minimal dependencies.
Helper/toolkit libraries like Guava or Lodash should pretty much be end user only. Your gzip library doesn't need em.
I get they're convenient, but if you're going to use 3 helpers in 5 places just fork those little bits and add them to your own codebase. DRY is for applications not libraries.
I like to see dependencies no more than 5 deep which is usually at the edge of manageability. For Java the critical path looks like:
Doing dependency management at the shared library level rather than source level, also results in massive bloat - you might only need one call for a library, but the whole library and all it's dependences, and their dependencies etc etc get pulled in - a ridiculous mess - then you have the whole different versions of libraries problem.
Things like npm, maven etc are the problem, not a solution in my view.