JavaScript linting and ESLint


This post is about what is a linter, why I use ESLint over others and how I use it. Do not expect a getting started or a configuration guide, there are the official guides for that.

What is a javascript linter?

By definition (wikipedia),

“A linter is any tool that flags suspicious usage in software written in any computer language”

And the definition continues…

In compiled languages (like Go, Haskell, etcetera) is easier (with the compiler) to find syntax errors, variables typed incorrectly, common errors and so on.

But in interpreted languages like JavaScript you have not a compiler and the error is thrown at runtime, many times silently, and others you will never realize (for example, bad practices).

In summary, a linter gives you:

  • It prevents bugs (some of them critical).
  • Makes your code safer and better.
  • Helps you learning better code.
  • Maintain code quality. In some cases, like ESLint also can maintain a certain code style.
  • Saves you a lot of time.

Why I use ESLint over others?

Actually, for my requirements and necessities, the best option now a day is ESLint. But doesn’t mean ESLint should be the best one for you and your necessities. There are others like JSLint, JSHint or JSCS (actually JSCS is merged with ESLint).

I started using JSHint as my first linter (a long time ago). Then, I combined with JSCS (in a build process) to maintain style (vital when you work in a team).

Since 2014, I discovered ESLint, and it fits perfectly to my necessities, better than any other. To me the pluggability is the key to match with many different approaches and workflows, the description of the ESLint says:

“A fully pluggable tool for identifying and reporting on patterns in JavaScript.”

There is a good comparison article by Jani Hartikainen that explains (among other things) the pros and cons between the linters mentioned above.

Using ESLint

ESLint can be used in many ways, here the official integrations pages as an example.

I think, the best way is to integrate it with a build system (webpack in my case) as part of your workflow.
Gives the project consistency making the developers agnostic on how to run ESLint, having it always as a parachute (because every time you build your code ESLint will lint it).
When you are used to this approach, trust me, doesn’t want other.

I also recommend configuring ESLint over the configuration file (.eslintrc), is very clear where the rules are setted.

Several pieces of information can be setted on that file, I will spotlight the most important to me:

  • Environment: which environment your script will be run.
  • parserOptions: specify JavaScript language options (ECMA version, sourceType, etcetera).
  • Plugins: ESLint support third-party plugins.
  • And obviously rules.

Additionally, you can extend from other configuration files, very useful functionality. If you are new to ESLint a pretty good start point extends from "eslint:recommended".

I highly recommend you take your time in the official configuration user guide. Is very well explained, also the rules page is going to be your new best friend.

References:

A Comparison of JavaScript Linting Tools
Wikipedia - Lint ESLint web page