Before You File a Proposal Please Confirm You Have Done The Following...

• I havesearched for related issues and found none that match my proposal.
• I have searched thecurrent rule list and found no rules that match my proposal.
• I haveread the FAQ and my problem is not listed.

My proposal is suitable for this project

• My proposal specifically checks TypeScript syntax, or it proposes a check that requires type information to be accurate.
• My proposal is not a "formatting rule"; meaning it does not just enforce how code is formatted (whitespace, brace placement, etc).
• I believe my proposal would be useful to the broader TypeScript community (meaning it is not a niche proposal).

Description

Enums are constrained sets of named key-value pairs. They're often used in places where developers want to be able to refer to one of those pairs by name, without caring what the value is.

Checking whether an enum-typed value is truthy, however, takes a dependency on the enum's values:

if(value){/* ... */}

I propose we add a rule that prevents truthiness checks on enum values. Similar to@typescript-eslint/strict-boolean-expressions, it would flag anyif statement, ternary, etc. that checks on an enum. Developers should instead use an explicit===/!== check.

Fail Cases

enumTheme{Dark,Light}functionwithTheme(theme){if(theme){console.log("🌞");}else{console.log("🌝")}}

Pass Cases

enumTheme{Dark,Light}functionwithTheme(theme){if(theme===Theme.Dark){console.log("🌞");}else{console.log("🌝")}}

Additional Info

Alternately, this could be an option in@typescript-eslint/strict-boolean-expressions. But that rule is already pretty meaty and isn't quite the same - it deals withnullable values, notimplicitly falsy values. I think this is a distinct enough classification of issue that it deserves its own rule.

I imagine we'd want to add anallowExplicitlyValuedEnum option for cases where the enum is given an explicit0 or"" value and intentionally meant to be used in truthiness checks:

enumTheme{None=0,Dark,Light}