-
Notifications
You must be signed in to change notification settings - Fork 12.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
typeChecker.typeToString() should print most derived alias #19198
Comments
This might actually be intended behavior after all, albeit an unfortunate one: https://www.typescriptlang.org/docs/handbook/advanced-types.html
It's not clear why this would be desired, but as always I could definitely be wrong! 🤡 It also turns out that this section is no longer accurate: microsoft/TypeScript-Handbook#682 It's possibel it's the intended behavior but the naming of the first alias slipped in accidentally from other changes. |
Likely true at one point, but right now aliases actually do create a name that is used for Intellisense and errors. However, if you make aliases of another alias it just uses the first alias name; this has been marked as a bug, but it's possibly intended behavior: microsoft/TypeScript#19198
TypeScript Version: typescript@next
Code
Playground Link
Expected behavior:
Using the compiler API,
typeChecker.typeToString(signature.getReturnType())
ofexample
returns the most derived alias,Second<string>
Actual behavior:
typeChecker.typeToString(signature.getReturnType())
returnsFirst<string, string>
IntelliSense in the playground and vscode both show the same thing as
typeChecker.typeToString(returnType)
, so I assume they share the same underlying logic.I tried examining the type object itself to see if I could reach into private APIs to get it, but I couldn't find it. I also tried various formatting flags, but none of them seemed to give me the desired behavior.
I searched for existing issues on this, #17433 seemed similar but digging into it, I think it's different. It's also possible this behavior was intentional of course, if so, lmk. I'm using the compiler API to generate custom documentation for rxjs and there are sometimes a number of aliases used which simplify much more complex structures and hide internals.
I could try to take a crack at a patch if someone knows where I might find the applicable logic. Seems like it would need to be on the type metadata generation side, since I can't find it in the type returned from
signature.getReturnType()
?Cc/ @benlesh
The text was updated successfully, but these errors were encountered: