How to add ESLint to your project
Yesterday, 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 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:
- Install some npm packages
- Add 5 lines to Webpack
- Get a sensible
.eslintrcconfig file
1. npm packages
Itās 2016, 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, 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/
},
// ...
}
For every file in include paths that ends with .js, use the eslint loader. The exclude setting might be unnecessary, but I like to add it out of habit.
Yes, the best place to put this is in loaders. Not preLoaders and 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.
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 buy-in? ?
Filed under: FrontendTechnical

