A linter is a piece of software that runs source code through a set of rules and then causes a stink if your code breaks any of those rules. On the one hand, this is intended to make code look consistent across a project, but on another, it flags up potential code issues while developing--particularly obvious mistakes, such as misnamed variables.

Linting rules are often based on industry best practices, and most open source projects have a customized ruleset corresponding to their community guidelines. This simultaneously ensures that code looks consistent even when delivered by a multitude of people, and also lets contributors know when they're doing something that's a little confusing or error-prone in their code. Note, however, that all of these rules are just opinions; you don't have to write your code following them, but it tends to help everyone else out if you do.

If you've been following along with the GitHub repo for this book, perhaps you've noticed a hidden file called .eslintrc, or noticed eslint in package.json. ESLint is the current best linter for ES2017 code, and it works very similarly to its predecessors: JSHint and JSCS. It's usually configured via the .eslintrc file, which both contains the specific rules to be checked against (or a set of defaults to extend--I'm a huge fan of Airbnb's configuration and use a slightly modified version of their ruleset throughout this book) and information about the code's environment (for instance, NodeJS has different global variables than the browser).

To run ESLint against the current project, type as follows:

$ npm run lint

Although there won't be any linting errors in the repo by the time this book gets to print, here's an example of how the output looked at this stage of the book:

What a lot of errors we have here!

We use npm to run eslint in this instance, which is effectively an alias for the following:

    $ node ./node_modules/.bin/eslint src/*.js

You can also install ESLint globally and then just run it anywhere.

Although this is helpful, linting is way more useful when you use it all the time during developing. Let's make ESLint scream at us while we're using webpack-dev-server. First, install eslint-loader:

    $ npm install eslint-loader --save-dev

Next, we add eslint-loader as a preloader to our Webpack config, so it runs on our code before Babel does its thing with it. In webpack.config.js, add the following in the module section of each build item:

module: {
rules: [
  {
    test: /.js$/,
    loader: 'eslint-loader',
    exclude: /node_modules/,
  },

Run webpack-dev-server:

$ npm start

Ta-da! Now you can get instant feedback about how messy your code is every time you hit Save! You're utterly thrilled by this, I can just feel it!

Linting is a very light way to manage complexity--generally, a linting failure won't necessarily cause anything other than a message to appear on the developer's screen. It's up to you and your team to maintain a sense of discipline in terms of not committing code until it passes linting. However, it's this lightness that makes it one of the easiest pieces of tooling to implement -- even if the rest of your team thinks linting is a godforsaken nuisance, you can still add an .eslintrc file to your home folder and get the benefits of having a linter yourself.