Key Takeaways
- JavaScript linting tools such as JSLint, JSHint, JSCS, and ESLint help to avoid mistakes in coding by adhering to a coding standard and identifying potential errors. Each has its own pros and cons, and the choice of tool depends on the specific needs of the project.
- JSLint is the oldest tool, created to enforce good parts of JavaScript. It’s not configurable or extensible and lacks documentation. JSHint, a fork of JSLint, is more configurable and easy to use in bigger projects, but requires some setup to make it useful.
- JSCS is a code style checker, focusing on code formatting rather than potential bugs or errors. It has over 90 different rules and supports custom plugins. However, it’s less flexible than the others and is the slowest of the four.
- ESLint is the most recent and extensible tool, with a large number of custom rules. It checks code for bugs and other problems, making it the author’s recommended choice. It supports ES6 features and JSX. However, its documentation can be confusing and some configuration is required.
A linting tool helps me avoid silly mistakes when writing JavaScript. Despite my many years of experience, I still type variable names incorrectly, make syntax errors and forget to handle my errors properly. A good linting tool, or a linter, will tell me about this before I waste my time—or worse, my client’s time. A good linting tool can also help make sure a project adheres to a coding standard.
There are many linters available for JavaScript, but how do you choose which one to use? Let’s take a look at both the features and the pros and cons of four popular alternatives: JSLint, JSHint, JSCS and ESLint.
Overview
The four tools work in the same basic way. They have a set of rules which they use to analyze and report problems in JavaScript files. They can be installed via npm. They are used from the command line by passing in files, are available as plugins for tools like Grunt, or are integrated into editors. They all support using comments for configuration.
But that’s where the similarities end. Each tool has its own pros and cons—it’s just that some have more pros than others.
JSLint
JSLint is the oldest of the four. Douglas Crockford created it in 2002 to enforce what, in his experience, are the good parts of JavaScript. If you agree with the good parts, JSLint can be a good tool—you install it and it’s ready to go.
The downsides are that JSLint is not configurable or extensible. You can’t disable many features at all, and some of them lack documentation. The official website is not very helpful, for example it lacks any information on how to integrate it with your editor.
Pros
- Comes configured and ready to go (if you agree with the rules it enforces)
Cons
- JSLint doesn’t have a configuration file, which can be problematic if you need to change the settings
- Limited number of configuration options, many rules cannot be disabled
- You can’t add custom rules
- Undocumented features
- Difficult to know which rule is causing which error
JSHint
JSHint was created as a more configurable version of JSLint (of which it is a fork). You can configure every rule, and put them into a configuration file, which makes JSHint easy to use in bigger projects. JSHint also has good documentation for each of the rules, so you know exactly what they do. Integrating it into editors is also simple.
A small downside to JSHint is that it comes with a relaxed default configuration. This means you need to do some setup to make it useful. When comparing it with ESLint, it’s also more difficult to know which rules you need to change in order to enable or disable certain error messages.
Pros
- Most settings can be configured
- Supports a configuration file, making it easier to use in larger projects
- Has support for many libraries out of the box, like jQuery, QUnit, NodeJS, Mocha, etc.
- Basic ES6 support
Cons
- Difficult to know which rule is causing an error
- Has two types of option: enforcing and relaxing (which can be used to make JSHint stricter, or to suppress its warnings). This can make configuration slightly confusing
- No custom rule support
JSCS
JSCS is different from the others in that it doesn’t do anything unless you give it a configuration file or tell it to use a preset. You can download configurations from their website, so it’s not a big problem, and it has a number of presets, such as the jQuery coding style preset and the Google preset.
It has over 90 different rules, and you can create custom ones with plugins. JSCS also supports custom reporters, which makes it easier to integrate with tools that need their input in a specific format.
JSCS is a code style checker. This means it only catches issues related to code formatting, and not potential bugs or errors. As a result, it’s less flexible than the others, but if you need to enforce a specific coding style, it’s a job JSCS does well.
Pros
- Supports custom reporters, which can make it easier to integrate with other tools
- Presets and ready-made configuration files can make it easy to set up if you follow one of the available coding styles
- Has a flag to include rule names in reports, so it’s easy to figure out which rule is causing which error
- Can be extended with custom plugins
Cons
- Only detects coding style violations. JSCS doesn’t detect potential bugs such as unused variables, or accidental globals, etc.
- Slowest of the four, but this is not a problem in typical use
ESLint
ESLint is the most recent out of the four. It was designed to be easily extensible, comes with a large number of custom rules, and it’s easy to install more in the form of plugins. It gives concise output, but includes the rule name by default so you always know which rules are causing the error messages.
ESLint documentation can be a bit hit or miss. The rules list is easy to follow and is grouped into logical categories, but the configuration instructions are a little confusing in places. It does, however, offer links to editor integration, plugins and examples all in a single location.
Pros
- Flexible: any rule can be toggled, and many rules have extra settings that can be tweaked
- Very extensible and has many plugins available
- Easy to understand output
- Includes many rules not available in other linters, making ESLint more useful for detecting problems
- Best ES6 support, and also the only tool to support JSX
- Supports custom reporters
Cons
- Some configuration required
- Slow, but not a hindrance
My Recommendations
My choice of these four is ESLint. JSLint is strict and not configurable, whereas JSHint is lacking the extension mechanism. JSCS is a good choice if you only want to check coding style, but ESLint does that and it checks your code for bugs and other problems as well.
ESLint is also the obvious choice if you want to use ES6 (or ES2015, as they seem to be calling it now). Of all the tools mentioned, it has the widest support for ES6 features.
If you want to try ESLint, I’ve made it really easy for you by creating a 5-step quick start guide. You can download the ESLint 5-step quickstart guide from my website.
JSHint is strong second choice. If you don’t need the advanced features of ESLint, JSHint catches a good number of issues once properly configured. JSCS, with its huge number of available rules, is a top pick if you don’t need anything other than coding style checks (indentation, braces, etc.).
I’m hesitant to recommend JSLint at all. The other tools do the same things, but don’t force any specific rules on the user. The only exception here is if you happen to agree with all the rules it enforces, in which case it might well be worth looking into.
A linting tool is a good step towards catching problems, but it only sees as many errors as its rules permit. For a more foolproof automated bug-catcher, I recommend using unit tests. Code reviews can also be useful for this purpose.
How do you and your team ensure the quality of your code?
Frequently Asked Questions about JavaScript Linting Tools
What are the key differences between ESLint, JSLint, and JSHint?
ESLint, JSLint, and JSHint are all popular JavaScript linting tools, but they each have their unique features and advantages. ESLint is highly customizable and supports the latest ECMAScript features. It also allows you to use your own custom rules. JSLint, on the other hand, is more rigid and doesn’t allow much customization. It enforces a strict coding style, which can be beneficial for maintaining consistency in large codebases. JSHint is a more flexible alternative to JSLint. It allows some customization and supports more ECMAScript features than JSLint.
How do I choose the right JavaScript linting tool for my project?
The choice of a JavaScript linting tool largely depends on your project’s requirements and your personal preferences. If you need a highly customizable tool that supports the latest ECMAScript features, ESLint would be a good choice. If you prefer a tool that enforces a strict coding style, you might want to consider JSLint. If you need a more flexible tool that still supports a wide range of ECMAScript features, JSHint could be the right choice for you.
Can I use multiple JavaScript linting tools in the same project?
While it’s technically possible to use multiple linting tools in the same project, it’s generally not recommended. Using multiple tools can lead to conflicting rules and can make your codebase more difficult to maintain. It’s usually better to choose one tool that fits your needs and stick with it.
How do I configure ESLint to use my own custom rules?
To configure ESLint to use your own custom rules, you need to create a .eslintrc file in your project’s root directory. In this file, you can define your own rules and configure ESLint to use them. You can also extend the base ESLint configuration and override specific rules as needed.
What are some common issues that JavaScript linting tools can help me avoid?
JavaScript linting tools can help you avoid a wide range of common issues, such as syntax errors, undeclared variables, unused variables, and inconsistent coding styles. They can also help you enforce best practices and maintain a clean, consistent codebase.
How do I integrate a JavaScript linting tool into my development workflow?
Most JavaScript linting tools can be integrated into your development workflow through a task runner like Grunt or Gulp, or through a module bundler like Webpack. You can also set up your text editor or IDE to run the linting tool every time you save a file.
Can JavaScript linting tools help me write better code?
Yes, JavaScript linting tools can definitely help you write better code. By enforcing best practices and helping you avoid common errors, these tools can improve the quality of your code and make it more maintainable. They can also help you learn more about JavaScript and improve your coding skills.
Are there any downsides to using JavaScript linting tools?
While JavaScript linting tools offer many benefits, they can also have some downsides. For example, they can sometimes be difficult to set up and configure, especially for large projects. They can also be overly strict and inflexible, which can be frustrating for some developers.
How do I handle false positives from my JavaScript linting tool?
If your JavaScript linting tool is flagging valid code as an error (a false positive), you can usually resolve this issue by adjusting your tool’s configuration. Most linting tools allow you to disable specific rules or adjust their severity.
Can I use a JavaScript linting tool with other programming languages?
While JavaScript linting tools are designed specifically for JavaScript, some of them (like ESLint) can also be used with other languages that compile to JavaScript, such as TypeScript. However, for other programming languages, you would typically use a different linting tool that’s designed for that specific language.
Jani has built all kinds of JS apps for more than 15 years. At his blog, he helps JavaScript developers learn to eliminate bad code so they can focus on writing awesome apps and solve real problems.