package.json version control and npm update? npm install --save will install the package you want, and add it to package.json

Why wouldn't your repo merge package.json between your changes? I'm doing the same thing when I merge changes to production. I add packages as I work on things at the desktop, and sync changes to production server.

Unfortunately, the regular package.json and related npm commands are built around semver, and typically also only specify direct dependencies. Either of those alone is enough to violate the simple condition I gave many times over on a real project, because it means you can't in practice guarantee that two developers are even running the same code. It's actually worse with the latest NPM changes that flattened the tree in node_modules, because now there are order dependencies affecting which versions of things you get as well.

The closest NPM has to an answer for this is shrinkwrap, but that adds a lot of complexity of its own, and still has limitations. In fact, there's a note at the bottom of the npm shrinkwrap documentation page suggesting that if you really want to control your dependencies robustly, you need to check everything into source control -- which is obviously the sensible thing to do, except that because npm does magic in node_modules that can involve all kinds of funky build steps, you're not checking in just the source for the modules you depend on, but might have all kinds of other artifacts that may or may not be portable as well.

In short, it is all but impossible in practice to use Node and NPM to satisfy the most basic of development requirements: getting all of your developers (or production systems, for that matter) to actually run exactly the same code. If that's not a catastrophic failure to meet the requirements for a package management system, I don't know what is.

Personally I don't find using npm shrinkwrap a chore at all. If npm 3+ notices a shrinkwrap file in the project it'll update it automatically, so most of the time you don't even have to think about it.

We've been using npm 3 on multiple large projects spanning frontend and backend, being worked on by many developers, pushing code through CI into production many times a day and npm installing fresh in every environment. There are probably many thousands of nested dependencies in some projects. It works, nothing bad happens, it's fine.

Npm comes with some trade offs, true, but also a long list of plus points as well. No system is perfect, but you're painting some calamitous disastrous picture here which simply isn't reflected in reality.

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).

> and not run into a single problem?

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.