jpeterson-esristaff

How to Tame your Web App - Linting

Blog Post created by jpeterson-esristaff Employee on Mar 7, 2017
First, the links:

Crowdsource Reporter Repo: https://github.com/esri/crowdsource-reporter

My Migration Repo: https://github.com/jpeterson/crowdsource-reporter

 

Where we are

This is the fifth part in a seven-part blog series called How to Tame your Web App. Here’s where we are:

  1. The Plan
  2. ES6 and Modern Modules
  3. Module Bundling 101
  4. Module Bundling 201 - Optimization
  5. Linting (you are here)
  6. UX and DX: The Best of Both Worlds
  7. Legacy Support - coming soon

 

Today's place: Yosemite National Park

Header: Rainy day in Yosemite driving down Tioga Road from Tuolumne Meadows.

 

Half Dome

Half Dome, bathed in alpenglow

 

Linting our Build 

 

The Plan

Implement linting (we’ll use ESLint) in our build process.

 

The Reason

Linting enhances our ability to catch bugs before they reach production.

 

The Commits

https://github.com/jpeterson/crowdsource-reporter/pull/6/commits

 

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:

 

Grand Canyon of the Tuolomne

Tuolumne River, in the Grand Canyon of the Tuolumne

 

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.

{
  test: /\.js$/,
  enforce: 'pre',
  exclude: /node_modules/,
  use: {
    loader: 'eslint-loader',
    options: {
      failOnWarning: false,
      failOnError: true
    }
  }
}

 

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.

Outcomes