In the SSP, we recently switched to using ESLint as our main JavaScript linting tool. This seemed like a sensible time to talk about linting in general, in JavaScript and why ESLint is the choix-du-jour at the moment.
Linting
Even if you’ve never seen or heard the word linting before, I can guarantee that you’ve seen one in action. I’m using one right now: a spell-checker.
A spell-checker (and much more so, a grammar checker) exists to try and identify problems in your text. It points out where you’ve typed something wrong, which you need to fix for your document to be correct. Your spelling and grammar errors may not make your text completely unreadable, but correcting them ensures that your document meets certain standards (the standards of the language you’re writing in).
Code linting works in exactly the same way: it highlights when what you’ve written doesn’t meet a set of standards. In the context of SSP JavaScript standards, I’m talking about our style guide. The style guide issues various didactic instructions about how code should be structured, formatted and documented, all for reasons of improving code quality and consistency. Here linting is the automatic process of checking those instructions have been passed.
You can implement a linter in various ways. It can be run from the command-line, or be built into your build process so that code won’t be shipped unless it passes the linting test. My favourite way to lint is in my text-editor. It means that you can catch problems as soon as they’re written, and be thinking about code quality all through development (not just when you’re ready to ship).
Benefits of linting
Linting comes with many benefits, and each individual rule provides its own merit. Many of the rules we lint for in JavaScript exist to ensure best practices are followed, such as checking that variables and functions are properly defined before they’re used. Browsers can often work around bad definition orders, which gives the illusion of it being correct. However, not only will some browsers trip up on poor ordering, but so will future developers when they try to work with your code.
We can also use linting and style guides to enforce sensible and consistent formatting, like whether if statements should ever be one-liners. These can seem trivial and nit-picky (particularly if you like your particular coding style!), but they make it much easier for all developers to quickly parse documents without having to ask “what is this supposed to do?”. If you’ve ever come across code written by fans of ternary operators, you’ll know what I mean.
var foo = bar ? baz : qux === quxx ? bing : bam;
As well as stopping us making silly mistakes and enforcing coding best practices, linting can be used to ensure general good behaviour, like commenting your functions. It’s a coding Swiss Army Knife to improve the quality of your final output.
In many places throughout our style guide, we’ve tried not just to state what the rules are but also what problem they’re trying to solve.
A brief history of JavaScript linting
JavaScript has a rich history of linting dating back over fourteen years. Over time, linters have covered more options, got more configurable and been better documented.
The first linter was Douglas Crockford’s JSLint, first released in 2002. Following on from his seminal book JavaScript: The Good Parts, Crockford’s linter is based around his suggested customs. Whilst all coming from a good place, many find his suggestions to be overly strict (disallowing for, forcing 4 space indents).
In 2010, JSLint was forked into JSHint (whilst JSLint continued to be developed). The fork intended to allow more customisation possibilities so that developers had more freedom to determine their own set of standards.
Then, in 2013, JSCS emerged. Whilst JSHint focussed more on ensuring your code was free of mistakes and bad practices, JSCS set out to allow developers to easily enforce code style. JSHint without JSCS was ensuring your code was very stable. JSCS without JSHint was making sure it all looked the same.
ESLint
ESLint has been around since a similar time to JSCS, but didn’t hit version 1.0.0 until June 2015. Since then, it has quickly become a developer favourite and a standard choice throughout the industry. ESLint again blurs the line between code quality and code style, meaning that where previously JSHint and JSCS were used side-by-side, you now only need one tool. It comes with a myriad of rules, all of them off by default so (in stark contrast to the original JSLint) there is no “suggested style”.
ESLint also has great support for future versions of ECMAScript, allowing you to easily lint ES6 code and use additional rules specific to new features, making it helpfully forward-thinking. Alongside this, it is configurable, so you can easily add your own rules.
ESLint has really cemented its place at court with two recent developments. On April 14, the JSCS team announced that they were deprecating the project and moving to ESLint, citing that they would rather work together to create a unified tool than have two competing products trying to solve the same problem. A few days later, the jQuery Foundation announced that they were going to officially support ESLint going forward. This means that ESLint is no longer relying on individual maintainers, and will continue to be owned by the community rather than any big business.
ESLint has for a while felt like a stronger product but, with the endorsement from both their competitors in JSCS and the jQuery Foundation, it seems clear that it is the JavaScript linting tool to use today.
You can find the SSP style guide and ESLint rules file on our GitHub repository.