Prior to the beginning of my time at HPE working on OpenStack, I have to admit I hadn’t really heard of EsLint. Sure, I had used JSLint and JSHint in the past, and I had sort of accepted that JSHint was good enough for what I was using and focused my brain attention elsewhere. Looking back, I wish I had heard of ESLint earlier and saved myself some headaches from the past! So, I’m getting ahead of myself. Let’s start at the very beginning, a very good place to start (as the Sound of Music song would advise) and look at what linting actually is. Disclaimer: I might have binge watched some old musicals last weekend…
What is linting and why should I lint my code?
In short, linting is used to find inconsistent or undesirable code in a project. By linting your code you can catch bugs early, avoid potential mistakes, and keep your code clean. This is particularly useful in a large team environment as it means no matter what your coding habits and background, the written code should all look similar to everyone else’s who are writing by the same coding rules. Pretty awesome on projects no matter how big or small as one day someone else is going to have to come along and make sense of that code. That will be one heck of a lot easier if there is one main code style across the codebase as opposed to several styles and little to no consistency.
So I explained earlier how I used to use JSLint in the past. Indeed there are a few commonly used linters out there. The main ones I will mention here are JSLint, JSHint and ESLint. Yes, they are all linters, and as such they do all have similar goals. However there are some key differences when it comes to the configuration.
JSLint was originally created by Douglas Crockford and, by enforcing JSLint in your project you were enforcing the rules that came along with it with a fairly limited set of configuration options. While this is great if you want a simple setup and go solution with standardised linting and leave it at that, a lot of people, myself included, want a bit more flexibility than that and to choose what rules to enforce and which to leave open.
That is where JSHint came in. Anton Kovalyov forked off JSLint, added some awesomeness, and voila, a linter that lets you configure the settings to suit your project requirements.
Awesome, I hear you say, now where does ESLint come into all this? JSHint covers most use cases, but it can’t possibly cover them all out of the box. ESLint was written completely differently to allow you to easily create your own rules from scratch and have things exactly as flexible (or inflexible) as you want. Thank you Nicholas Zakas!
How do I install ESLint?
First and foremost, to run ESLint on Node.js, ensure you have installed npm. If npm is not installed, follow the instructions at https://www.npmjs.com/
You can then either install ESLint either globally or locally to the individual project. NPM recommends installing it locally if you want to include ESLint as part of your project’s build system (https://www.npmjs.com/package/eslint).
Installing ESLint locally
# Install eslint locally to the root of the project: npm install eslint --save-dev # Create the configuration file: ./node_modules/.bin/eslint --init # run ESLint on any file or directory: ./node_modules/.bin/eslint filename.js
Installing ESLint globally
# install globally npm install -g eslint # create global config file eslint --init # run ESLint on any file or directory: eslint filename.js
After running the init command (see above), an .eslintrc file will be created in your directory. In it, you’ll see some rules preconfigured. The format of the configuration is firstly the names of rule being confugured followed by the error level of the rule that can be one of the following:
“off” or 0 – turn the rule off
“warn” or 1 – turn the rule on as a warning
“error” or 2 – turn the rule on as an error
These levels allow you complete control over how ESLint applies rules for your project.