Site is currently on development mode

Enforcing Code Quality for Node.js

Last updated 1 year ago by Patrick Lee Scott


If you are going to be writing code and shipping it to production, it’s important that the code is high quality.

In my last article, I showed you how to use docker-compose to leverage standardized, already existing Dockerfiles for development. The next step in getting our application ready for deployment is productionizing it.

I’m going to continue using the React/Parcel example from my earlier tutorial: Move over Next.js and Webpack!

Here is the source code:

I also haven’t done anything else related to getting the application “production ready”, so I’ll also talk about what is required for that, though it may take another article to finish… we’ll see how it goes. I’m ad-libbing this.

Let’s start with some quality control.

In this article we will explore Linting, Formatting, Unit Testing and Code Coverage and enforce some quality standards.

Linting & Formatting

According to Wikipedia, to “Lint, or a linter, is a tool that analyzes source code to flag programming errors, bugs, stylistic errors, and suspicious constructs.”

This means it enforces things like using spaces vs. tabs or making sure your code using semicolons consistently or not.

There are probably a bunch of linting errors in my project currently.

My goal so far has to demonstrate particular concepts and having too many sidebars about different things really takes away from the concepts at hand. Therefore I chose to forgo linting to keep the previous articles focused.

Now that it’s time to “productionize” our app, quality is of increased priority.

My preferred linter format is StandardJS, which is a very minimalist setup. But before we set that up, let’s talk about formatting as well.

Formatting is similar to linting, but less focused on syntax errors and more focused on just making the code look prettier, hence the name of the popular package prettier.

Thanks to a couple of awesome open-source contributors on Github we can use them both in one package — prettier-standard. Thanks to Adam Stankiewicz, Kent C. Dodds, Adam Garrett-Harris, and Benoit Averty!

In the past I’ve written about using husky to make sure rules are run before each commit. The prettier-standard package also recommends doing so, so let’s add prettier-standard, husky, and lint-staged now.

Read full Article