'Fix all auto-fixable problems' doesn't fix as many issues as possible
See original GitHub issueI have ESLint extension 1.0.7 with VSCode 1.6.0 in win10 x64 and ESLint 3.7.1 globally installed.
First of all, please note that since ESLint 2.9.0:
when you use the --fix option, ESLint will make multiple passes over your code in an attempt to fix as many issues as possible.
Let’s say I have the following .eslintrc.js in C:\Users\Kostas
:
module.exports = {
"env": {
"browser": true,
"es6": true,
"greasemonkey": true,
"jquery": true
},
"extends": "eslint:recommended",
"rules": {
"indent": ["error","tab"],
}
};
Now, I have this Javascript file:
var localTimezone;
function convertDates(f) {
if (f === 'f1') {
format = 'DD.MM.YYYY HH:mm';
} else {
format = 'MMMM DD, YYYY';
}
}
If I do eslint --fix myfile.js
via CLI (a single time) it will be fixed into:
var localTimezone;
function convertDates(f) {
if (f === 'f1') {
format = 'DD.MM.YYYY HH:mm';
} else {
format = 'MMMM DD, YYYY';
}
}
But, in VSCode the ``Eslint: Fix all auto-fixable problems` command doesn’t fix all indentation at once: executing it the first time will only fix indentation on line 3, a second time fixes lines 4 + 9, and finally a 3rd time fixes lines 5-8, i.e. it requires multiple (3) executions.
For reference, in Atom with linter 1.11.18 and linter-eslint 8.0.0 using my global ESLint installation as well,
with the relevant command (Linter eslint: Fix File
) all indentation is fixed with a single execution.
Issue Analytics
- State:
- Created 7 years ago
- Reactions:56
- Comments:77 (18 by maintainers)
Top GitHub Comments
Wanted to chime in on this, first reported here (marked as duplicate): https://github.com/Microsoft/vscode-eslint/issues/575
Lots of online resources start to recommend to use eslint+prettier. Basically using eslint for its awesome code-quality rules, but prettier for its awesome formatting rules: https://prettier.io/docs/en/comparison.html
If someone uses VS Code and eslint, they would start by installing the extension vscode-eslint. The npm packages installed for the repository you work on would be eslint, prettier, eslint-config-prettier, eslint-plugin-prettier.
Prettier best practices integration with eslint tells you to use
"extends": ["plugin:prettier/recommended"]
. This will makeeslint --fix
also run the prettier formatter. If I run this on command line like sonode_modules/.bin/eslint --fix server FILE
it formats everything perfectly. This has already been established in this thread.In VS code I’ve set:
When I then save the same
FILE
in VS Code, I have to do three consecutive saves in order for the formatting to end up in its final state, equal to as when I ran it from command line. This is obviously not good and has also been established in this thread.I then turn to install Prettier in VS Code. This section about integrating VS Code Eslint+VS Code Prettier reads:
The recommended VS Code configuration to integrate these two is to set the configuration
"prettier.eslintIntegration" true
and remove"eslint.autoFixOnSave": true
and"javascript.format.enable": false
The purpose of prettier-eslint is to run
prettier
, followed byeslint --fix
. If one has set the ESLint configuration ("extends": ["plugin:prettier/recommended"]
), then prettier will already be run witheslint --fix
. In practice what will happen then is:prettier
is run.eslint --fix
is run. a.eslint --fix
runs the the prettier plugin and the rule called prettier, which again formats according in the same way as 1.This is a strong reason as to why possible the VS Code ESLint extension and the command
ESLint: Fix all auto-fixable Problems
should instead issue aeslint --fix FILE
instead of what it currently does. I would then not have to rely on the VS Code Prettier extension to format the document in a subpar way.I released 2.0.4 today which addresses this. Please note that for large file you need to increase the time budget to compute the fixes using
editor.codeActionsOnSaveTimeout