Thanks for the PR, @bradzacher!

typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community.

The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately.

Thanks again!

🙏 Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently on https://opencollective.com/typescript-eslint. As a thank you, your profile/company logo will be added to our main README which receives thousands of unique visitors per day.

Codecov Report

Merging #1272 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #1272      +/-   ##
==========================================
+ Coverage   94.06%   94.06%   +<.01%     
==========================================
  Files         131      131              
  Lines        5745     5746       +1     
  Branches     1617     1619       +2     
==========================================
+ Hits         5404     5405       +1     
  Misses        183      183              
  Partials      158      158

Can this be used to make ESLint not report an error in those cases? I'm not sure how just changing the suggestion type would help with adoption, if it still fails CI...

Converting it to a suggestion fixer only means that it won't auto-fix and introduce breakages.

The idea would be that you'd set the rule to a warning (which shouldn't block your CI; if your warnings and errors both block CI, then why have warnings?), and progressively update your codebase to remove the warnings.

As mentioned on the linked issue, adding an option to not check falsey types makes the rule pretty well useless, as it would only check object and symbol; but those are fixable without code breakage, so you'd eslint --fix them, and then the rule would report nothing.

As mentioned on the linked issue, adding an option to not check falsey types makes the rule pretty well useless, as it would only check object and symbol; but those are fixable without code breakage, so you'd eslint --fix them, and then the rule would report nothing.

That is still very useful on a large team where many people don't know the latest features. It means that no new cases can be introduced, and when someone writes them in their editor, they can be directly automatically converted to the more precise form on save.