A few months ago, at the office, I was lamenting the fact that TSLint doesn’t have the ability to WARN of problems, therefore any new rules that get introduced will break the build. We have a gigantic project and have had a lot of success slowly implementing ESLint rules thanks to being able to give teams time to adhere to the new rules by setting them to WARN instead of ERROR. Once all the warnings are gone from the build we switch it ERROR and move onto the next rule.
I found two issues (#629 and #345) on github and took a shot at implementing one of the suggested ways to allow for setting the “rule level”. At first I went a little crazy and renamed RuleError to RuleViolation which resulted in hundreds of files being changed. After a little feedback, I reverted that and added a simple RuleLevel that is attached to each Rule. I haven’t gotten around to writing tests for it, which is probably why it hasn’t had much attention, but I found the tests a little complicated and I need a solid block of time to get in there and make my changes. It’s also a bit weird because the TSLint project uses TSLint to lint itself. So, while backwards compatibility is very important, it’s a little odd trying to use the new stuff in HEAD while the scripts use the version (master) installed by package.json when running some of the tests.
I’m going to start pushing to get this pull request in as it’ll help my team adopt better and more consistent styling of our TypeScript. We have tons of Javascript being converted over to TypeScript and in the process losing our ESLint rules, so this is a high priority before we get too far off the rails.