I suppose we just have different amounts of tolerance for unexpected breakage.<p>It sounds like we do have a similar philosophy as far as tooling goes: simple scripts, minimal dependencies. But I add to that a strong preference for tools like build systems and package managers and source control systems to have completely deterministic behaviour and therefore provide reproducible results by default.<p>In practice, trusting semver has caused real world problems for some projects I&#x27;ve worked on with non-dev dependencies too. For example, a few weeks ago, Facebook pushed a bad update to React that completely broke dev builds on IE. It was fixed a few days later, but during that window NPM considered the broken version just as good as the version we&#x27;d been developing and testing with for the past couple of weeks. Tracking that one down wasted a few hours in our office as we tried to figure out why tests were failing on our new build&#x2F;CI machine but whenever the developers tried it everything seemed to be working fine.<p>I guess I just don&#x27;t understand the decision to make ambiguity the default with NPM, particularly with the Node&#x2F;NPM culture of using very many small dependencies. It&#x27;s not as if it&#x27;s difficult to issue a message if a newer version of something relevant is available, or to provide a command or option to deliberately change to newer versions of packages -- pretty much every package manager in every language I&#x27;ve ever used does these things -- so introducing unnecessary variability just seems like asking for trouble.