Many React projects have ESLint set up and devs are fixing lint errors as they code. This is great for reducing bugs, and keeping code cleanly formatted.
However, sometimes there’s a situation where a project can have a lot of linting errors (i.e. adding ESLint to an existing project) and it would be tedious for a dev to fix them manually. Don’t worry, ESLint has a command for auto-fixing: eslint --fix!
In this article I’ll discuss the flags available for ‘fix’, the types of issues (problem, suggestion, layout) that ‘fix’ can resolve automatically, and options such as how to limit the amount of warnings, print to a file, and more.
ESLint –fix Options
Whether or not you have experience with ESLint, the primary thing you need to know for using ESLint commands is that it will only lint and fix according to the rules set in your .eslintrc.json file*. An .eslintrc.json file with lots of preconfigured rules can be found here at this ESLint playground (scroll to the bottom for the download).
Related: Test your TypeScript knowledge against these 50 difficult TypeScript questions.
*If you are running ‘fix’ from the eslint-cli, you can set rules with the --rule option.
There are three ways that ESLint fix can be run:
eslint --fixeslint --fix-dry-runeslint --fix --fix-type
eslint --fix will fix every rule violation it is capable of fixing, actually overwrite the code, and print out any warnings or errors it was incapable of fixing.
Most errors are not actually automatically fixable. Take a look at this documentation, the items with the ‘wrench’ image can be auto-fixed.
Here’s an interesting example: 0 == 0 can be automatically fixed (to 0 === 0), but comparing a variable likely won’t be fixed (i.e. x == 0). The linter has to err on the side of caution. It generally fixes redundancies and situations where typing can be certain.
The output from eslint --fix will be a list of errors and warnings. If desired, warnings can be silenced with the --quiet flag. Conversely, if desired, a maximum number of errors can be specified as ‘too many’ (--max-warnings [number]), and the linter will succeed but end with exit code 1 (more on that below).
eslint --fix-dry-run acts like fix but will not actually overwrite the file. Instead, specify an output location and a formatting option such as eslint --fix-dry-run --format=json -o ./test.test.json. This output will be quite verbose, naming the files that were linted and results.
eslint --fix --fix-type enables targeting of specific categories of issues to fix. We’ll discuss the types in more detail below, but an example command would be eslint --fix --fix-type layout. This would fix an issue such as having too much whitespace before a line of code, if the rule is designated in your .eslintrc.json file (this rule in particular would be “indent”: [“error”, 4] to limit whitespace to four characters).
Below is output from my project when I ran eslint --fix --fix-type problem \”src/**/*.tsx” . This command targeted all problems in my .tsx files under src folder.
*A note on these commands: notice that--fix-type is preceded by -fix , while --fix-dry-run is not.
The Three Types of Fixable Issues
The three types of issue either fixed or reported by --fix are:
problemsuggestionlayout
According to the ESLint documentation:
- a problem is code that will cause an error or confusion
- a suggestion is code that could be done in a better way
- layout deals with how the code looks
Now that we are familiar with the fix-type flag, let’s look again at the 0 == 0 issue. This is fixable as a suggestion. Issues such as whitespace count before the start of a code statement or extra parenthesis are fixable as layout.
ESLint –fix Warnings
When running eslint --fix, some rule violations result in warnings instead of errors. Take a look at the below TypeScript rule violations:
warning IObservableArray is defined but never used @typescript-eslint/no-unused-varswarning Unexpected any. Specify a different type @typescript-eslint/no-explicit-any
Generally, warnings don’t directly result in problems at runtime. However, many rules can be configured to show errors instead of warnings (or vice versa). For example, both of the issues listed above are included as warnings when extending @typescript-eslint/recommended like below in .eslintrc.json:
extends: [ 'plugin:@typescript-eslint/recommended' ]
However, I could have specified the below instead:
rules: [
"no-unused-vars": "error"
]
This would make the IObservableArray violation appear as an error instead of a warning. Error vs warning is partly a difference in what rules a particular team finds most critical to enforce.
The Three Exit Codes of ESLint fix Command
ESLint’s fix command has three possible exit codes:
- 0: success and no lint errors, less warnings than max warnings
- 1: linting was successful, at least one lint error or more warnings than max-warnings
- 2: linting unsuccessful due to config error or internal error
The exit code will be at the end of the output and appear like this:
It’s best to fix the errors of course. However, keep in mind there is also the option (preferably only during testing) to ignore rules for individual lines. For example, // eslint-disable-next-line @typescript-eslint/no-explicit-any could be used to bypass the no-explicit-any warning mentioned previously.
TSLint –fix Differences
Even though TSLint is deprecated in favor of ESLint, many devs are still using TSLint (based on how many Google searches are still happening for TSLint topics).
TSLint has a --fix option, but it has no flags (i.e. no --dry-run option). TSLint also has different exit codes. From Palantir’s docs:
0: Linting succeeded without errors (warnings may have occurred)
1: An invalid command line argument or combination thereof was used
2: Linting failed with one or more rule violations with severityerror
If you are still using TSLint, consider upgrading to typescript-eslint. Many of the commands and directives are the same, such as the directives for ignoring lines or rules.
Resources
Here’s how and when to specify global variables in your .eslintrc file.
Here’s how to configure the @typescript-eslint/ban-types rule in your project.
Expand your JavaScript knowledge with these 50 difficult JavaScript questions!
Normally I link to example React code and show screenshots of a working app. This article is different: the codebase doesn’t matter much, it’s all about the ESLint commands and the output. In addition to the code snippets and screenshots above, take a look at the below docs. They provide very detailed information about all the capabilities of ESLint fix.
- ESLint docs: https://eslint.org/docs/user-guide/command-line-interface#fixing-problems
- Old TSLint ‘fix’ command: https://palantir.github.io/tslint/usage/cli/
- This is a good start to your
.eslintrc.jsonfile:
parser: '@typescript-eslint/parser', extends: [ 'eslint:recommended', 'plugin:react/recommended', 'plugin:@typescript-eslint/recommended' ], plugins: [ 'react-hooks' ]
- This is an excellent resource: https://eslint.org/demo. You can scroll to the bottom and download the
.eslintrc.jsonused for the rules in the demo. You likely will want to incorporate some of these rules in your own project.
