Skip to content

Typescript Type Resolution Fails with generics of T | null #62608

Closed as not planned

Description

@adminnz

🔎 Search Terms

type indexing generics vscode intellisense resolution

🕗 Version & Regression Information

  • This is the behavior in every version I tried, and I reviewed the FAQ for entries about type indexing and intellisense

Note: While i've provided the playground link, the playground doesnt show type intellisense the same as vscode does, and so doesnt actually show a difference.

⏯ Playground Link

https://www.typescriptlang.org/play/?#code/C4TwDgpgBAygxgQwDYIE4GcoF4oG8BQUUAcgK4C2ARhKgFxQB2F1qA3PgL7v6iRQCyCENQA8AFQB82KGKgAfRqSRJuvaGPAQAgtIJEE9eMjToA2gCIyVGuYC68xcvZFK9QcIgim11BOdQ4Q0QUDAsrFjsHJidOVU0ZTQAhXUIoA1hgkzDmG3sFaJVU10UfKKVCokCM41DLHNRI-PL2LiA

💻 Code

type Scalars = {
  Number: number;
};

type Maybe<T> = T | null;

type TypeA = {
  a: Scalars["Number"] | null;
  b: Maybe<number>;
  c: Scalars["Number"] | null;
};

type TypeB = {
  a: Scalars["Number"] | null;
  b: number | null;
  c: Scalars["Number"] | null;
};

🙁 Actual behavior

I'm not sure if this is a typescript issue or a vscode issue.

In VSCode with typescript 5.9.3 installed with just a single file called typeissue.ts and the above code in it.

If you have a generic type definition that is:

type Maybe<T> = T | null;

And you use it in a type, any types after that generic usage that are using type indexing, will no longer correctly resolve to their types.

Hovering over TypeA will show:

Image

Where you can see the "c" field doesnt get "resolved" to number | null

Hovering over TypeB will show:

Image

Where you can see all fields are shown as number | null even when using type indexing.

🙂 Expected behavior

TypeA should show exactly the same as TypeB.

Additional information about the issue

This was found in a React + Typescript project we have, that is using React-Hook-Forms and graphql codegen types.
Where the types use type indexing, and we were trying to use the hook useFieldArray.
VSCode Typescript shows an error that there are no field arrays in the type.

Activity

  1. added
    Domain: LS: Type DisplayBugs relating to showing types in Quick Info/Tooltips, Signature Help, or Completion Info
    Possible ImprovementThe current behavior isn't wrong, but it's possible to see that it might be better in some cases
    on Oct 17, 2025
  2. TudorGR commented on Oct 19, 2025

    @TudorGR

    Hi! I'd like to work on fixing this issue.

    I've identified the root cause: when displaying type aliases in hover/quick info, the compiler was reusing the syntactic form of indexed access types (like Scalars["Number"]) and type aliases (like Maybe<number>) instead of resolving them to their actual types.

    I have a working fix that modifies the type serialization logic to resolve these types when displaying object type literals. Would this be the right approach?

  3. Subham-KRLX commented on Nov 5, 2025

    @Subham-KRLX

    Sir i would like to fix this issue can you please assign it to me.

  4. locked as resolved and limited conversation to collaborators on Dec 3, 2025
  5. RyanCavanaugh commented on Dec 3, 2025

    @RyanCavanaugh
    Member

    Closing language service bugs related to the 6.0 implementation. For more information, see #62827

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    7.0 LS MigrationDomain: LS: Type DisplayBugs relating to showing types in Quick Info/Tooltips, Signature Help, or Completion InfoHelp WantedYou can do thisPossible ImprovementThe current behavior isn't wrong, but it's possible to see that it might be better in some cases

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions