I don't understand this argument. If you know what parts of your site the deps will effect it should be trivial to update them incrementally and rollback the commit if one unexpectedly breaks your code.
Besides, there's no universal unwritten rule stating that you have to use the bleeding edge version of every dependency.
Keeping all dependencies up-to-date is mostly in the interest of widely used libraries not one-off applications.
Not sure what the OP's problem was, but I've had issues with old libraries where some dependencies have been removed from npmjs.com. It's totally ridiculous.
I solve such problem for our clients by packaging every dependency we use in project as independent RPM package, so whole application can be installed using single "yum install ..." command from local repository without need to connect to internet. It allows us to precisely control version of libraries we use and also allows to apply patches to them when a problem is found.
So it's not immutable? Blinkin' egg, I'm happy I only played with node.js now. On the other hand, I guess it's always better to vendor one's deps, at least those that are not packaged by the operating systems. The language specific package managers add a lot of complexity.
I went as far as pulling the node_modules directory from production and perfectly matching the node version on my local machine. Linux -> linux and the app won't run locally. I think it's because the node-gyp influenced deps need to be built locally and linked to the right libs.
I then spent a few hours downgrading each version to isolate the issue...found a few libraries that were hard-deprecated (which was nice), found some breaking changes in the node version I'm using and then I just gave up.
Besides, there's no universal unwritten rule stating that you have to use the bleeding edge version of every dependency.
Keeping all dependencies up-to-date is mostly in the interest of widely used libraries not one-off applications.