Welcome to Part 8 of this review of the Pluralsight course “Creating a JavaScript Development Environment” by Cory House.

Cory is a Microsoft MVP in C#, founder of OutlierDeveloper.com, avid tech reader, and speaker.

He believes in clean code, pragmatic development, and responsive native UIs.

He has also created reactjsconsulting.com, and has the authored Pluralsight courses including Building Applications with React and Flux and Building Applications with React and Redux in ES6.

Also in this series:
Part 1 – You Need a Starter Kit
Part 2 – Editors and Configuration
Part 3 – Package Management
Part 4 – Development Web Server
Part 5 – Automation
Part 6 – Transpiling
Part 7 – Bundling
Part 8 – Linting
Part 9 – Testing and Continuous Integration
Part 10 – HTTP Calls
Part 11 – Project Structure
Part 12 – Production Build
Part 13 – Production Deploy

Linting

This jumped out at me as a particularly important subject.
Although there are massive benefits in using a linter, there are a ton of decisions that come along with it.
Up until now there has been a lack of guidance on which decisions we should make, putting developers at risk of wasting a lot of time instead of being productive.

Why Lint?

We use a linter to enforce consistency and to avoid mistakes. Cory provides many examples of each of these.

Linters

Cory mentions JSLint, JS Hint, ESLint and TSLint in this lesson. He generally recommends using ESLint.

ESLint Configuration Decisions

There are a lot of decisions:

1. Config format?
2. Which built-in rules?
3. Warnings or errors?
4. Which plugins?
5. Use preset instead?

Decision 1: Configuration File Format

ESLint supports the following formats:

– JavaScript (eslintrc.js)
– YAML (.eslintrc.yaml or .eslintrc.yml)
– JSON (.eslintrc.json)
– Deprecated (.eslintrc)
– package.json (using a eslintConfig property)

If you are already using NPM, the easiest thing to do is to add an eslintConfig into your existing package.json

Decision 2: Which Rules?

The ESLinter rules are subjective and different developers will have different opinions on which rules should be enforced or not.
For this reason Cory does not state which rules to use here, instead recommending you organise a meeting with your team to reach agreements.

Decision 3: Warnings vs Errors

Cory discusses the pros and cons of a rule raising a warning vs raising an error.

Decision 4: Plugins?

Some popular plugins are:
eslint-plugin-react
eslint-plugin-angular
eslint-plugin-node

Cory recommends checking out github.com/dustinspeacker/awesome-eslint to learn more.

Decision 5: Use a Preset?

If all the previous decisions feel overwhelming then you can just choose a preset.

ESLint has a recommended preset. I have found this is a good starting point and you can adjust the settings from here as best meet your needs.
Cory has also found the same works well for him.

Other popular Presets are available from airbnb, XO and “standard JS”

Watching Files with ESLint

Cory warns that ESLint doesn’t watch files. By default, you run ESLint by typing the command into the command line.
This isn’t a great development experience and having it run automatically on save is much better.

He discusses to options to achieve this:

1. eslint-loader
2. eslint-watch

eslint-watch is not tied to webpack and has other advantages that Cory describes here.

Linting Experimental Features

ESLint doesn’t support many experimental JavaScript features. If you find this is a problem, you can use Babel-eslint.

Why Lint via an Automated Build Process?

Cory explains this gives us just one place to check, universal configuration and most importantly continous integration.

Demo: ESLint Set Up

In this demo Cory sets up ESLint using the ESLint recommended preset and adds eslint-watch.

You can find the rules at https://gist.github.com/coryhouse/61f866c7174220777899bcfff03dab7f
Make sure that you watch this lesson if you don’t already understand what these rules mean because Cory explains them all and shows us how to override the rules.

Next we see how to update package.json to call es-watch.

We run the linter on the command line:

> npm run lint

And we see the errors returned due to use of console.log. We see how we can disable the rule where we feel it is a rare exception to the rule.

Demo: Watching Files

eslint-watch does not watch our files by default. To get it to watch our files we add another rule to the scripts section in our package.json file.

Then in the command prompt we type:

> npm run lint:watch

ESLint will now run every time we save one or more of our JavaScript files.