suggest in operator when accessing non-common property of union types

[Zzzen]

🔍 Search Terms

access to non-common property of union types, suggest in operator for union types

✅ Viability Checklist

My suggestion meets these guidelines:

• 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 feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

Background: https://twitter.com/kentcdodds/status/1420125238436655104?s=21

When accessing props that are not on all union types, tsc gives Property 'foo' does not exist on type 'XX', which is confusing to newcomers. We can suggest the in operator when it is used inside if condition.

📃 Motivating Example

type A = {one: string}
type B = {two: string}
type C = A | B

declare const thing: C

// 😕Before:
// Property 'two' does not exist on type 'C'.
//  Property 'two' does not exist on type 'A'.(2339)
if (thing.two) {
  // it's a B
}

// 😄After:
// Property 'two' does not exist on type 'C'.
//  Property 'two' does not exist on type 'A'.(2339)
// Did you mean to use `'two' in thing`?
if (thing.two) {
  // it's a B
}

💻 Use Cases

[MartinJohns]

Has been rejected several times, see #39065 / #38842.

Remember that objects are not sealed. You can assign object { one: 'abc', two: true } to A. The check for thing.two would succeed, but it's still not a B.

I just realized you suggest a different error message pointing to the in operator, not to allow this syntax.

But I'd like to point out that the in operator leads to a known unsoundness in the type-system. Like mentioned above, just because there's a two property doesn't mean it's actually a B. I think pointing newcommers to this is actually rather harmful.

[andrewbranch]

Yeah, I saw that tweet and was pretty horrified at all the responses that said to use in. It may or may not be an appropriate tool for the job, depending on how much you know about your values inhabiting A and B, which is obviously information we don’t have. As @MartinJohns points out, using in could be straight up wrong. @DanielRosenwasser, do you have any other ideas for an error message that would push beginners in the right direction here?

[Zzzen]

You're right. I should have proposed a better error message instead of a specific fix that may be wrong.

We can probably learn something from rust.

https://learning-rust.github.io/docs/e1.smart_compiler.html

[RyanCavanaugh]

Here's what I would propose (not promising to take a PR on this, just my own opinion):

• If there's a discriminant (we have logic that can detect this), suggest "Check for expr.prop === 'A'". This will seem like ✨magic✨ and people will love it, especially with a quickfix (??)
• If there's not a discriminant, but the property is sourced from a type that also has a constructor function, suggest using instanceof. Again this will be magic
• If there's not a discriminant and there's no plausible instanceof, we may as well give up and suggest in, since there's unlikely to be a better way to guard yourself in -- many people would type assert here instead, which is obviously much more unsound than in

[RyanCavanaugh]

cc @DanielRosenwasser for feedback on that

[simonbuchan]

I would also suggest suggesting "Try adding two?: undefined to A" etc..

This is sound and simple.