New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enhancement: [restrict-template-expressions] allow expressions with never
type
#5325
Comments
never
type>
The entire point of the lint rule is to ensure you're properly formatting your values for your users so that you don't leak "user-hostile" strings (like booleans, unconstrained decimals, improperly formatted lists, etc). This does mean, however, that in places you're creating strings that don't get seen by the user - for example console logs or thrown errors - then you'll see reports that you may not care about because you as the dev are happy to get "user-hostile" values in your strings.
Is it a good idea to turn on an option to allow Also given that this rule has existed for ~2 years and nobody has previously wanted such an option - it's likely not a case that too many people want to always allow? |
never
type>never
type
I second this. I wonder how many people got deterred (myself, for one) because the last request for the exact same thing was closed as WAI: #3069 The demand is certainly always there. I have yet to see a case where a |
I think it should be changed because It's impossible to check if use of If you are paranoid about something being Here's another use case: type Opt = "foo" | "bar"
function doThing(opt?: Opt) {
if (opt == null) {
return
}
if (opt === "foo") {
doFooThing()
return
}
if (opt === "bar") {
doBarThing()
return
}
// opt is `never` here.
// If we add another variant to Opt then a new error will show up here
// to remind us to handle the new case.
// If an unexpected value is passed anyways then we get an exception:
// "Invalid opt: value".
assertNever("opt", opt)
}
function assertNever(kind: string, value: never) {
throw new Error(`Invalid ${kind}: ${value}`)
} |
I can't find the PR on demand 😕 but I've experienced this annoyance before and think it's reasonable to want an option for the
|
I kinda have the same question for |
I've implemented |
My biggest issue with this is that ultimately you have absolutely no idea what you might get in your string. As an example - if for some reason the thing is an object, you'll end up with However if you instead did something like Ultimately by allowing It just seems like this is going against the philosophy of what the rule is trying to enforce - which is why, IMO, this is a valid error that should be reported in all cases, and should not be configurable. |
I mean, the type system is telling you that you won't be getting a string, period. Sure, TypeScript is unsound so sometimes code can run where something has a type that's different from what it's supposed to, but if that's true for As for your other comment that this issue hasn't come up in the past: I can only speculate, but I know that TypeScript has gotten better in recent versions at inferring |
It's not though, unless your
That is completely a strawman argument. In a nutshell you're saying "we can't trust the type system ever so why does it matter now?". OTOH In a lot of cases you can make an educated guess; for example if you're switching over a disjoint union's discriminant then the The way I see it your
For (1.i) - you should also probably assert it's of a specific type For (1.ii) - you know it's going to print garbage inside the template string - so you're going to want to nicely stringify it in some way. For (2) - you have no idea whether or not it'll create garbage - so you're going to want to nicely stringify it in some way. So by my reckoning it looks like there's not really a case where you want a |
Before You File a Proposal Please Confirm You Have Done The Following...
My proposal is suitable for this project
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 type
never
. This occurs, for example, if you have code like this:I don't see the benefit of the lint warning here, which complains that
foo1.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 type
never
. 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
Pass
Additional Info
This same logic should also apply to similar rules like
restrict-plus-operands
(no need to complain that an operand has typenever
), although I haven't checked to see how that rule behaves fornever
operands.The text was updated successfully, but these errors were encountered: