Linters are tools that analyze source code to detect problems based on formatting rules and code quality rules then output as warnings or errors. They are used to increase code quality, configured manually, and run automatically when code changes.
JavaScript, being a dynamic and loosely-typed language, is especially prone to developer error. Without the benefit of a compilation process, JavaScript code is typically executed in order to find syntax or other errors. Linters allow developers to discover problems with their JavaScript code without executing it.
Even though JavaScript compilers or static type checkers have evolved to include many of linting functions, linters have also evolved to detect an even wider variety of suspicious constructs — warnings about syntax errors, uses of undeclared variables, calls to deprecated functions, spacing and formatting conventions, misuse of scope, implicit fallthrough in switch statements, or missing license headers.
Linters parse and inspect source code, and then analyze the code’s syntax and structure. If any code violates the rules defined by the linter a warning is shown. The warning explains what part of the code might lead to unexpected behavior and why.
Linters are often built with 4 core components with different degree on customization and opinionated rules:
Linter Parsers — to parse different flavors of JavaScript source code and output AST for next steps
Linter Rules — the core of linters, often come with opinionated recommended presets; the ability to customize linting rules differs from linter to linter.
Linter Plugins — are npm modules to provide additional features and processors
Linter Formatters — linters often come with built-in formatters to control the appearance of the linting results, and also supports third-party formatters as well.
Linters can be integrated into editors (VSCode, Vim, Sublime Text, …), built tools (Gulp, Grunt, Webpack, …) or standalone as command line tools.
Popular JS linters are ESLint, JSHint, JSLint, and StandardJS.
ESLint is an open source project originally created by Nicholas C. Zakas in June 2013. Its goal is to provide a pluggable linting utility for JavaScript.
ESLint supports JSX, making it very popular with the React community. ESLint is superior for its ability to detect problems and has more rules available than other linters. While it does require configuration, ESLint has many presets available that make getting started a breeze.
ESLint is designed to be completely configurable, meaning you can turn off every rule and run only with basic syntax validation, or mix and match the bundled rules and your custom rules to make ESLint perfect for your project. You can configure ESLint via configuration comments or configuration files.
Here’s an example .eslintrc.json file:
{
"parserOptions": {
"ecmaVersion": 6,
"sourceType": "module",
"ecmaFeatures": {
"jsx": true
}
},
"rules": {
"semi": "error",
"curly": "error",
"quotes": ["error", "double"]
}
}To configure rules inside of a file using configuration comments, use a comment in the following format:
/* eslint semi: "off", curly: "error" */ESLint includes industry standard, open source style guides and linting rules that can be applied to any project. Too much customization makes it harder to just pick up and start using. How to setup and use ESLint is outside the scope of this post.
StandardJS is an opinionated JavaScript style guide, linter, and formatter. It has three core features: no configuration needed, automatically format code and catch style issues & programmer errors early. Adopting standard style means ranking the importance of code clarity and community conventions higher than personal style. It is available both as npm package and text editor plugins.
No configuration — The easiest way to enforce code quality in your project. No decisions to make. No .eslintrc files to manage. It just works.
Automatically format code — Just run standard --fix and say goodbye to messy or inconsistent code.
Catch style issues & programmer errors early — Save precious code review time by eliminating back-and-forth between reviewer & contributor.
StandardJS supports the latest ECMAScript features. However, Flow and TypeScript add new syntax to the language, so they are not supported out-of-the-box.
To support JavaScript language variants, standard supports specifying a custom JavaScript parser as well as an ESLint plugin to handle the changed syntax. Before using a JavaScript language variant, consider whether the added complexity is worth it.
StandardJS is a great option for those of you looking for a quick and reliable way to get started with a JavaScript linter.
JSLint is highly opinionated and based on Douglas Crockford’s Javascript: The Good Parts, super easy to just start using, but does not provide enough customization.
JSLint is a great option. It is particularly effective for testing snippets of code or if you’re looking for a way to quickly lint small projects.
JSHint comes loaded with sensible defaults, highly opinionated, allows for a lot more configuration than JSLint, provides the perfect blend of ease and functionality.
JSHint is completely configurable and it also exposes an API, meaning it can be used as a JavaScript module in your own JavaScript files.
JSCS has merged with ESLint!. Originally JSCS is a code style linter and formatter for your style guide. ESLint and JSCS started out at roughly the same time, just three weeks apart in 2013.
Both teams had a similar idea: leverage the ecosystem of ESTree-compatible tools such as Esprima to create the next generation of static analysis tools for JavaScript.
While ESLint’s primary goal was to create a linter with pluggable rules, JSCS’s primary goal was to codify style guides for easy verification and fixing.
By incorporating a linter tool into your project, you will have a better and more consistent code, getting rid of some annoying refactor tasks and ultimately optimizing the code style and useless diffs in commits.
You may get frustrated while using linters but you’ll get a lot of benefits by using them in the right way. They each have their pros and cons but ultimately serve the same purpose for ensuring code quality and consistency.
Personally after testing some of the above linters, I highly recommend using ESLint which I found very flexible, easily integrate with IDEs to add compiler-like benefits.