An example of a current problem in NPM land, is "peer dependencies". Suppose 30 of your direct and indirect dependencies require one popular, fast moving librar

An example of a current problem in NPM land, is "peer dependencies". Suppose 30 of your direct and indirect dependencies require one popular, fast moving library, say, React. For safety's sake, and to spare the effort of regression testing, many of these modules specify a fairly conservative version range for their own React dependency. Normally, NPM would just give you multiple versions of React, and each library would get the React version that it expects. There is a small problem and a big problem with this. The small problem, is that your build size will be unreasonably large. The big problem, is that this React library has internal state - you can't just initialise multiple copies of it, and expect them to share a single state. Enter peer dependencies. Each library that needs React, demands that the root module, your application, specify a normal depency on React, that satisfies their version range requirements. Clearly, this quickly becomes impossible. So, version mismatch is treated as a warning, not an error, and you (the application developer) learn to basically ignore that warning. I can think of lots of solutions to this problem, all of which have problems of their own. - All libraries factor out their state, so that they are stateless. Now you can load multiple instances of a module, but if they have different major versions, then they are totally going to mess up that state that you are holding for them. - Application developer: it is your responsibility to patch your dependencies, and their dependencies, so that they all accept an overlapping range of React versions. But who has time to test 30 modules for regressions? - Just build more, smaller, simpler applications. This is where I am right now. I still get version warnings, but it is a little less risky to ignore them. How do you handle this issue in the Java community?