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

• I believe my proposal would be useful to the broader TypeScript community (meaning it is not a niche proposal).

Link to the rule's documentation

https://typescript-eslint.io/rules/restrict-template-expressions#allownullish

Description

The restrict-template-expressions rule currently complains if the template expression has typenever. This occurs, for example, if you have code like this:

// more variants may be added to Foo in the futuretypeFoo=|{type:"a",value:number};functioncheckFoosAreMatching(foo1:Foo,foo2:Foo){if(foo1.type!==foo2.type){// since Foo currently only has one variant, this code is never run,// and `foo1.type` has type `never`.thrownewError(`expected${foo1.type}, found${foo2.type}`);// ^ Invalid type "never" of template literal expression.}}

I don't see the benefit of the lint warning here, which complains thatfoo1.type andfoo2.type have typenever and says,Invalid type "never" of template literal expression.

I am suggesting changing the lint rule's behaviour to allow template expressions to have the typenever. This could be done as a new option calledallowNever, although I personally don't see the point in giving the option to disallownever in template expressions. Why should this lint rule be complaining about dead code?

Fail

constfoo:"a"|null;constbar:"a";if(foo!==bar){// `foo` has type `null`, which is not allowed// with the default options for this rulethrownewError(`${foo} and${bar}arenotequal);}

Pass

constfoo:"a";constbar:"a";if(foo!==bar){// `foo` and `bar` have type `never`, which should be allowed// by this rulethrownewError(`${foo} and${bar}arenotequal);}

Additional Info

This same logic should also apply to similar rules likerestrict-plus-operands (no need to complain that an operand has typenever), although I haven't checked to see how that rule behaves fornever operands.