Fixed member completions for NoInfer-wrapped unions
#60271
Conversation
typescript-bot
added
the
For Uncommitted Bug
|
This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise. |
|
Looks like you're introducing a change to the public API surface area. If this includes breaking changes, please document them on our wiki's API Breaking Changes page. Also, please make sure @DanielRosenwasser and @RyanCavanaugh are aware of the changes, just as a heads up. |
| @@ -5637,6 +5637,7 @@ export function getPropertiesForObjectExpression(contextualType: Type, completio | |||
| } | |||
|
|
|||
| function getApparentProperties(type: Type, node: ObjectLiteralExpression | JsxAttributes, checker: TypeChecker) { | |||
| type = checker.unwrapNoInferType(type); | |||
There was a problem hiding this comment.
At first, I considered unwrapping it in the public getContextualType (and alikes). But since NoInfers are not unwrapped when they contain structured types etc it wouldn't really address everything.
My line of thinking was that the API user likely shouldn't be concerned with NoInfer types all that much and it would be simpler if they just wouldn't be observable by the API users. But currently they will always be - we can obtain { prop: NoInfer<A> }, then get that property and end up with a NoInfer type easily.
So it's pretty impractical to unwrap those in the API layer, there are just too many places where the user interacts with the types and, perhaps, my initial instinct that NoInfers should be hidden from the API users wasn't good anyway.
So I decided I might very well just uwrap it here since that's something than an external API user would have to do anyway. It feels utterly annoying to deal with those NoInfers though. I'd expect most of the "get me a type" calls have to be wrapped with this unwrapping call. It's such an easy mistake to make.
But, in general, NoInfer<Structured> types behave almost the same as their wrapped base types. So I'm thinking now that maybe it's just the union case that gets in a way as that's not a union per-se but yet it's also a union for actual practical purposes.
So perhaps a better fix would be to distribute NoInfer over unions? That has some drawbacks for huge unions as we'd produce an equally huge distributed output union though.
fixes #60253