Tslint: Option to auto-suppress errors

Created on 17 Jan 2018 · 10Comments · Source: palantir/tslint

Correct me if I am wrong but currently there is no way to gradually adopt tslint to an existing project.
You are flooded with errors. Therefore adding it to your CI and enforce it is not possible. Also all workarounds are not practical in my eyes.

So here is my suggestion:
Add a command line option like --fix which automatically suppresses all warnings by adding a
// tslint:disable-next-line:rule1 rule2 rule3
comment and a description stating that this is a legacy error. Now if you want to adopt tslint you can enable all the rules you want. Run it once with the new flag enabled and add it to your CI. Jobs done. All new code has to follow the rules because it is enforced. Nobody has to touch code which is not required to change and whenever you come across such a comment in your daily work you can fix it to make your code base better over time.

Any opinions on this?

Needs Proposal Question 🌹 R.I.P. 🌹

Source

smoehrle

👍2

All 10 comments

Set defaultSeverity: "warning" in your config file.

adidahiya on 17 Jan 2018

I'm not sure how your proposal would handle enforcing lint rules on new code added to your project..? That's a little harder to do, you might be able to achieve something there by using the programmatic linter API and checking the git diff on a commit...

adidahiya on 17 Jan 2018

Set defaultSeverity: "warning" in your config file.

This or just ignoring the exit code does not solve the issue. The output is still cluttered with all errors/warnings. As a developer I do not want to have to search for the errors/warnings I produced. But with your second comment I think there is still a misunderstanding.

I propose this flag to be used only once in the beginning. To get a "clean state" without having to touch code manually all over the code base. This has the effect that the tslint output is clean and I can enforce it to run without errors as you do currently in this project. All new code is linted as of today. If there is an error the CI will break and you have to fix it. In addition you can fix all the supressed errors when you have to touch the code anyway because of a bug/new feature/refactoring...

I hop this makes my idea clearer.

smoehrle on 17 Jan 2018

👍1

I see what you're getting at. Yeah, I suppose that's useful in one-off cases. I'm reluctant to add it as a core feature in the TSLint CLI, but it should be easy enough to build a tool that does this using TSLint's APIs (look at all the failure locations, inject some // tslint:disable-next-line lines above those failures, write the output file). If you (or someone else) builds it and provides a link here, we could consider adding it to the docs or README.

adidahiya on 17 Jan 2018

I've started something here (quite a hack at the moment, but will clean it up going forward): https://github.com/paulkoerbitz/tslint-auto-disable

paulkoerbitz on 19 Mar 2018

I think tslint-auto-disable is in a usable state now. @stefan-m if you're still interested, I'm interested in feedback. It's also on npm now: https://www.npmjs.com/package/tslint-auto-disable

paulkoerbitz on 29 Mar 2018

👍1

This feature becomes necessary on ant reasonably large sized project. For inspiration, rubocop handles this situation very elegantly with the option --auto-gen-config

ianks on 5 Apr 2018

👍1

It's still unclear whether this should be integrated into TSLint itself or stay as a separate package (tslint-auto-disable). Since there's a bit of demand for it, it'd be good to see a concrete proposal for how this could be integrated into TSLint.