3 Random Tips for Node.js Development

At Quenk Technologies, Node.js is the go to framework for Web development.

The flexibility of JavaScript, excellent package manager and a ridiculous number of third party libraries are among the main reasons for this. There is also isomorphic JavaScript which is kind of a big deal.

That’s not to say Node does not have issues of its own (like any software platform) but here are three random tips that may help you miss some of them.

Use the REPL

On your command line type node.

This starts the Read Eval Print Loop.

I like to use this to test features of JavaScript, Node and third party frameworks I’m not sure about.

Let’s say you just npm install‘d a new library and the API documentation isn’t that comprehensive.

What to do, read the source? This is JavaScript in the wild, good luck!

You could write a few lines of code to a file and do node file, but why even pollute your project space?

You can require files in the REPL just like in your scripts, set variables call methods and anything else you need to do. When you are done experimenting, simply close the session.

This works particularly well if you develop with tools like tmux that let you split console windows to your heart’s content.

npm scripts

I tried grunt but I found myself spending more time maintaining grunt files than actually writing code.

Along came gulp which is fantastic when using gulp files generated by yeoman generators, but once I started editing them myself the fun stopped.

I have seen a number of projects on Github preferring Makefiles to Grunt and Gulp but I never did quite get the hang of Makefiles and I always found them weird (or should I say PHONY?).

Enter bash!

Well bash, sh, csh, zsh, really whatever terminal emulator you keep on your system.

In a node project’s package.json, a special field exists called scripts.

You can read more about it in the docs but the point is, you can run arbitrary terminal commands by specifying them in this field.

Example:

{
 "name":"respect",
 "description":"An app that demands respect.",
 "scripts": {
  "test": "mocha -R spec test/*.js",  
  "bundle": "./node_modules/.bin/browserify -t babelify index.js > app.js"
}

You can now do npm run bundle, and browserify will get to work on your index.js file.

Note that I am not using the global install of browserify, by doing this my application is much more portable.

All another developer needs to do is npm install and he/she is ready to hack. No bloated IDE needed, the build process is all there in the scripts field. ;)

@substack has a nice post on this.

npm shrinkwrap

Do you shrinkwrap your production code?

The npm shrinkwrap command locks the dependencies of your application to currently installed versions. This ensures that regardless of what you specify in package.json, the exact same version you used during development (or whenever you run npm shrinkwrap) gets installed.

You may wonder what the point of this is when we can explicitly declare the version of a module we want in package.json already. However, we can’t specify the version of our dependencies’ dependencies and there are situations where this can introduce some subtle bugs.

Let’s say we require module A@0.5.1 which requires module B@1.6.x. When we run npm install, it will install the latest patched version (the x in 1.6.x) of module B. What if that introduces a bug in module A that the author has not addressed yet?

npm shrinkwrap recursively records all module dependencies to a file called npm-shrinkwrap.json which npm will utilize when installing your modules in the future. I like to think of it as a snapshot of the node_modules folder.

Do you find these tips useful?

Node.js development can be daunting at first but once you establish some procedures and a work-flow for yourself, you get to realize how productive it is.

Quenk Blog