Comparison of JavaScript inspection tools

The author is Jani Hartikainen, English good classmate directly read the original text. Original

When writing the JS code, a verification tool can help me avoid stupid mistakes. Although I have many years of experience, I still have variables that are named incorrectly, produce grammatical errors, and forget to handle errors correctly. A good calibration tool or validator can tell me these questions before I waste time, especially customer time. A good validation tool ensures that a project follows the code specification.

There are four JS validators that can be used, but how do you choose which one to use? Next, let's look at the features, advantages and disadvantages of these four popular options: JSLint, Jshint, Jscs, ESLint.

Overview

The four tools work in the same basic way. They have a set of user analysis, report JS file error rules. They can all be installed via NPM. They can be used from the command line, used as grunt plug-ins, or integrated into the editor. All four of them support the use of annotations for configuration.

But the similarities are over. Each tool has its own advantages and disadvantages – The advantages are obtained by comparison.

JSLint

JSLint is one of the oldest tools. In 2002 Douglas Crockford developed the tool, which, based on its experience, enforces the use of the pristine parts of the JS language. If you agree with these essences, JSLint can be a good tool.

The disadvantage of jslint is that it cannot be configured and expanded. You simply cannot ban the need for features, and many lack documentation. Official documents are very unfriendly, such as the lack of information on how to integrate them into your edits.

Advantages

• Parameter configuration is complete and can be used directly

Disadvantages

• JSLint There is no configuration file, if you want to change the parameter settings, there is a problem
• Limited configuration options, many rules cannot be banned
• Cannot add personalization rules
• No document record rule
• It's hard to figure out which rule caused the error.

Jshint

As a configurable version of JSLint, Jshint was developed. You can configure each rule to put it in a configuration file, which can be easily used in large projects. Jshint has good documentation for each rule, so you know exactly what each rule does. It is also easy to integrate it into the editor.

A small drawback of jshint is the loose default configuration inside. That is, you must start it before making it available. Jshint is more difficult to determine which rule users can turn error messages on or off, compared to Eslint.

Advantages

• Most of the parameters can be configured
• Support configuration files, easy to use in large projects
• Supports the need for class libraries like jquery, Qunit, NodeJS, mocha, etc.
• Support for basic ES6

Disadvantages

• It is difficult to know which rule produces errors
• There are two types of options: Mandatory options and loose options. Make the configuration a little confusing
• Custom rules are not supported

Jscs

Jscs differs from the others, because if it is not given a profile or tells it a configuration item, Jscs
Won't do anything. Can save their site now configuration items, so this is not a big deal, and there are many configuration items, such as jquery code style configuration items, Google config items.

It has more than 90 different rules, and you can create custom rules through plugins. Jscs also supports custom reporting, which makes it easy to integrate with other tools that require a specific format.

Jscs is a code style checker. This means that it only matches the problem of the code format and does not match the potential bugs, errors. As a result, there is less flexibility than other tools, but Jscs is also a good tool if you just force check the code style.

Advantages

• Support custom reports for easier integration with other tools
• If you follow an available code style, configuration items and ready-made profiles make it easy to start
• There is a tag inclusion rule name in the report, so it's easy to point out which rule caused the error
• Expand with Custom plugins

Disadvantages

• Just check the code style for the problem. Jscs does not check for potentially existing bugs, such as non-applicable variables, accidental global variables, etc.
• The slowest of the four tools, but not an issue in use

ESLint

Eslint is the newest tool. It is designed to be easy to expand, has a large number of custom rules, easy to install through the plug-in. It gives the exact output, and includes the rule name, so you know which rule caused the error.

Eslint documentation is somewhat confusing. Rules are easy to find and are grouped into logical groups, but configuration guides are easy to mix in some places. However, it can provide links in one place to edit integrations, plugins, and examples.

Advantages

• Flexible: Any rule can be turned on and closed, and some rules have some additional configuration
• Easy to expand and have the necessary plugins available
• Easy to understand output
• Contains rules that are not available in other inspectors, making eslint more useful for error checking
• Support ES6, the only tool that supports JSX
• Support for custom reports

Disadvantages

• Need some configuration
• Slow, but not a major problem

My recommendation

My choice is eslint. Jshint is strict and non-configurable, and Jshint lacks the extension mechanism. Jscs It is a good choice to use only code style checking, but eslint can not only conduct code-style testing, but also check for bugs and other problems in the code.

It is also an obvious choice if you use Es6,eslint. Among the tools mentioned above, Eslint supports the widest range of ES6.

If you're like trying eslint, I've created a 5-step quick Start Guide. You can download the ESLint 5-step QuickStart Guide form my website

Jshint is the second choice. If you do not need to eslint advanced features, Jshint once configured to capture the need for good problems. Jscs with many rules will be a good choice if the code style is not checked out.

I was very hesitant to recommend JSLint. Other tools do the same thing, but do not force users to abide by these rules. The only exception is that you happen to unify those rules of coercion, which is worth studying in depth.

A test tool is a good step to capturing a problem, but only sees its rules in error. For further bug auto-capture, I recommend using unit tests. Code view also helps to achieve this.

How do you and your team protect the quality of your code?

Comparison of JavaScript inspection tools