From our experience of working on Node.js projects, we’ve established a common set of development libraries and services that help a great deal with building those projects, and we thought it would be good to share them.
What do Node.js projects need?
Whether it is a server-based job worker or a web application, there is a common need for tools that tackle these requirements:
- Testing and code coverage
- Code consistency and quality
- Keeping dependencies up-to-date and secure
We’ll cover the categories one by one.
Testing and Code coverage
There are lots of different libraries and tools for testing Node.js code. In our projects we’ve tended to use a combination of unit testing, integration testing, and code coverage analysis to provide a comprehensive approach to testing our code.
Mocha is one of the most popular testing tools in the Node.js ecosystem, and those coming from RSpec in the Ruby community will be familiar with its style and approach to unit testing. It allows developers to write unit tests for their code, handle asynchronous code execution, and use hooks to seed and destroy data for the tests.
Some people have also used Mocha to handle integration testing in combination with a web driver like wd for Selenium or PhantomJS, a headless version of Webkit. For us, we prefer to use a combination of some other Node.js libraries to do integration testing.
Cucumber has been described by its creator as the world’s most misunderstood testing tool. Cucumber is a tool for describing the behaviour of an application feature in human terms. This provides a way of documenting how the application should work. This documentation is then read by Cucumber.js’ Gherkin parser and converted into steps, which are then matched via Regular expressions to functions that can execute code.
The code that is executed can be anything, even code that drives a web browser, allowing developers to automate quality assurance testing. This is why Cucumber is such a powerful tool, and one that in my experience isn’t known well enough among both developers, user experience analysts, and product managers.
In the past, we’ve used a library called soda in combination with selenium-launcher to handle integrating testing our code via Cucumber. Unfortunately this library isn’t maintained anymore, so we recommend using wd instead. Selenium-launcher is still maintained.
If you would like to see an example of this to play with, consider downloading Dashku (an open source, realtime dashboard solution), and running the tests on it (though check what version of Firefox you have running, as Firefox 37 stopped working with Selenium driver 2.44).
Istanbul by Krishnan Anantheswaran at Yahoo is a code coverage analysis tool that helps you to check whether your code has been executed by tests, and helps to highlight where untested code exists. Having used it to help evaluate legacy Node.js projects as well as on a large open source web framework, it’s value cannot be underrated. In the picture above, we’ve been using Istanbul to help show where to improve code coverage on SocketStream, a realtime web framework. SocketStream was a large web framework that was developed in prototype fashion (meaning no tests), and so over time we’ve added tests to it, getting the code coverage up to 77% at the time of writing.
In combination with using Istanbul for code coverage, Coveralls is an online SaaS for collecting code coverage statistics over time, and can be useful for helping to track when code coverage declines below thresholds, and warn developers when it does.
Code consistency and Quality
Being able to get code written by multiple developers to fit a consistent style and high quality is a good challenge, and one that can be supported by a variety of tools and services out there.
Linting code with jshint is an effective way of being able to ensure that the code maintains a consistent style (such as not mixing tabs and spaces) and preventing the use of bad patterns (such as using == for equality evaluation), and spotting errors like undefined variables being used in the code.
An honourable mention goes to Standard, a linting tool from Feross Aboukhadijeh that sets a predefined set of rules for linting your code with, and has become quite popular with NPM modules in recent months.
Code Climate is a code analysis tool that helps to identify issues with code simiar to linting, but extends on top of this by analysing the complexity of the code, spotting duplicate code, and helping to identify which files could use improvements.
Another code analysis service is Codacy. Similar to Code Climate, Codacy provides code analysis on your code, provides information and stats on where complexity and duplication exists in your code, and graphs issues over time in line with commits. This helps to spot cases where code gets worse and isn’t necessarily spotted in code reviews (or in cases where no code reviews were done). It can be an invaluable tool for helping to review legacy Node.js projects and pinpoint where issues exist.
Often one of the last things to be done on a project before a developer leaves, documentation is a crucial part of being able to make sure that developers can work on a project without becoming dependent on one person for crucial bits of knowledge, especially if that person is on holiday.
When it comes to storing documentation in a place where developers can easily search and add/alter documents, Raneto offers a compelling option. Written in Node.js and based on Markdown, Raneto is an open source knowledgebase platform that can be easily modified to fit your needs.
Developers can sometimes leave TODO notes in their source code when they are in the middle of a coding session, and easily forget about them and not put them in any task tracking system.
The notes module is a very helpful command-line tool for searching a codebase and finding any code comments tagged as NOTE, TODO, FIXME in the code. You can install it like so:
npm install -g notes
After installing it, run “notes” on your codebase, and you should see some notes in your code, along with where they are:
Keeping dependencies up-to-date and secure
NPM dependencies can easily get out of date quickly, meaning that unresolved bugs and security issues can linger in your code indirectly. Thankfully there are a number of tools for helping to take care of this.
NPM-dview is an npm module for checking the dependencies listed in your package.son file, and will print out a table report on the command line, like so:
npm install -g npm-dview
David is another dependency management tool for Node.js projects. It also has an npm module for checking the dependencies from the command line, but the main value of David is that it will show security notices for any npm modules that you use (such as when the marked npm module was found to have a security vulnerability).
For those who want to keep a closer eye on their software dependencies and know when new versions are released, Libraries.io from Andrew Nesbitt is a nice tool for exploring not just node modules on NPM, but also software packages across 29 package managers.
With these libraries and tools, you can help enhance the quality of your Node.js projects, maintain high standards for your code, and ensure that future developers who arrive onto projects can work more effectively with them.
I’m writing a book, and available for hire
Also, we’re available for hire on Node.js projects. If you’re interested, get in touch.