Eslint vs Performance

Nowadays, eslint is a very popular tool in the frontend world. It helps you to enforce different code style rules, prevent bugs, and encourage your team to use best practices as you write code.

Eslint is completely pluggable and you can add as many rules as you wish, and of course, write your own rules. As you start seeing the benefits eslint gives you, it is become very tempting to use each and every rule that you can reach out to.

But beware! Keep in mind, that with every rule you accumulate the amount of work that needs to get done whenever you lint your code, be it a local development or a part of a CI.

To get some insights about time spent on every rule you can use a special environment variable TIMING=1. It will trigger the display of the ten longest-running rules, along with their individual running time and relative performance impact (docs).

Take a look at the timing information on one of the projects I'm working on:

Rule                                    | Time (ms) | Relative
:---------------------------------------|----------:|--------:
import/no-restricted-paths              | 94633.358 |    72.2%
@typescript-eslint/no-floating-promises | 18576.419 |    14.2%
react/no-multi-comp                     |  4629.594 |     3.5%
@typescript-eslint/no-redeclare         |  2634.454 |     2.0%
lodash/callback-binding                 |  1272.849 |     1.0%
@typescript-eslint/naming-convention    |  1209.871 |     0.9%
lodash/collection-return                |   885.415 |     0.7%
lodash/no-unbound-this                  |   669.923 |     0.5%
lodash/collection-method-value          |   668.716 |     0.5%
lodash/no-extra-args                    |   569.119 |     0.4%

More than 90 seconds spent on checking a single rule... A little bit too much, isn't it? :)

In this particular example, the TIMING report revealed a performance bottleneck and pushed us to contribute to a third-party eslint plugin we used and fix it eventually.

In addition to obvious performance issues, you might notice that a significant amount of time is wasted on rules that you can live without. For example, most of the code-style-related rules could be replaced with prettier. Some rules just don't give you that much to use them, e.g. react/no-multi-comp in our case.
As for me, I prefer to follow this advice:

Look at every linting rule and think: “Does this rule bring me joy help me find bugs?” If not, TURN IT OFF.

But I would add: start with ten the longest-running rules if your goal is to speed up linting.