Setting up coding standards tools for Javascript projects

Have you ever wasted a lot of time merging endless files just because someone committed a file with a different code style and refused to fix it?

Have you ever had problems with your code editor because it was formatting your code on save leaving it with some weird line breaks, or using tabs instead of spaces?

Have you ever pushed a commit to fix a typo, trying to reference _MyVar instead of _myVar?

If your answer is Yes to any of the questions above, or you just don’t want to find yourself in any of these situations, stick with me.

In this guide introduce you to some great tools that I use on my personal projects and here at Back4App. You will also learn how to set up a minimal JS project configuration that:

• Guarantees that everyone working on your project follows the same style guide.
• Automatically formats your code based on the style guide whenever you save the file.
• Displays warning/error messages whenever you reference an undefined variable, leave some unwanted console.log (who never?), or break a code style rule.
• Automatically formats your code and check errors (just like those described above) whenever hit git commit.

First of all, a quick overview of the tools that are going to shine in this guide.

Note: In this guide, we’ll stick with Visual Studio Code (not Visual Studio!), since it is a really popular code editor for JS and I highly recommend it. 

EditorConfig

EditorConfig helps developers to maintain code style when typing their fancy code across many code editors. Whenever you save a file or change tabs, it automatically formats your edited code using the style rules you have defined in a single configuration file. Sounds great, doesn’t it?

All you have to do is have an .editorconfig file at the root of your project. Here you define the code style rules for every file type opened by your editor and install/activate the plugin which integrates with your code editor.

Note: many code editors already come with EditorConfig natively bundled, so there is no need to install anything in this case, just create your .editorconfig file and have fun.

.editorconfig file samples

List of style rules supported

ESLint

ESLint is a linting tool that allows developers to discover problems with their JavaScript code without executing it. What is a linting tool? It takes care of Unused variables, variables that weren’t defined being referenced, an unwanted console.log, and many more problems. A linting tool warns you whenever it finds these kind of common JS problems.

Similar to the EditorConfig, ESLint uses a configuration file that contains its rules, .eslintrc. Additionally, makes it possible to extend some existing configurations. For instance, just extend Airbnb’s linting rules or Javascript standard rules, do your own customization (or not!), and never worry again about editing that config file.

List of rules supported

It also warns us about code style mistakes. It shows an error/warning message if you type something that goes against the code style rules as defined in the .eslintrc file. This feature is really great when integrated with…

Sign Up now to Back4App and start to build your javascript Project.

Prettier

Prettier is also a code formatter tool (just like EditorConfig), but it provides some additional rules, such as React’s JSX and ES6/7 styling rules. ESLint can be integrated with Prettier, so whenever you code something that goes against Prettier’s code style rules, ESLint displays an error/warning message telling you what’s wrong. Interesting, huh?

As you might expect, Prettier also uses a configuration file that holds all its styling rules, .prettierrc, and these are also extensible just like ESLint.

List of rules supported

“Why not just stick with Prettier and forget EditorConfig?”

The main reason EditorConfig is a good choice for some basic code styling rules (such as tab size, indent style, trim trailing whitespace, etc) is that many code editors come with native support to EditorConfig and Prettier lacks this feature. In addition, Prettier also takes into consideration all the rules defined in the .editorconfig file, so you won’t have to define the same rule twice! However, if you choose Prettier over EditorConfig, consider using some plugin to replace EditorConfig’s native styling during your coding sessions.

Husky

Husky is an npm package that helps create and run Git hooks, and most importantly, to share them with all your team. It means we can guarantee that both Prettier and ESLint runs whenever you, or one of your team hits git commit.

WHAAAT? That means there’s no way to commit the code?!

lint-staged

ABSOLUTELY YES! lint-staged is an npm package that allows us to run code quality tools like ESLint and Prettier, but ONLY on STAGED files. Instead of running your linter or code style tool over your entire project, you can only run these tools over a couple of files being committed! Sounds faster, right? No need to open Instagram whenever your linter starts working.

Pretty-Quick

Last but not least, Pretty-Quick runs Prettier over the staged files and also reports which are going to be changed. It can be integrated with Husky as a pre-commit hook so that whenever it styles some file, it stages that file again. Didn’t think about this issue? Pretty-Quick has it covered.

Setting up your project

Create our .editorconfig file. Do this either copying it from some sample or creating your own.

Install the EditorConfig plugin on your code editor (if not already installed).

Next, install our project dependencies using npm:

npm install --save-dev eslint prettier husky lint-staged pretty-quick

Create the configuration files for ESLint and Prettier. At the root directory of your project, create the following files:

.eslintrc.json

# Extension is optional here. Could be either .prettierrc or .prettierrc.json
.prettierrc

More about ESLint configuration file

More about Prettier configuration file

To stop ESLint checking our code style with its set of rules, and start using Prettier’s rules, we need two packages:

# This will get the ESLint configuration file (remember .eslintrc is extensible) that tells ESLint
# to simply ignore all its original code styling rules
npm install --save-dev eslint-config-prettier

# This plugin allows ESLint to check our code style using Prettier's rules
npm install --save-dev eslint-plugin-prettier

On your ESLint configuration file (I chose to use the JSON format, i.e.: .eslintrc.json):

{
  "extends": ["prettier"],
  "plugins": ["prettier"]
  "rules": {
    "prettier/prettier": ["error"]
  }
}

This will make ESLint extend the “prettier” configuration, and use the “prettier” plugin. Additionally, the "prettier/prettier": ["error"] rule tells ESLint to display an error message whenever your code does not match your code styling rules!

Optional: If you, like me, are lazy and wants to extend some existing linting standard, such as Airbnb’s linting rules, here’s what you need to do:

npx install-peerdeps --dev eslint-config-airbnb

And on your ESLint configuration file:

{
  "extends": ["airbnb", "prettier"],
  "plugins": ["prettier"]
  "rules": {
    "prettier/prettier": ["error"]
  }
}

At this point, EditorConfig, Prettier and ESLint should be set up. To set up Husky, lint-staged and Pretty-Quick, we need to edit our package.json:

{
  "dependencies": {
    ...
  },
  "devDependencies": {
    ...
  },
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "src/**/*.{js,jsx}": [
      "pretty-quick --staged",
      "eslint --fix",
      "git add"
    ]
  }
}

This edit tells Husky to execute the lint-staged task whenever the pre-commit hook is triggered. lint-staged then uses the "src/**/*.{js,jsx}" regex to find which files from our project will be piped through its list of commands.

And it’s done! Now you can start your coding sessions without worrying about merging endless commits due to different code styles!

Sign Up now to Back4App and start to build your javascript Project.