How the React Developer Team Uses ESLint – Their Settings and Custom Plug-ins

  • Post author:
  • Post last modified:2020-11-25
  • Post category:Code Review
  • Reading time:11 mins read
The Official Logo of ESLint. Source: https://eslint.org/docs/about/

Have you ever used a Lint tool, or a static code analysis tool?

Lint is a tool that can analyze the source code and notify the user in case of errors or discrepancies with the team’s coding conventions. In some cases, it can also automatically fix the errors.

Although many kinds of Lint have been developed for different languages, some of you may have encountered the following issues.

This is my first time using this language for coding. What is considered a general coding style in this language?

I’m using the default setting for Lint, but the error verification procedure is too strict. I want to change the settings, but will changing the settings make it easier to overlook certain bugs?

Even for a single language, various coding conventions have been proposed. So, it may be difficult, especially at first, to determine which coding conventions are better to follow.

So let’s investigate the Lint settings on commonly-used Open Source Software, and see what kind of settings and coding conventions are being used.

By concentrating on the ESLint, the most commonly used Lint on JavaScript, let’s look at the coding conventions of the JavaScript used in OSS.

In this post, we will look at the rules for the ESLint that focus on React.

ESLint Overview and Features

ESLint is a linting utility for JavaScript.

ESLint is not dependent on a specific coding convention, and users can also freely enable or disable individual coding conventions. In this sense, one of its key features is its high customizability.

Users can set up their coding standards with a great flexibility by defining their original rules, which are coding rules available by default in ESLint. In addition, famous coding conventions that are shared by third parties such as “Google JavaScript Style Guide” or “Airbnb JavaScript Style Guide” can be reused as well.

You can even enable/disable specific rules for specific files while following those coding conventions.

If you have no idea what settings to start with, you can refer to the “Getting Started” guide provided by ESLint Official to use the recommended coding conventions.

How to read ESLint Rules

It is very easy to set up ESLint coding rules. As a simple example, let’s define “config” as a rule that a semicolon is to be added at the end of a statement.

{
"rules": {
"semi": [2, "always"]
}
}

You can define individual coding rules within rules of the file configuration. In this case, a rule called semi — a default provided by ESLint — is configured. ESLint defines 2 for ERROR, 1 for WARN, and 0 for setting the rules OFF. In this example, when lint is executed, it will state an ERROR if a statement does not contain a semicolon upon execution.

Additionally, ESLint provides many other coding rule groups, and it is possible to use those rules for further customization.

Using settings provided by third parties

Famous coding conventions may already be provided as packages. For example, if you want to apply the Google JavaScript style guide mentioned above, you can use it by installing the eslint-config-google package made public on npm.

{
"extends": "google",
}

By using the description above, users can easily use the coding conventions from Google JavaScript style guide without having to write the settings from scratch.

While some of these rules are provided as default settings by ESLint , you can also choose to use the base settings that are provided as npm module by third parties such as eslint-config-google . It is also possible to develop your own configurations, and share them with others or reuse them in multiple projects. The group of settings for this rule is called sharable config.

In case you don’t want to add a semicolon after the statements while following the Google JavaScript style guide, you can do so by setting the semi in rules as follows. (FYI: the Google JavaScript style recommends users to add a semicolon after the statements.)

{
"extends": "google",
"rules": {
// Additional, per-project rules...
"semi": [2, "never"]
}
}

Plugin

The default rules provided by ESLint cover basic rules, but the range that JavaScript can use is extremely wide. For this reason, it may be possible that the rules you want don’t exist within the default rules. In that case, it is possible to develop your own independent rules within ESLint. In order for third parties to develop their own rules, ESLint allows the use of Plugins. If you search for eslint-plugin-* in npm, you can find a vast amount of custom plugins provided by third parties.

If the rules that you want to use are not provided by ESLint’s default rules, it is recommended that you look for plugins.

Similar to the shareable config, it is easy to set up. For example, if you want to perform a static analysis for the React code, you can install a plugin named eslint-plugin-react, and use the following settings in order to perform a static analysis that is unique to the React syntax.

{
"extends": "google",
"plugins": [
"react"
],
"rules": {
"semi": [2, "never"],
"react/display-name": 2
}
}

By setting the rules as shown above, it can prevent you from forgetting to declare the displayName variable within the React component. In this way, ESLint allows you to easily set and reuse each rule.

So far, I have explained that ESLint has an extremely high customizability and various possibilities for settings. However, what we really want to know is which rules are best applicable in certain situations.

You may have wondered what coding conventions are used in other projects.

As the title of this post shows, let’s find out what coding conventions are being configured, by investigating the static analysis rule used in React of the famous front-end framework.

React

Overview

React is a front-end library developed under an initiative by Facebook.

In the React’s official document, the following three keywords are introduced for React.

Declarative It makes declarative programs possible.

Component-Based Complex UI configurations can be easily executed by using component-based thinking.

Learn Once, Write Anywhere The techniques used in React can be used not only in Web front ends but also in mobile apps like React Native.

ESLint in React

The configuration files of the eslint framework defined within React can be found here.

fbjs

Let’s look at the beginning of the configuration file shown above. You can see that it extends the fbjs.

module.exports = {
extends: 'fbjs',
}

React uses a shareable config called eslint-config-fbjs as a based rule.

fbjs is a compilation of ESLint settings under shareable config that was once used internally by Facebook. Its features are as follows:

