Request to expose getBigIntLiteralType on the TS Type Checker

[kirkwaiblinger]

🔍 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

1. What do you want to use this for?
   • This would be beneficial for a typescript-eslint rule
2. What shortcomings exist with current approaches?
3. 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.