You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm working on some possible improvements to typescript-eslint's strict-boolean-expressions and no-unnecessary-conditions rules. These need to check for assignability of possibly falsy types.
, but we're missing the ability to check assignability of 0n.
Looks like the other falsy literal types were exposed in #50694, #52473, for similar reasons, but getBigIntLiteralType was not included.
π» Use Cases
What do you want to use this for?
This would be beneficial for a typescript-eslint rule
What shortcomings exist with current approaches?
What workarounds are you using in the meantime?
(answer to 2 and 3) The type flag PossiblyFalsy exists, and currently powers the no-unnecessary-condition rule. However, it has some drawbacks, such as not being set on the {} type, or other "object" types to which falsy values are assignable, see, e.g.let x: {toString: () => string} = 0n, which can cause false positives in the rule. Furthermore, the PossiblyFalsy flag doesn't indicate why the type is possibly falsy, and it could have significant value to be able to tell a user which falsy types are assignable to a type.
The text was updated successfully, but these errors were encountered:
π Search Terms
bigint, checker api, checker, external api
β Viability Checklist
β Suggestion
cc @jakebailey
Add
getBigIntLiteralType()
to the checker API.π Motivating Example
I'm working on some possible improvements to typescript-eslint's strict-boolean-expressions and no-unnecessary-conditions rules. These need to check for assignability of possibly falsy types.
So far, we can check
, but we're missing the ability to check assignability of
0n
.Looks like the other falsy literal types were exposed in #50694, #52473, for similar reasons, but
getBigIntLiteralType
was not included.π» Use Cases
PossiblyFalsy
exists, and currently powers theno-unnecessary-condition
rule. However, it has some drawbacks, such as not being set on the{}
type, or other "object" types to which falsy values are assignable, see, e.g.let x: {toString: () => string} = 0n
, which can cause false positives in the rule. Furthermore, thePossiblyFalsy
flag doesn't indicate why the type is possibly falsy, and it could have significant value to be able to tell a user which falsy types are assignable to a type.The text was updated successfully, but these errors were encountered: