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

🔍 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

[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

[simonbuchan]

I would also suggest suggesting “Try adding two?: undefined to A” etc…

This is sound and simple.