Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

How to Add ESLint to Your Project

DZone's Guide to

How to Add ESLint to Your Project

Learn how to add ESLint to your project, and find all the errors in your code quickly. Hopefully it's less than the number this DZone MVB found.

· Web Dev Zone
Free Resource

Add user login and MFA to your next project in minutes. Create a free Okta developer account, drop in one of our SDKs to your application and get back to building.

In another article, I wrote about how fun it was to add linting to a 3-year-old project, discover 856 errors, give up immediately, and downgrade all errors to warnings so I can sleep at night.

2% error rate per line of code – 2 lines with problems for every 100 lines of code – is disheartening as hell. But you know what? You can’t fix a problem you don’t know you have.

By the way, here’s how you count them:

> webpack --config=webpack.config.js | grep problems > problems.txt

This gives you a file full of lines like 18 problems (0 errors, 18 warnings). One line for each file with linter issues. 175 of those in my case.

If your Bash is as bad as mine, you can count the problems with one line of Python. Like this:

// throwaway.py
import re

print sum(int(re.search('\d+', line).group(0)) for line in open('problems.txt'))


Iterate file line-by-line, extract the first number of each line, turn it into an integer, sum. Isn’t Python great? This would be hell to do in JavaScript.

In my case, this prints 856. I hope you get less!

So, how do you get that evil mean output that says your code’s no good when running Webpack? There are 3 steps:

  1. Install some npm packages.
  2. Add 5 lines to Webpack.
  3. Get a sensible .eslintrc config file.

1. npm Packages

It’s 2017, so I’m going to assume you’re using ES6 to write your code. Even if you aren’t, empowering ESLint to understand modern JavaScript can’t hurt.

The packages you need are eslint, babel-eslint, and eslint-loader.

> npm install --save-dev eslint babel-eslint eslint-loader


This installs the packages and saves them as devDependencies in your package.json file. If you’re using Heroku, you have to set them as normal dependencies with --save. Otherwise, your Webpack build will fail when deploying to Heroku because Heroku doesn’t install dev dependencies.

That’s always fun to re-discover.

2. 5 Lines of Webpack Config

Let’s assume you’re already using Webpack and have a config going. To add ESLint to your build step, add these lines to that config:

// webpack.config.js
module: {
        loaders: [
            // ...
            {
                test: /\.js$/,
                include: [
                    path.resolve(__dirname, PATH_TO_YOUR_CODE)
                ],
                loader: 'eslint',
                exclude: /node_modules/
            },
            1
            // ...
        }


For every file in include paths that ends with .js, use the eslintloader. The exclude setting might be unnecessary, but I like to add it out of habit.

Yes, the best place to put this is in loa1ders. Not preLoadersand not postLoaders.

Logically speaking, it fits best in preLoaders, doesn’t it? You’d want to run the linter before doing any other transformation. That’s why it can’t go in postLoaders.

That caused strange errors for me that took … cough … hours to figure out. When you use the bang syntax to specify loaders in require() calls, eslint gets confused and constructs file paths that do not exist.

The easiest solution is to use it as a part of normal loaders. Ordering matters.

If I switch places and put eslint before babel-loader, Webpack spits out 883 errors in 178 files. 27 more errors in 3 more files.

I will pretend I didn’t see that.

3. A Sensible ESLint Config

Now, the fun part -> ESLint config in .eslintrc. There are many files out there with varying degrees of annoyingness.

You can use AirBnB’s ESLint config, which I’ve heard is annoying and makes you feel dirty.

@Swizec I tried the airbnb ruleset. Threw so many errors I just disabled it. I felt so dirty…

— Jonas (@JonasBadalic) August 28, 2016

Then there’s Google’s ESLint config, which I haven’t heard anything about. It does have a lot of downloads though.

Or the option that would make me feel all warm and fuzzy: my battle untested base config. It’s designed to annoy you, but not too much. It’s based off of Code Climate’s config with all errors turned into warnings.

My favorite feature is that it lists all available options, so, in theory, it’s easy to fine-tune. I can already tell that we’ll have to crank up some of the styling rules and tune down some of the “potential error” rules.

Now… how do I get team to buy-in?

Launch your application faster with Okta’s user management API. Register today for the free forever developer edition!

Topics:
web dev ,linting ,npm ,webpack

Published at DZone with permission of Swizec Teller, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}