Linters
help you to analyse your code statically, i.e without actually even running it. This helps us:
- to catch the errors and pitfalls in the code far before doing the testing
- enforce style and coding practises so that, throughout the project, the conventions are strictly followed.
ESLint
ESLint is an open-source project originally created by Nicholas C. Zakas which provides a pluggable linting utility for JavaScript. It parses your code, analyses it and runs linting rules that may trigger warnings or errors to let you know if your code is right or wrong.
Installation
ESLint can be installed either globally or locally.
npm i -g eslint
or npm i -d eslint
It is better to install ESLint project-wise because it will save you from running into conflicts.
If you use VSCode, we can use the ESLint plugin which is really handy.
Configuration of ESLint
ESLint is highly configurable. We can do that either, using
- configuration comments
- configuration files
The second approach is easier and productive so we will explain that.
Configuration files
When using configuration files, it is entire project-specific. The configuration file can be a JSON, YAML or JS file. It is named .eslintrc.*
and placed at the root of the project. Or else it can go inside the package.json
files under the key eslintConfig
.
To create a configuration file you can run the command
npx eslint --init
// or
yarn run eslint --init
but make sure you have package.json
in the project root. If not you have to create one before running the init command.
Available options
The configuration files can take many options. A few of them are
-
parserOptions
: tells ESLint how you want it to parse your code. The available options are:-
ecmaVersion
: to specify the version of ECMAScript syntax you want to use. Fores6
syntax support we can use{ "parserOptions": { "ecmaVersion": 6 } }
, but for the latest keyword support we need to mention it using theenv
. By setting{ "env": { "es6": true } }
thees6
syntax support is enabled automatically. -
sourceType
: set toscript
(default) ormodule
if your code is in ECMAScript modules. -
ecmaFeatures
: an object indicating which additional language features you'd like to use. -
globalReturn
: enable globalreturn
-
jsx
: enablejsx
support -
impliedStrict
: enable global strict mode (version > ECMA5)
-
-
parser
: ESLint usesespree
by default as the parser. We can change it by passing aparser
option in the configuration. Even with a separate parser,parserOptions
are to be passed. The supported parsers are:- esprima
- babel-eslint
- @typescript-eslint/parser
plugins
: plugins are a set of ESLint rules related to some specific subject. As an example,eslint-plugin-react
contains many rules related to React. If needed theeslint-plugin-
prefix can be omitted from the plugin name.
{
// ...
"plugins": [
"jquery", // means eslint-plugin-jquery
"@jquery/jquery", // means @jquery/eslint-plugin-jquery
"@foobar" // means @foobar/eslint-plugin
]
// ...
}
Caution: you have to install the plugin as a dev
dependency for your rules to work properly.
processor
: some plugins may come with processors, which helps to extract JS code from other file types. Or it can also convert the JS code to other formats/types. more...env
: it is used to specify which environments your script is designed to run in. Each environment brings with it a certain set of predefined global variables. For example, when using testing tools like protractor, there are a few global keywords that are protractor specific. We can useenv
to enable them. To enable an env, just add it in the object with value as true and the environment as the key.
{
"env": {
"browser": true,
"node": true
}
}
-
globals
: if there are any user-defined global variables that are being accessed inside the script, that can go inside theglobals
.
{
"globals": {
"var1": "writable",
"var2": "readonly"
}
}
-
rules
: which rules are enabled and at what error level. Following are the error levels available:
-off
/0
- turn the rule off
-warn
/1
- turn the rule on as a warning (doesn't affect exit code)
-error
/2
- turn the rule on as an error (exit code is 1 when triggered)
Ignoring files and directories
In order to ignore files from getting linted, we can do it either by creating an ignorePatterns
field in the configuration or by creating a .eslintignore
file in the project root.
Top comments (2)
This. Definitely this. I would argue this over automated testing, not that I'm saying you shouldn't do testing, but if you just don't have the time (or other factors) at the very least by using a linter you will improve your code quality.
Spot on. I never write test cases. βΊοΈ