First, the links:
Where we are
Today's place: Yosemite National Park
Linting our Build
Implement linting (we’ll use ESLint) in our build process.
Linting enhances our ability to catch bugs before they reach production.
As a preface, it's highly likely you already have a linter installed in your editor. While inline-linting is absolutely useful and recommended, adding it to our build cycle makes it a bit more official, and forces us to play by the rules. I prefer ESLint because it is pluggable, highly configurable, and doesn’t promote any particular coding styles. I encourage you to read more about ESLint’s philosophy.
So how do we add ESLint to webpack? You guessed it – another loader.
> npm install eslint-loader –-save-dev
We’ll add it to webpack.config.js just like any other loader – but using a new option pre, which will ensure ESLint gets run on our code before webpack does any transformations.
Side note: You’ll notice I configured eslint-loader to output a report file (which contains all the broken rules). This is useful, but after going through the process I’d recommend just doing this via the command line so you don’t need to involve the rest of the build process just to find/fix the cacophony of rules your app will be breaking if this is the first time you’ve implemented a linter.
One of the most amazing features of ESLint is its ability to automatically fix some issues. The Rules page on the ESLint website has a wrench icon next to the rules that can be auto-fixed.
Crowdsource Reporter didn’t have any linting before, so I added an .eslintrc file to tell both my editor and webpack which rules to follow, then ran eslint from the command line to see what I was working with. Here is what my .eslintrc looks like.
> eslint -o ./temp/eslint-log.html
17,167 problems reported. Wow.
That’s kind of a shocking number – but chill... the vast majority of those are because the original developers simply had a different preference when it comes to indent-style and quote-style. Luckily, both of those are auto-fixable. Let’s run eslint again, but use the --fix flag.
> eslint --fix -o ./temp/eslint-log.html
187 problems reported. Talk about efficiency!
Most of the remaining errors break these 3 rules:
At this point, you must decide what it means to “fix” these remaining issues. In the case of Crowdsource Reporter, it was a mix of manually fixing some things (like when modules were being imported but are never actually used), or simply relaxing my ESLint rules a bit (like saying it’s okay to use $ as a global, and it’s okay to handle errors with console.warn and console.error). I relaxed those rules by modifying my .eslintrc.
I probably could have spent more time standardizing the codebase by applying more rules – but that was outside the scope of this exercise.
Now that we have a clean slate with no errors being reported, let’s modify our webpack.config.js again.
With that, we stop outputting a report on every build, and tell Webpack that the build should fail if an ESLint error is reported.
So now that we've added a layer of error-checking to our build/deployment process, let's push on to the 6th part of the series where we'll focus on user and developer experience - UX and DX: The Best of Both Worlds.