Justin Chmura

ESLint Using Gulp

By on

A while ago I wrote an article about using ESLint. Which for my money, does a better job of not only checking for syntax errors, but enforcing a style guide. So I figured I would write a quick complementary guide for ESLint using Gulp.

If you’re not familiar with ESLint, it’s JSHint on steroids. It’s extremely flexible, provides the most rules out of any linter, and has support for JSX. Which with the recent growth of React, makes it the defacto tool for linting React files. If your still using JSHint, definitely give ESLint a look.

As in the other article, I’m going to assume you have a knowledge of Node and NPM, as well as a little working knowledge of how Gulp works. If you don’t, definitely check out my getting started in Node series and the JSHint using Gulp article linked above.

Install Packages

ESLint does require a few more packages than JSHint. That’s mostly because they’ve separated all the various presets you want out into their own packages. If you want JSX support, that’s its own package, you want some experimental ES7 features, that’s its own package.

Really the minimum to get started it his:

npm install gulp gulp-eslint --save-dev

That will install Gulp obviously, but will also install the Gulp ESLint package which allows you to run the task using Gulp.

As mentioned before there’s other packages depending on what your doing but take a look at the ESLint documentation on what you’ll need. ESLint considers those to be plugins and allows extension of its abilities. For React development, the eslint-plugin-react package will be required.

Setting up the Task

Before I go into getting ESLint up and running, I’ll outline setting up a task to start linting your code. If you are familiar with Gulp already, this will seem straightforward.

const gulp = require('gulp');
const eslint = require('gulp-eslint');

gulp.task('lint', function () {
  return gulp.src([...])
ESLint Output

ESLint Console Output

The two that may look unfamiliar are the eslint.format() and eslint.failAfterError() . The first just formats the output to the console window. There’s ways to output the result to other places if you need it, and it’s done with that method. Here’s a sample output from one of my projects:

failAfterError tells Gulp to not continue on if there’s any issues found. This is handy if you want to chain it with some other tasks. For instance, linting your code before concatenation to make sure no issues get into the final product.

Configuring ESLint

The key to ESLint it setting up the rules that it will apply to your code. With JSHint, those rules are already predefined so you’re stuck in with what they deem as proper JavaScript code. ESLint does have a set of standards, but those can be entirely up to you.

Not only is it entirely configurable, ESLint has support for ES6 features plus some ES7 features. Plus everything in between.

If you’re familiar with JSHint, then you know about the .jshintrc file. You put that in the same directory as your Gulpfile and JSHint will look for it to get its configuration from. Same rule applies to ESLint with the .eslintrc file.

Here’s an example of the baseline I use in some of my projects:

  "env": {
    "es6": true,
    "browser": true
  "extends": "eslint:recommended",
  "rules": {
    "no-console": ["error", { allow: ["warn", "error"] }]

The env section tells ESLint to make some assumptions when it starts looking at code. If you’re linting browser JavaScript, there’s going to be some assumed globals (window, document, etc). es6 is always a good flag to enable since that’s become the new language standard. There’s also a node flag in case you need to enforce the same rules on Node code.

I would suggest having two separate configs if you’ll be linting browser and server code. Having separate configs, which can be specified in Gulp, allows you to really hone in on what styles should be enforced where.

The extends gives you the ability to have a base ruleset, then override certain ones. In the example, I’m just using the recommended from ESLint.

Last section are your defined rules. I recommend going through the ESLint site and see what all the options are because they are numerous. I don’t mess with the recommended too much other than the one seen here. I’m treating a console.log as an error so that I don’t accidentally leave one. Warns and errors are ok in case I want to use those for actual errors.

Make the Switch

Adding ESLint to your development process is simple. Especially if you’re already in the JavaScript ecosystem of Node. JSHint is a good start but I’m starting to really enjoy ESLint’s thoroughness and extensibility.