NodeJS: Freeze dependences before testing and deployment? Check in node_modules?

Question

Suppose you have a NodeJS application. A release could consists of multiple steps:

1. Automated and/or manual tests
2. Deployment
3. (if something goes wrong) Rollback to the last stable version

There are some desirable requirements regarding the application's dependencies:

• When you have done your testing, you want to deploy exactly the version that you tested with, including all dependencies.
• The same goes for rollbacks: You want to restore not only your own code, but all external dependencies, too.

My question is about best practices to meet this goals.

What is the recommended way to create a snapshot of all dependencies of your NodeJS application?

Here are three options that I can think of:

1. In this article, the author recommends to put the node_modules directory under source control. (Not for all modules, but only for modules that will be deployed.)

2. One alternative, which the same article describes as an anti-pattern, is to use explicit version locking. His argument seems reasonable: When you lock, for example, Express to a certain version, you still cannot control that one of its dependences hasn't introduced a subtile bug, later.

3. Just don't care and always use the most recent version of all external modules.

---

My thoughts so far (but I don't have much experience with NodeJS yet):

• 3) seems to be too reckless.
• I tend to 1), but I'm not sure where to put the node_modules. When you just check it along with your normal code, I fear that workflows like npm link to your local modules will no longer work. Additionally, there is always the problem of annoying merge conflicts.

Answer 1

You can use npm shrinkwrap to implement option #2 and lock all of the child dependencies. From the doc:

This command locks down the versions of a package's dependencies so that you can control exactly which versions of each dependency will be used when your package is installed. The "package.json" file is still required if you want to use "npm install".

• Philipp Claßen: Thanks! I didn't know that command. Here, they also recommend to use shrinkwrap: codebetter.com/glennblock/2012/07/29/… Checking in still has some advantages, but it is not strictly required.

Answer 2

I do not understand your nead of a node_modules version control. I mean you can easily define which version the dependency should have:

{
 "name": "native-gpio",
 "version": "0.0.6",
 "description": "sysfs GPIO wrapper for node.js",
 "author": "Bodo Kaiser <[email protected]>",
 "license": "MIT",
 "keywords": ["gpio", "addon"],
 "main": "lib/index.js",
 "gypfile": true,
 "scripts": {
 "test": "make test",
 "install": "make install"
 },
 "dependencies": {
 "node-gyp": "0.10.6"
 },
 "devDependencies": {
 "mocha": "1.12.0",
 "chai": "1.7.2"
 },
 "repository": {
 "type": "git",
 "url": "git://github.com/bodokaiser/node-native-gpio.git"
 },
 "bugs": {
 "url": "https://github.com/bodokaiser/node-native-gpio/issues"
 }
}

• Philipp Claßen: Yes, that is what he called "explicit version locking" in the article. His argument against it was that even if you now know that you are getting node-gyp version 0.10.6, you cannot be sure that all its dependencies are the exact same. Libraries, in general, will always use the latest versions. npm shrinkwrap will produce a packages.json where all dependences are explicit and thus seems to avoid that problem.