Feature request: hide warnings/errors if they will be auto-fixed

[ryaninvents]

Proposal: Add a new config option eslint.hideAutoFixedIssues.

If eslint.hideAutoFixedIssues and eslint.autoFixOnSave are both true, then do not show the error/warning in the text editor if ESLint suggests a fix. This is helpful when scanning a file, as it makes real errors (such as a typo in a variable name) much more visible.

I've got a bit of time coming up and would love to implement this.

[dbaeumer]

Nice suggestion. A PR is welcome here. The file to look at is: https://github.com/Microsoft/vscode-eslint/blob/dbaeumer/multiroot/eslint-server\src\server.ts#L899

[ryaninvents]

Unfortunately it looks like if the error is reported, it must be displayed, and if the error is not reported, it will not be auto-fixed. Bit of a Catch-22.

However, I was able to successfully downgrade issues with available fixes to DiagnosticSeverity.Hint, which provides a nice user experience. If the cursor is within the range highlighted by the issue, it displays as an unobtrusive lightbulb in the gutter, and if the cursor is on a different line there's no visual indication of the issue.

Do you think hideAutoFixedIssues is still an accurate enough phrase to describe this behavior? It's not really totally "hidden" per se, but all the other wordings I came up with sounded engineer-y and bizarre (suppressAutoFixedIssues was the closest I could come up with).

[ryaninvents]

I've made the PR, but it's open to maintainers, so you can modify the name of the option if need be.

[dbaeumer]

@r24y thanks for looking into this. I think it should still be possible to hide the errors all together without downgrading them to a hint. The code flow should be something like this:

• recordCodeAction should return whether there was a fix or not

					if (problem) {
						let diagnostic = makeDiagnostic(problem);
						let hasFix = false;
						if (supportedAutoFixLanguages.has(document.languageId)) {
							hasFix = recordCodeAction(document, diagnostic, problem);
						}
						if (!(hasFix && hideAutofixableDiagnostics)) {
							diagnostics.push(diagnostic);
						}
					}

Have you tried this?

[ryaninvents]

@dbaeumer I haven't tried that. I might have time today to work on it

[ajerez]

@dbaeumer Any updates on this? Thanks

[dbaeumer]

No, not from my side. @ryaninvents any update.

[kasvtv]

edit: Just sent a PR!

I would like to emphasize how much of a difference this would make:

This option will allow ESLint to completely replace any formatting tooling like Prettier, Beautify etc for VScode! The only reason why it doesn't right now (at least for me) is that the mandatory warnings while typing are just too distracting.

One could even use "eslint.options": { "fixTypes": ["layout"] } such that it really behaves like just a formatter :).

Both Prettier and Beautify aren't very configurable, at least not anywhere near the granularity that ESLint has. Also when a team member happens to use ESLint, but not the formatter, they won't be warned about breaking project conventions. With this change, even if someone doesn't have/like autofixing enabled or uses ESLint with a different editor of their choice, it would still nicely warn them!

This could really make ESLint the one-stop-shop for both auto formatting and linting, with its configuration being a single source of truth, without having to deal with possibly conflicting extensions with and configurations for different features described with different nomenclature.

[dbaeumer]

@kasvtv thanks for the PR. Due to #154 this however can have a strange side effect. In the code the same kind of error might be reported as a problem and not being reported. AN example is superfluous ;. In code like

console.log();;;;;;;;;

the last ;;; will not be reported as a problem whereas ;;;;; are. The reason being is that the first autofix round ESlint computes is only fixing the last three ;.

Not that this is a big proble, just wanted to point out that there might be some weirdness.

[kasvtv]

I did experience some other minor issues where multiple fixes are needed actually.
Mostly with indentation requiring a second pass before it gets it right.

It seems to me that layout fixes are applied too early in the fix queue. Not entirely sure how easy that is to change. Performing them in order based on their fixType might help.

Making fix truly idempotent should be the last step in making ESlint double as a formatter.

In most cases (at least in the case of linting while typing), code is always immediately linted again after autofixing. Wouldn't it be an easy fix keep fixing when auto-fixable issues occur on a post-fix lint and save the result and update all issues at once when they stop appearing? Might have to limit the amount of passes or hash the result to prevent loops, but it could work. The performance hit might not be too bad, since one would be linting at this time anyway and if certain sensitive fixes like indent can be applied last. Besides it should be a relatively rare occurrence.

[finnp]

Atom has “Ignore fixable rules while typing”. I'm really missing this in VSCode. Would've been nice to see that PR merged.

[minig0d]

Not sure if it warrants a separate issue, but it looked like one of the more recent issues mentioning this got merged into another which got closed into this one, and there was an older one #222 closed as upstream (but not sure if anything has changed in the past 3 years) so...

What irks me isn't so much that some rules get autofixed at save, it's more that a tiny change (ex moving around a line of code) actually fires so quickly, that the entire screen could turn squiggly while I'm actively moving the code. I personally am one that does like the linting to be "live", but would much rather it occur after an inactivity of a certain period of time (personally I'd probably like it between 500ms and 2s, but that's just a guess). Some people it may be 30 or 60 seconds even. Basically running the checking on a debounce (if possible).

A side benefit would seemingly be a significant decrease in computer resources (not that it takes much now).

[rhyek]

Just switched my default formatter from prettier to eslint with this extension and this is the one thing I think is missing for a perfect experience. Warnings/errors for things prettier will fix anyways is too distracting.

[dbaeumer]

This can now be customized using the new eslint.rules.customizations setting. The setting gives you full control over which severity is used when errors are detected. It also allows to not report an error at all to the UI.

[amannn]

@dbaeumer Thank you very much for the update on this issue!

Can you provide an example for how this would work?

I've tried this setting:

"eslint.rules.customizations": [
  { "rule": "prettier/*", "severity": "off" }
]

From what I can tell, this turns the rule completely off in VSCode and also doesn't provide auto-fixing anymore.

The behaviour I'm looking for is having no visual indication of the rule, but still using it for auto-fixing. Ideally this would be the case for all auto-fixable rules and I wouldn't have to maintain a list of all of them in the customizations array.

Am I missing something?

[dbaeumer]

@amannn good catch. There is an issue if all problems are off then code action on save short cuts. Need to consider this.

[dbaeumer]

Opened #1345

[daveycodez]

Code snippet for anyone landing here from Google.

Disable Squiggly Lines in VS Code for ESLint fixable warnings and errors:

{
  "eslint.rules.customizations": [
     { "rule": "*", "fixable": true, "severity": "off" }
   ]
}