You've been using NPM3 on many large projects with many developers, many commits, thousands of nested dependencies, and not run into a single problem? If so, that is a remarkable achievement, and I hope you'll write up how you've done it somewhere.
In particular, I envy whatever combination of dependencies and development platforms you get to work with, because I haven't seen a single project with no problems due to updates since NPM3 arrived, never mind all of them. (Edit: This is not intended to imply NPM3 is the only reason for the problems, only to define a comparable time frame.)
Even if you're in an environment where shrinkwrap is working well, we seem to find transitive dependencies of installed packages that introduce bugs or break something without correctly updated semver with alarming frequency. As some of us were discussing here on HN the other day, this has happened so often with Gulp plugins over the past few months that one project I work on dumped the entire Gulp ecosystem (and instantly and dramatically improved developer productivity as a direct result).
I didn't say not a single problem: I said "its fine, nothing bad happens, it works". Of course there are issues, and bugs, some of them due to dependencies breaking, but nothing calamitous or actually bad, and nothing out of the ordinary compared to other stacks and tools imo.
Npm module churn can be annoying sure, but on the flip side its good to be getting incremental patch updates sometimes too. And with exact versions in package.json and shrinkwrap you can eliminate enough uncertainty that to all intents and purposes its really not a problem.
> dumped the entire Gulp ecosystem
Amen to that. Gulp plugin eco-system has been messed up for a year or more. We do all our frontend builds with npm scripts now, running the bare cli tools where possible, and reducing dependencies as much as possible (e.g. Gulp and all its plugins).
I suppose we just have different amounts of tolerance for unexpected breakage.
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.
In practice, trusting semver has caused real world problems for some projects I'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'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/CI machine but whenever the developers tried it everything seemed to be working fine.
I guess I just don't understand the decision to make ambiguity the default with NPM, particularly with the Node/NPM culture of using very many small dependencies. It's not as if it'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've ever used does these things -- so introducing unnecessary variability just seems like asking for trouble.
In particular, I envy whatever combination of dependencies and development platforms you get to work with, because I haven't seen a single project with no problems due to updates since NPM3 arrived, never mind all of them. (Edit: This is not intended to imply NPM3 is the only reason for the problems, only to define a comparable time frame.)
Even if you're in an environment where shrinkwrap is working well, we seem to find transitive dependencies of installed packages that introduce bugs or break something without correctly updated semver with alarming frequency. As some of us were discussing here on HN the other day, this has happened so often with Gulp plugins over the past few months that one project I work on dumped the entire Gulp ecosystem (and instantly and dramatically improved developer productivity as a direct result).