Ignore fixable rule while typing

[markogresak]

I keep switching between JS code, where I'm using eslint, and TypeScript code. One feature that I really enjoy in eslint and am missing with tslint is Ignore fixable rules while typing.
I like it because the UI is less distracting while I'm typing and is not showing errors that are fixed as soon as I save the file, e.g. eofline, which is already fixed by atom.
Would something like that be possible?

[Xapphire13]

Is the feature you want disabling lint until save? Or disable lint until a certain period of being idle?

[markogresak]

The way linter-eslint works is it will disable the fixable rules while typing (i.e. in the "lint on fly" stage) and will display these errors only when the file is saved. But for errors which can't be fixed automatically (e.g. unused variable), the error is shown immediately and will be shown until it's fixed.
A good start would be to have an option for lintOnFly instead of it being hardcoded, but I still prefer to see the unfixable errors right away, before I even save the file, so I can fix them immediately.
What I want with this issue here is to open a conversation to find the best way of doing this. I was out of the TypeScript ecosystem for almost two years now and I've seen a lot of development has occurred and I'm not fully aware of all features the tools are offering and I wouldn't want to re-invent the wheel.

[Xapphire13]

Sounds like a good improvement. I will work on this when I get some free time. As for the fixable/nonFixable errors, I'm not sure off hand what info the API gives us, so that'll need some investigation

[Arcanemagus]

linter-eslint actually builds a cache of the rule metadata coming back from ESLint's API. This includes whether the rule is fixable or not. Whenever this metadata updates it is sent back to linter-eslint along with the results. When the editor is modified (on the fly run), we tell ESLint to disable the fixable rules.

It's a mess, but mostly works.

[Xapphire13]

Hmm, sounds messy. Got a direct link to the cache code? Seems that the lintOnFly stuff is an easy change though

[Arcanemagus]

The check for updated (and the initial) fixable rules list in the worker happens here. When that has found updates to send it is returned here.

The job response is processed here which updates a local list of fixable rules that is used here when sending a job.

It was all introduced in AtomLinter/linter-eslint#1018.

[phaux]

It would make sense to hardcode the trailing whitespace rules as blacklisted by default, because atom itself fixes it

[Arcanemagus]

@phaux Atom itself doesn't fix those, the whitespace package (part of Atom's core packages, but not Atom itself) can do that, but it's optional.

[Xapphire13]

We could technically scan config.cson to check if the whitespace package is disabled, and if it's not, then check if the user has turned off whitespace trimming.