Node.js Best Practices – Part 2

You may remember our previous post on Node.js best practices. In this article we will continue with more best practices that can help you become a better Node.jsNode.js is an asynchronous event-driven JavaScript runtime and is the most effective when building scalable network applications. Node.js is free of locks, so there's no chance to dead-lock any process. developer.

Consistent Style

When developing JavaScript applications in a bigger team, it is important to create a style guide that everyone accepts and adapts to. If you are looking for inspiration, I would recommend checking out the RisingStack Node.js Style Guide.

But this is just the first step – after you set a standard, all of your team members have to write code using that style guide. This is where JSCS comes into the picture.

JSCS is a code style checker for JavaScript. Adding JSCS to your project is a piece of cake:

npm install jscs --save-dev

The very next step you have to make is to enable it from the package.json file by adding a custom script:

scripts: {
	"jscs": "jscs index.js"
}

Of course, you can add multiple files/directories to check. But why we have just created the custom script inside the package.json file? We installed jscs as a local dependency only, so we can have multiple versions on the same system. This will work because NPMnpm is a software registry that serves over 1.3 million packages. npm is used by open source developers from all around the world to share and borrow code, as well as many businesses. There are three components to npm: the website the Command Line Interface (CLI) the registry Use the website to discover and download packages, create user profiles, and... will put node_modules/.bin on the PATH while executing.

You can set your validation rules in the .jscsrc file, or use a preset. You can find the available presets here, and can use them with --preset=[PRESET_NAME].

Enforce JSHint / JSCS Rules

Your build pipeline should contain JSHint and JSCS as well, but it may be a good idea to run pre-commit checks on the developers’ computers as well.

To do this easily you can use the pre-commit NPM package:

npm install --save-dev pre-commit

and configure it in your package.json file:

pre-commit": [
	"jshint",
	"jscs"
],

Note, that pre-commit will look up what to run in your package.json‘s script section. By enabling this, these checks will run before every commit.

JS over JSON for configuration

We see that a lot of project uses JSON files as configuration sources. While this may be a widespread approach, JS files provide more flexibility. For this purpose we encourage you to use a config.js file:

Use NODE_PATH

Have you ever encountered something like the following?

When you end up with a quite complex project structure, requiring modules may get messy. To solve this problem you have two options:

• symlinking your modules into the node_modules folder
• use NODE_PATH

At RisingStack we use the NODE_PATH way, as symlinking everything to the node_modules folder takes extra effort, and may not work for various operating systems.

Setting up NODE_PATH

Imagine the following project structure:

Instead of using relative paths, we can use NODE_PATH which will point to the lib folder. In our package.json‘s start script we can set it and run the application with npm start.

Dependency Injection

Dependency injection is a software design pattern in which one or more dependencies (or services) are injected, or passed by reference, into a dependent object.

Dependency injection is really helpful when it comes to testing. You can easily mock your modules’ dependencies using this pattern.

In the example above we have two different dbs. In the index.js file we have the “real” db module, while in the second we simply create a fake one. This way we made it really easy to inject fake dependencies into the modules we want to test.

Need a helping hand in developing your application?

RisingStack provides JavaScript development and consulting services – ping us if you need a helping hand!