My 7 Node.js mantras

I’ve been using Node.js professionally since 3 years (with the help of 13 years of dev. experience in C, C++, PHP, Perl, Javascript, etc.) ; and like everyone else, I’ve faced a lot of (recurring) problems. I solved some using my Javacript knowledge but for the majority, I did it with the help of the community (mostly StackOverflow and Freenode).

From this experience, I taught myself 7 mantras for every Node.js projects that keeps me away from a lot of traps and pains.

1 — Beauty arise when you get a Promise

Really … Promises are a god’s gift to the JS developer community. Every time you think asynchronous (which happens almost every time with Node.js), you can (should) think Promise.

Initially, the Node.js adopted a convention for asynchronous functions : your last argument must be a callback function that takes two arguments, the first one being an error, the second one being the operation result.

fs.readFile(’/etc/passwd’, function (err, data) {
  if (err) throw err;
  console.log(data);
});

Now, in the promise world, this callback hell spaghetti code :

Becomes this elegant :

Beside the beauty of code, Promise allows you to control with ease all your async operations and makes it easier to debug.

Last but not least, Promise are available in your old Node.js version with the help of Bluebird (and it’s really fast !).

2 — ES6 is more than a bag of tricks

Here we are, the long-awaited Node V4.0 is out, with a lot of ES6 features. We can now safely say that ES6 is de facto a standard for Node.js developers.

During the last months, ES6 was a real subject but considered as a “cool thing to test” but not production ready ; I disagree. Babel produces a nice-to-read, safe and optimized ES5 code, so anyone could already code in ES6 and use its lot of new features. But still, it was a risk because a company would have suffer in hiring an ES6-ready team. Ok.

But time has changed, with Node V4 and all the browser that keeps on implementing it, ES6 should now be a prerequisite for any JS developer position and offers a lot of optimization, code sugars, safety and more …

Choosing ES6 right now is also a strategic point, your ES5 code will soon (months ? a year) be deprecated !

3 — Ignoring semver makes problem occur

With Node.js comes npm. With npm comes your package.json. package.json is the biggest key to success or failure when it comes to maintainability, deployment and stability.

Every time you add a dependency to your project with npm install — save, npm will install this package and save it to the dependencies property ; but npm doesn’t only saves the package it also the required version — required means here “The version I need to work correctly”. This version respects the semver format.

It’s important here to not just trust npm (which will use a caret (^) by default) ; using caret means that you trust (and I really mean TRUST) the package maintainer(s) to respect strictly the semver versioning. It he (they) introduces a breaking change in a minor build, you’re screwed up.

If you’re working with on a professional project, I advise you to choose a different strategy, like exact-save and to upgrade your packages version manually. You’ve got enough work with your bugs, don’t import other’s one !

4 — Knowing your dependencies keeps away some diseases

This mantra is linked to the previous one. Node.js is module based by architecture and our work, as Node.js dev, is not only to produces code. We have to know, understand, study, observe(and maybe contribute to) EVERY package we require().

A lot of time, I found myself searching for a node module on Google, then fastly read the description on npmjs.com, and if it matched my needs, a fast npm install — save did the trick… Fatal error !

Here is my check list now to decide if I depend (the word is exact, after all) or upgrade a package :

• The stats on npmjs.com or github

• The CHANGELOG to check if semver is respected (Eg: restify)
• The commit history, to check if it’s still active (Eg: express)
• The issues/PR tracker, to see if the project has a community (Eg: request)
• The CI status if it has unit testing (Eg: mocha on travis-ci)
• Its dependencies status (out of date) (Eg: socket.io on David)

5 — Offer yourself some rest with unit tests

Unit testing has always been a very good solution to industrial development problems, almost anyone would advise to use it ; I’m personally a big fan of TDD and I couldn’t agree more. But when it comes to Node.js, my opinion is that it’s not an advise, it’s mandatory and it can defeat all the “it takes too much extra time” argument.
Of course, the main goal of unit test is to ensure that your code is not buggy, answers to a problematic and doesn’t introduce new bugs on updates. Like in all languages. But as we saw it in mantra 3 & 4, Node.js is based on a module system, and its philosophy is to use as most as possible the Microservice pattern ; we HAVE TO depend on a lot of external modules ; depending doesn’t mean a blind trust.

The best way to be sure about a package upgrade is having a collection of unit tests that will performs operations like “Does it return that when I pass this”, “Does it throws if I do that” or “Does my code detects if this does not return that”. This may sound like a waste of time or reinventing the wheel on a package that already has some unit tests, but trust me (not blindly huh ?), soon or later, you’ll regret it and probably spend more time to identify and fix the sub-sub-sub dependency that made your website burping 500 pages while your COO is asking you every 37 seconds on yammer “is it fixed now ? what’s going on ??!”.

6 — Knowing V8 will calm your heart rate

Let’s talk semantic. PHP is a language. And also a runtime. Zend Engine is it’s engine.
Javascript is a language. Node.js a runtime. V8 is it’s engine. An there again, the word is correct ; you can see it as your car engine.
The way to Node.js mastering goes through knowing (at least a little bit) V8. V8 performance makes Node.js performance, and of course, V8 bugs and caveats are Node’s one !

For this mantra, all is detailed in Bluebird’s Optimization killers page. For all the TL; DR, here is some ways to make your code slower and buggy :

• Playing with arguments
• Using more than 128 case-clauses in a switch case
• Using for...in or for…of
• debugger, eval, with (KILL IT WITH FIRE, BEFORE IT LAYS EGGS)
• Object litterals with __proto__, get or set

7 — Use (AirBnB) eslint and reviewers doesn’t squint

This last one is very personal and I don’t think it’s a good or a bad practice, it’s mine.
Javascript is a very flexible language, code readability (although it’s very difficult to rate it) goes to WTF to poetry.

Anyway, we have to work together and respect some conventions, the main reason being :

The greatest code style with a popularity I found so far is AirBnB Javascript Style Guide, they did a great work with detailing all their choices and it meets almost all of my preferences.

That being said, having a code convention is a thing, respecting it is another. That’s the linter’s job, and for this work, eslint is my best choice (After some years of fidelity to JSHint).
ESlint is pluggable, fast, they have a detailed page about each rule tested and it’s actively maintained.
Oh and it’s ES6 ready.
Oh(2), as I’m a lucky guy, AirBnB has published an ESlint package for their style guide.

So, when I’m allowed to do it (a lot of company I’ve worked for has their own style guide and/or linters), I always setup this little stack in my npm prepublish script to check my code before publishing and activate ESlint support in Webstorm (yeah, another subject ;).