Follow identifiers to their declaration in `no-constant-condition`

• What rule do you want to change? no-constant-condition
• Does this change cause the rule to produce more or fewer warnings?: More How will the change be implemented? (New option, new default behavior, etc.)?: New default behavior

Please provide some example code that this change will affect:

var foo = true;
if(foo) {}

• What does the rule currently do for this code?: Nothing
• What will the rule do after it’s changed?: Warn/error
• Are you willing to submit a pull request to implement this change?: Possibly

This proposal has been split out of #13752

Currently no-constant-condition triggers on if(true){} but not on const foo = true; if(foo){}. In this case we could use the ScopeManager to attempt to follow foo to its declaration/assignment. If the variable is in scope and only assigned once, then we could check if the assigned value is constant.

In addition to assignments, we could also check other types of declarations. For example a function declaration could trigger an error:

function foo() {}

if(foo){} // <= foo is always truthy here

Additionally, @mdjermanovic pointed out that there may be other rules which could be employing a similar technique.

I’ve done a simple version of this for a rule I wrote (as mentioned in #13752) which could be used as a starting place.

Shout out to @bradzacher who first suggested this approach while we were iterating on my no-useless-null-checks rule.

[btmills]

Marking this as accepted after discussion in today’s TSC meeting. Since there are some complex parts here, we’d like to discuss the implementation details in a new RFC before starting work on a PR. It should help us decide where we draw the line on the extended checks and whether the implementation belongs in this rule or eslint-scope.

[nzakas]

@Gautam-Arora24 awesome! The next step here is to create an RFC.