1. It does not set a special case for each project.

2. It does not configure rules that are unique to Facebook.

However, in regard to the second feature, Facebook actually created several of its own internal configurations.

According to the extendConfig configured here, it seems that the settings are somewhat created for Facebook.

Plugins in fbjs

Next, let’s look at the rules for the fbjs itself.

In the ESLint configuration files for fbjs, the plugins to be used are specified as shown below.

plugins: [
'babel',
'flowtype',
'jsx-a11y',
'react',
'relay',
],

A brief explanation of each component is as follows:

● babel

eslint-plugin-babel is a rule set for Babel. Babel is a transpiler that can output codes written in ECMAScript2015/2016/2017 or flowtype as JavaScript supported by common web browsers from.

● flowtype

flowtype-plugin is a plugin for performing static analysis provided by Flow in ESLint

● Flow is a tool that enables static typing in JavaScript. Leaving the checking for the static typing to the Flow side, ESLint checks if all the js files have @flow annotations and checks whether or not Flow is checking type or markings.

● jsx-a11y

jsx-a11y is a plugin checker for a rule called react-a11y, which Identifies accessibility issues in React

● react

The rules to react are defined here.

● relay

relay-plugin is a plugin used for executing statics analysis on a JavaScript framework named Relay

Now, as for the repository called fbjs that appeared so abruptly, it seems to be that it is regarded as a library module for Facebook’s product development team to quickly and securely write its codes. Although there are many other scripts apart from the shareable config in ESLint, please be aware that unexpected problems may occur when applying it in the actual production environment.

With regard to this repository, they are developing eslint-config-fbjs-opensource in order to support more modern code bases, and their main focus in the future may shift development based on this shareable config.

React’s ESLint

The rules stated above for fbjs will be the basis of the rules, and any other described rules will be React’s original rules.

Plugins in React

In React’s ESLint configuration file, another plugin has been added.

plugins: [
'jest',
'no-for-of-loops',
'react',
'react-internal',
]

A brief explanation of each component is as follows.

● Jest

Jest is a test framework for JavaScript — of course, made by Facebook. The main philosophy is “zero-configuration,” where appropriate settings are set up when you create projects in create-react-app or react-native init. Especially when you are using React or React Native, this is a test framework that can be introduced very easily.

This rule is only applied to the **/__tests__/**.js file paths.

● no-for-of-loops

no-for-of-loops is a rule for suppressing for (…of)

● react-internal

Although it is not mentioned as a plugin in npm, this is a unique custom plugin defined within React.

Rules have also been added regarding the format of error messages and suppressing primitive type constructors for Boolean, String, and Number.

Regarding other fundamental rules

So far, we have seen an overview of the ESLint plugins used in fbjs and React.

Besides that, static analysis is configured through the default rules provided by ESLint. Here is a summary of all the rules. .

● Does not specify indentations.

● Recommends semicolons.

● Places spaces after blocks or functions and before and after keywords.

● Uses ===or !== rather than == or != as Comparison operator

● The file ends in a new line.

● Uses single quotes for the character strings generally, and use double quotes for JSX.

● It does not permit unused variables declaration.

We wish we could explain each rules, but there are about 140 rules detailed in their configuration. We would like to limit the explanation to a brief overview for this post.

Source code subject to static analysis

Based on this file configuration, React executes its static analysis by dividing it into 3 cases.

eslintrc.esnext.js

In addition to the rules set as mentioned above, it adds a rule that does not allow the user to use var.

Most of the files use this rule for static analysis.

By looking at the React repository, this rule is applied to the following:

packages/*/*.js,packages/*/src/**/*.js,packages/events/**/*.js,packages/shared/**/*.js,scripts/flow/*.js,scripts/rollup/shims/**/*.js

eslintrc.es5.js

The code developed in ECMAScript5 will be statically analyzed with this rule.

In this rule, that use strict is now compulsory, and that the parser is changed from babel to espree.

It is applied to the following:

packages/*/npm/**/*.js

eslintrc.default.js

This rule is applied to the code corresponding to ECMAScript 2017. In addition to the eslintrc mentioned above, the following three rules are added.

● Does not allow the use of var.

● Enables Strict.

● Enables support from Rest Properties and Spread Properties introduced from ECMAScript 6. Furthermore, similar to eslintrc.es5.js, the parser is changed from babel to espree. The application scope is eslintrc.esnext and corresponds to JavaScript codes other than the files with eslint.es5.js applied to it.

A summary of the ESLint used in React

This has been the ESLint rules currently configured for React.

To summarize,

● Generally speaking, the rules used internally by Facebook were open source fbjs. This seems to be widely used in the Facebook’s JS Library. However, it does not assume that other development teams would create the same product.

● Apart from those mentioned above, many plugins like Jest have been used.

● Although multiple versions for ECMAScript exist, each version uses its own static analysis rules to execute static analysis.

Without this, rules would have to be developed uniquely every time, plugins would have to be developed for every framework, and there would be many rules for configuration. By automating all these rules, it helps to eliminate these bugs before they become a problem, especially for interpreter type languages for JavaScript and other large-scale projects.

In Conclusion

Sider allows code reviewing for JavaScript projects using ESLint. By using Sider, reviewing code will be much easier if the project members all share and use the automatic code review that is connected to your Pull Requests on GitHub.

Please feel free to use it!


For more information about Sider, please go to our website.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.