And yes that means that bigger surface area leads to more problems.
This is less severe if you are only working on few projects at a time that you gradually update. It still sucks and is completely unnecessary, but only in tiny bits over a spread out time period.
However if touch code from just a year ago, then you might get some of these fun, breaking changes and bugs. Even more fun if you're not familiar with the build tool, or the packaging tool, because there are a dozen of those around as well and someone decided to use X at the time because why not. And you need a specific version of those too.
The Go modules thing is similarly painful, but it's not the best example of what I describe, because there is a very clear cut change from the previous way of doing things. It sucks but there is a clear path forward. With a JS project you get the feeling that you are walking on a minefield.
I've had compatibility issues with rebar, rubygems, pip, go modules and many more.
Once you're pulling in third party dependencies and the tools that manage them - in any development environment - you open yourself up to these issues. At some point, you have to update dependencies and/or tools (for security reasons if nothing else). And at some point, either the dependencies or the tools will break in a way that has you hunting down issues and workarounds that are outside the scope of what you're actually trying to accomplish.
Is JS significantly worse in this regard? It does seem like the propensity for many small packages increases the surface area of things that can go wrong, but that doesn't seem to be a flaw in the tooling.