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 db
s. 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!