By Ruslan Prytula February 13, 2017 12:18 AM
JS code linting

Last few years have dramatically changed JavaScript. Nowadays, a typical JS application is a big code base that involves a few developers and significant efforts. Having a linter in your JS app is a must-have feature. In this post I’ll try to encourage developers to use one in their JS apps.

Linting your code has few important advantages, such as:

  • defines a formatting standard to make code base consistent, readable and understandable to everyone in a team.
  • forces developers to improve their code, making it more professional (no unused imports, no duplicate keys in an object, no mixed space / tab indention etc …)
  • helps to eliminate the bugs.

Why ESLint?

Fortunately, we have a pretty good selection of linting tools for JavaScript applications. After making a research and testing different tools I’ve decided to stay with ESLint since it has few valuable benefits for me, for example:

  • great ES6 and JSX support
  • large community and active development
  • wide set of rules to use
  • automatic fixes to code

Integration

Based on the needs, you could either run a linting procedure in a git-hook or perform it on the fly as you run your code (for example with eslint-loader for wepback). Both approaches have their pros and cons, but in my opinion the git-hook way provides a better experience, cause we could lint only modified / created files, it’s faster and you don’t mix js and linting errors in the console.

Another option could be to run the linter as a part of a build process on your CI server, although I don’t think having unlinted code in your repository is a good idea.

Using git hook

Firstly, let’s install eslint and some module to manage our git hooks. I’ll go with pre-commit, but it doesn’t really make any significant difference if you want to use husky or any other simular tool.

npm i eslint pre-commit --save-dev

Secondly, let’s create our .eslintrc file. A complete list of configuration keys could be found here. By the way, there is always an option to just extend the rules defined by current IT giants (Google, Airbnb etc …) if you prefer to save some time on configuration.

module.exports = {
    "env": {
        "browser": true
    },
    "extends": "eslint:recommended",
    "parserOptions": {
        "sourceType": "module"
    },
    "rules": {
        "quotes": [
            "error",
            "single"
        ],
        "semi": ["error", "never"],
        "newline-after-var": ["error", "always"],
        ...
    }
};

Thirdly, let’s define the required configuration for pre-commit in your your package.json, for example:

...
"scripts": {
  ...
  "lint": "git diff HEAD --name-only --diff-filter=ACM | grep 'app/' | grep '.js$' | xargs eslint && exit 1"
},
"pre-commit": {
  "silent": true,
  "run": ["lint"]
}
...

That’s it! Once, you commit the changes that you’ve made in app/, you should get a message like this one, that will kindly reject your commit and ask you to fix the problems.

Ruslans-MacBook-Pro:eslint ruslan$ git commit -a -m 'message'

/Users/ruslan/www/playgroud/eslint/app/index.js
  1:5  error  'value' is assigned a value but never used  no-unused-vars

✖ 1 problem (1 error, 0 warnings)

Notes

  1. If you’re using es6 / es7 features in your project, don’t forget to install babel-eslint and specify the correct parser in your .eslintrc file:
...
"parser": "babel-eslint"
...
  1. Since, ESLint can automatically correct some problems in your code, I would definitely recommend Sublime users to have ESLint-Formatter plugin installed.

Thanks for reading!