; Date: Thu Dec 21 2017

Tags: Node.JS

With eslint, coders can save a lot of time (in theory) by checking code for simple (but hard to find) errors. Take a function where you typed one parameter name, and used a different name, and then your unit testing did not touch that function. You'll find that error after a customer reports a bug. With eslint such an error can be caught before shipping the code.

We'll do a quick "how to set up" post focusing solely on a Node.js module.

Home page: https://eslint.org/

Installation - at the root directory of a Node.js project:

$ npm install eslint --save-dev

This will obviously add eslint as a devDependency in the package.json. Not so obviously, it will install the eslint command in node_modules/.bin and you can get a usage statement with:

$ ./node_modules/.bin/eslint

It's recommended that you add ./node_modules/.bin to your PATH so that you can run eslint without typing the full path.

You can initialize a configuration file using:

$ eslint --init

The file will land as .eslintrc.yml and this file instructs eslint on what to do to check your project. For the project I tried this out for, a simple Node.js package that uses a few ES6/7 constructs including async functions (but not ES Modules), this is the configuration I ended up with:

env:
  browser: false
  node: true
  commonjs: true
  es6: true
parserOptions:
  ecmaVersion: 8
extends: 'eslint:recommended'
rules:
  indent:
    - error
    - 4
  linebreak-style:
    - error
    - unix
  # quotes:
  #   - error
  #   - double
  semi:
    - error
    - always

The env section describes some high-level facts about how this package is to be run. It's environment in other words. In this case we've told eslint this is Node.js code using CommonJS modules, that it will not be run in the browser, and that it uses ECMAScript 2015/2016 constructs. Further, the parser is told to look for ES-2017/2018 constructs - because the code uses async functions.

For example turning on the env.node feature allowed it to recognize process and console as global variables that did not need to be declared anywhere.

The extends clause lets you reuse a package of rules, in this case the recommended rules from eslint.

The settings in the rules section further tune how you want your code to be checked. The rules shown here are stylistic in nature, and would be a way to enforce code style guidelines. Notice that I turned off the quotes rule because it gets picky about using only one style of string quoting whereas I switch back and forth between the three types (single-quote, double-quote, and backtick) freely.

A full set of rules is here: https://eslint.org/docs/rules/

You can also define rules in-line with a comment like: /*eslint quotes: ["error", "double"]*/ That rule is equivalent, because it has the same object structure, to the rule shown in the YAML above.

Another thing I found necessary was temporarily disabling a rule for certain code segments. Suppose you know something is acceptible that eslint see's as an error. Do this:

/* eslint-disable no-console */
rd.on("error", function(err) {
    console.error('WARN: createReadStream '+ err);
});
/* eslint-enable no-console */

This, and other configuration details, are here: https://eslint.org/docs/user-guide/configuring

Automation

In package.json try this:

"scripts": {
    "lint": "eslint index.js cli.js"
},

And then you can do:

$ npm run lint

> globfs@0.3.1 lint /Users/david/nodejs/globfs
> eslint index.js cli.js

Taking that to the next level, one must verify the code is clean before publishing to the npm repository. Yes? Of course? We do test our code before publishing?

"scripts": {
    "lint": "eslint index.js cli.js",
    "prepublishOnly": "npm run lint"
},

With that in place, and with a carefully inserted bug that causes eslint to complain, I get this on running npm publish:

$ npm publish

> globfs@0.3.1 prepublishOnly .
> npm run lint

> globfs@0.3.1 lint /Users/david/nodejs/globfs
> eslint index.js cli.js

/Users/david/nodejs/globfs/index.js
  232:12  error  Parsing error: Unexpected token furtz

✖ 1 problem (1 error, 0 warnings)

npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! globfs@0.3.1 lint: `eslint index.js cli.js`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the globfs@0.3.1 lint script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/david/.npm/_logs/2017-12-21T20_23_12_528Z-debug.log
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! globfs@0.3.1 prepublishOnly: `npm run lint`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the globfs@0.3.1 prepublishOnly script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/david/.npm/_logs/2017-12-21T20_23_12_554Z-debug.log

That was a lot of output - the bottom line is that eslint discovered a problem, and prevented the code from being published.

Removing the artificially-induced error:

$ npm publish

> globfs@0.3.3 prepublishOnly .
> npm run lint


> globfs@0.3.3 lint /Users/david/nodejs/globfs
> eslint index.js cli.js

+ globfs@0.3.3

Flow - a related tool

Flow ( https://flow.org/) is a related tool that uses code transpiling techniques to add runtime type checking for function parameters and perhaps some other features.