Request to expose `getBigIntLiteralType` on the TS Type Checker
kirkwaiblinger opened this issue Β· comments
Kirk Waiblinger commented
π Search Terms
bigint, checker api, checker, external api
β Viability Checklist
- This wouldn't be a breaking change in existing TypeScript/JavaScript code
- This wouldn't change the runtime behavior of existing JavaScript code
- This could be implemented without emitting different JS based on the types of the expressions
- This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
- This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
- This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals
β 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
const falsyTypes = [
{
value: null,
type: checker.getNullType(),
},
{
value: undefined,
type: checker.getUndefinedType(),
},
{
value: false,
type: checker.getFalseType(),
},
{
value: '',
type: checker.getStringLiteralType(''),
},
{
value: 0,
type: checker.getNumberLiteralType(0),
},
{
value: -0,
type: checker.getNumberLiteralType(-0),
},
{
value: NaN,
type: checker.getNumberLiteralType(NaN),
},
]
// roughly,
if (falsyTypes.some(falsyType => checker.isTypeAssignableTo(falsyType.type, type)) {
// condition is necessary, don't report an error.
}
, 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 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.
- (answer to 2 and 3) The type flag