How to do it…

Linters are a class of programming tools that analyze your source code, and raise warnings and errors about poor-quality uses or constructs that could even imply bugs. We are going to use ESLint, created by Nicholas Zakas in 2013; the tool's current version is 5.10.0, as of December, 2018.

The first lint program was written in 1978 by Stephen Johnson, at Bell Labs, where he also worked on Unix, yet another compiler compiler (yacc), and the portable C compiler, which made it easier to output code for different computer architectures.

ESLint is based upon pluggable rules, which may be enabled or disabled at will, or configured according to your specific preferences. (You could even develop your own rules, but that's beyond the scope of this book.) There are also bundles of rules that let you avoid having to individually configure dozens of distinct rules.

Installing ESLint is quite simple, and just requires doing the following:

 npm install eslint eslint-config-recommended --save-dev

Then, you will have to add ESLint options to the package.json configuration file; let's get into this. First, we'll add a script to apply ESLint to our complete source directory (which has only a single file at this time!) with npm run eslint:

"scripts": {
"build": "babel src -d out",
"eslint": "eslint src",
"test": "echo "Error: no test specified" && exit 1"
}

We must also specify some configuration for ESLint itself. We'll add a completely new section for this:

"eslintConfig": {
"parserOptions": {
"ecmaVersion": 2017,
"sourceType": "module"
},
"env": {
"browser": true,
"node": true
},
"extends": "eslint:recommended",
"rules": {}
}

Let's go item by item:

  • parserOptions lets you specify what JS version you want to process (I'm going with 2017, for ES8), and whether you are going to use modules (I'm indicating this, in advance of what we'll see in the Organizing code in modules section of Chapter 2, Using Modern JavaScript Features).
  • env lets you specify the environment(s) you are going to work with, and that really means that some global variables will be assumed to exist. In this case, I'm saying I will be working both with code for browsers and for Node, but there are plenty more possible environments; checkout the Specifying Environments section at https://eslint.org/docs/user-guide/configuring. Later on, we will be adding some more environments, for example, for unit testing.
  • extends lets you select a predefined set of rules, which you will later be able to modify to suit your tastes. I'm going with the recommended set; you can read more about it at https://github.com/kunalgolani/eslint-config. The available sets of rules change only whenever the ESlint major version changes, so they are reasonably stable. Furthermore, the recommended set represents a usually agreed upon list of rules, so before you start tinkering with specific changes, give it a try as is. The complete set of rules is available at https://eslint.org/docs/rules/, and the recommended rules can be found at https://github.com/eslint/eslint/blob/master/conf/eslint-recommended.js.
  • rules lets you change some of the rules to better suit your style. We'll see good reasons for this soon.
If (and only if) you are planning to use some Babel feature that is not yet supported by ESLint, you should install and use the babel-eslint package from https://www.npmjs.com/package/babel-eslint. This will also require adding a line to the .eslintrc.json file to change the parser that ESLint uses. However, keep in mind that it's highly unlikely you will require this change!

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.118.152.58