Repository navigation
Typescript Type Resolution Fails with generics of T | null #62608
Description
🔎 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
💻 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:
Where you can see the "c" field doesnt get "resolved" to number | null
Hovering over TypeB will show:
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
TudorGR commentedon Oct 19, 2025
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 (likeMaybe<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?
Subham-KRLX commentedon Nov 5, 2025
Sir i would like to fix this issue can you please assign it to me.
RyanCavanaugh commentedon Dec 3, 2025
Closing language service bugs related to the 6.0 implementation. For more information, see #62827