How linting and ESLint improve code quality

Since joining Zalando, I have had the opportunity to dive into some open source projects like , a pluggable JavaScript linter. Here is my take on what ESLint is, a brief description of linting in general, and why it is so important. ESLint What is linting? Generally speaking, linting is a tool for static code analysis and therefore part of . The main purpose of white-box testing is to analyse the internal structure of components or a system. To make sense of this, a developer would already have knowledge of the written code and will define rules or expectations about how a component should behave (unit tests), or how it should be structured (linting). white-box testing In modern web development, this describes the process (and tools) of applying rules against a codebase and flagging code structures that violate these rules. Rules can vary from code rules, so code appears to be written by one person, to much more complex rules (e.g. ). Even fixing these issues is part of modern JavaScript . styling here linting Why should you lint your code? Linting code is already an established part of any (popular) JavaScript project and, in my opinion, has a lot of benefits such as: Readability Pre-code review Finding (syntax) errors before execution As we have the possibility to define a set of styling rules, this increases the readability of our code towards the effort of having our codebase look like it was written by “ ”. This is important, as it can happen that software engineers move from codebase to codebase within projects meaning a lot of people become involved. A common set of rules makes it easier to really understand what the code is doing. one person Further linting rules help to improve code reviews, as linting already acts as a pre-code review, checking against all the basic issues such as syntax errors, incorrect naming, the tab vs. spaces debate, etc. It increases the value of having code reviews, as people are then more willing to check the implementation rather than complain about syntax errors. ESLint in a nutshell is an open source, JavaScript linting utility originally created by Nicholas C. Zakas. Code linting is a type of static analysis that is frequently used to find problematic patterns or code that doesn’t adhere to certain style guidelines. There are code linters for most programming languages, and compilers can sometimes incorporate linting into the compilation process. ESLint ESLint is a CLI tool which is wrapped around two other open source projects. One is , which creates an Abstract Syntax Tree (AST) from JavaScript code. Based on this, AST ESLint uses another project called which provides traversal functions for an AST. During the traversal, ESLint emits an event for each visited node where the node type is the Event name, e.g. or . ESLint rules are therefore just functions subscribing to node types it wants to check. Espree Estraverse FunctionExpression WithStatement It is also important to note that ESLint doesn’t support new language features until they reach Stage 4 of the . proposal process of TC39 A basic bird’s eye view how ESLint works For further explanation, I will use the following simple script which generates an AST for the given JavaScript code. simple AST Creation Abstract Syntax Tree The is an abstract representation of your code structure. In the JavaScript world, this abstract representation is defined by the project and is the starting point if you want to understand JavaScript AST’s or want to build / extend on your own. I highly recommend reading the grammar documentation, as it helps to understand the different types of nodes represented in the AST. AST ESTree ES5 AST A specific point of difference with the AST is that each node describes a specific grammar definition in your code, as you can see below — our one line of JavaScript code already produces an AST with 5 nodes, and each node itself contains additional information which you can see in the JSON representation below. This graph representation is just one example of how a Tree representation of our code might look like (I would also interpret the values in as individual nodes, but developers are free to choose themselves). ArrayExpression Visualizing our AST (with ) http://resources.jointjs.com/demos/javascript-ast As you can see, the AST of just one line of code and a simple Tree representation contains a lot of information. What kind of information is in the AST? As previously mentioned, one line of JavaScript code contains a vast amount of information for an AST. Every entry in the AST is a , consisting of a ‘type’ property and a . Node object SourceLocation Object The type property is a string representing the different Node variants in the AST. The consists of a start and end property. The type, start, and end line number provide us with information about the structure of our code. Generally, a JavaScript AST consists of , and Declarations (for ES5), which doesn’t sound like much, but have a lot of variations. For those interested in ES2016 and beyond, see the following: SourceLocation Object Statements Expressions Patterns Classes Modules Template Literals Traversing the AST Now that we have generated our AST for our JavaScript code, what can we do next? Traversing! As great as the AST is, the exciting part starts with traversing it and analysing the information it has. For traversing the AST, ESLint relies on the Estraverse project which traverses over the generated AST (from Espree). Estraverse provides a traverse functionality which executes a given statement. In this traverse function we can subscribe to specific types of nodes and complete our analysis. For example, if we want to make sure that all Literal Definitions in our Array declaration are Integers, we could check for that with the sample script below: Sample script for traversing Furthermore, the traverse functionality of uses the , which allows us to execute functions for each visited node of the AST instead of traversing the whole AST and performing operations afterwards. By debugging the of Estraverse, it has showed that it is using the depth-first algorithm of traversing a Tree. This means Estraverse is traversing to the end of a child node (depth-first) before it begins backtracking. The Visitor pattern, combined with a depth-first search, then allows ESLint to trigger Events whenever it enters an AST node or leaves it immediately. Estraverse Visitor design pattern traverse function Plugins The architecture of ESLint is pluggable, so if you want to create new rules for specific problems, frameworks, or use cases you have, it is recommended to develop ESLint plugins rather opening up an issue and requesting changes. This presents quite a powerful opportunity to create much more complex code analysis than ESLint can provide. Therefore, developers should consider creating plugins as they are npm modules. Thanks to the pluggable architecture, it is easy to use already existing plugins or rules for different frameworks, libraries, or companies, e.g. , or . eslint-plugin-react eslint-plugin-vue eslint-contrib-airbnb Wrap-Up While we all might use ESLint and linting tools in our JavaScript projects, we don’t know much about the insights of these projects and the challenges behind them, or how they provide us with the tools to create good quality code. I highly recommend every JavaScript developer play around with these tools, as this is still a topic only a select few really work on, but are actually used everywhere. A few projects doing similar work are: , , ). https://github.com/jlongster/prettier https://github.com/babel/babel-eslint https://github.com/facebook/flow/tree/master/src/parser As a next step, I’d like to create a small ESLint plugin tutorial for interested developers to see how they can create their own custom ruleset for different use cases, e.g. placing rules into the core of ESLint. If you have any suggestions or ideas for a ESLint plugin you’d like to see, grab me on Twitter at @Fokusman .