No, I strongly disagree. Npm may have some weird ergonomics and defaults, but as a dependency manager it is first class. Before npm, almost all dependency managers suffered from the diamond dependency problem. Npm pioneered allowing multiple versions of packages to be simultaneously installed without having to chase down conflicting dependencies as long as the package involved is not a major framework (i.e. peer dependency). For example you can’t (or at least strongly discouraged to) have react v15 and react v20 in the same project, but you can have leftpad v1 and leftpad v3 in the same project. You cannot do this in most other languages like Ruby Python Dart C++ etc. (Java has a similar but half baked concept called shading which requires a separate plugin) Go and Rust followed what npm pioneered, allowing multiple conflicting dependencies too, saving countless hours of developer time. Rust goes as far as supporting linking against code from different language versions. Without npm, Cargo would be doing NP class dependency searches and Rust developers would be wasting forking old upstream repos to bring them up to date. Not everybody has the engineering resources of google to build everything in house and keep every single dependency in sync through a massive monorepo and test suite.

In the npm-style dependency managers, generally speaking, you don’t really get dependency conflicts unless it’s a large overarching peer dependency or something like global singleton e.g. a GPU driver. Regardless of your thoughts on npm or having a massive number of tiny dependencies, you can’t deny npm dragged the dependency management field into the 21st century and forced it to scale.

This is such a wild take. I’m constantly running into issues with bundler and literally never have issues with npm or yarn. Not to mention the amount of innovation happening within that world with module resolution algorithms.