Open ryanberckmans opened 5 years ago
This would bring tslint development closer to golang's glorious distraction-free development with gofmt
. Another rule that would be useful to blacklist from UI diagnostics is whitespace.
It'd also be useful to have a checkbox to Enable blacklist if and only if "Fix errors on save" is active (if unchecked, Blacklist is always active)
.
A blacklist of reasonably spammy rules could ship with linter-tslint
, and this ^ option would be checked by default, such that new users would get a convenient blacklist, but by default the blacklist is only active if the user has opted into "Fix errors on save".
Over in linter-eslint
we send the current rules whenever they have updated since the last time we sent them back to the main process. Back in the main process there is a routine that returns the list of rules currently known to be fixable. If the user has enabled the option to ignore fixable rules, we use that list of fixable rules to just tell ESLint to ignore them for the lint jobs we run from the editor.
This process does require at least one lint job to run before fixable rules are ignored, but after that it is dynamic what rules are ignored. Is something like this possible with tslint
?
There is also an option that allows users to ignore any rule they specified, similar to your blacklist above. That should be blank though, this definitely shouldn't ship with a "default list".
If the user has enabled the option to ignore fixable rules, we use that list of fixable rules to just tell ESLint to ignore them for the lint jobs we run from the editor.
@Arcanemagus nice! I like the idea of a config checkbox Ignore (Don't show UI warnings for) Fixable Rules
as an alternative to my entire proposal. Not sure I'd ever want to ignore a non-fixable rule.
Functionality like that depends on being able to determine the list of fixable rules though, which I don't know if tslint
provides that capability.
Note also that in linter-eslint
all "ignore these rules" options are ignored for lints on a buffer that has been saved, so users can still see messages that will fail CI checks if they have stopped editing the file.
@Arcanemagus makes sense. I'm open to any solution that suppresses fixable/blacklist of annoying linter errors, to make Atom typescript development less distracting, similar to golang with auto gofmt
.
If you're interested to propose a specific design for a solution, I'm happy to fund a gitcoin bounty for somebody to execute that design.
I use tslint with "run fix on save"; the tslint rule quotemark is useful, but having it show up as a linter error in Atom/Nuclide diagnostics is prohibitively distracting for me. I'd rather have it silently fixed. One way to achieve this is to have an editor-defined blacklist of rules that can still be fixed, but don't show up in UI diagnostics.
Eg. if
quotemark
is added to the blacklist, violations of that rule appear nowhere in the UI-- not in diagnostics list or inline.