microsoft / microsoft/TypeScript

Check for missing property on union type causes failure in subsequent property checks

Open
#58,448 17 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Domain: check: Control Flow Help Wanted Possible Improvement
Dominant language
Go
Stars
111k
Forks
14.3k
Avg merge
1d 19h
Merged PRs (30d)
117

Description

🔎 Search Terms

"missing property", "property check", "type union", "control flow analysis"

🕗 Version & Regression Information
  • This is the behavior in every version I tried*, and I reviewed the FAQ for entries about property checks

*There was a minor change between 4.8 and 4.9 that changed the types but did not change the behavior: inference improved from never to incorrectUnionElement & Record<"key", unknown>.

⏯ Playground Link

https://www.typescriptlang.org/play/?ts=5.4.5#code/FASwdgLgpgTgZgQwMZQARIPYFsAOBGVAb2FVNRigQBMMwAbAT1QQC5UwBXLAI1gG4SZCtVqNU3Npx79gAX2ChIsRCnTYcAJiKDSwmvSat2XXjAHzgEBjjSZcqALw7UAHzW48zt3c0K4HMCQIEFpUGgB9AGdsKAgAC3AAcwAKAEptMjUwSIh3HEciWWZIvIFnEDhUZIAiBGrUcDz04kzMnwA6BHaIDABlCBgktIFWsgB6MdQAPQB+ZwtMiqrq7nrGn2bnNvV27m6+gaHUkdHUCem5zIWyJZqkNbAmjNOOpH3+wbAU463xydn5gpFpUanUGo8Ns9Rh0uj0PkcTqNzgCrkCbiCVg8ni0Xjs9nDDl9hr9SMjLmR5LIgA

💻 Code
interface comp1 {
    readonly a: number;
    readonly b: number;
}

interface comp2 {
    readonly a: number;
}

type comp =
    | comp1
    | comp2

function do_something() {
    const comp = {} as comp;

    if ("a" in comp) {
        comp.a.toString();
        // ^? comp
    }

    if ("b" in comp) {
        comp.b.toString();
        // ^? comp1
    }

    if ("c" in comp) {
        comp.c.toString();
        // ^? comp & Record<"c", unknown>
    }

    if ("a" in comp) {
        comp.a.toString();
        // ^? comp2
    }

    if ("b" in comp) {
        comp.b.toString();
        // ^? comp2 & Record<"b", unknown>
    }
}
🙁 Actual behavior

Every property check after the ("c" in comp) one fails to narrow correctly if the key is one that is only defined for some of the element types of the type union. Attempting to access the property after one of these checks results in unknown. As well, the narrowed variable in subsequent conditionals is an arbitrary(?) union element.

🙂 Expected behavior

The conditionals that come after the ("c" in comp) conditional should have the same behavior as the ones before it, as they are the exact same code.

Additional information about the issue

This was initially noticed in a more complicated context with assertions, that I can include here as a secondary example. This one is even more strange, as it is a check for a property that is only defined on some of the elements of the union and it blocks its own duplicate check later.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the provided TypeScript Playground repro and compare the union narrowing before and after the "c" in comp check. Trace the control-flow analysis and property-check handling involved in narrowing union types. Done means later checks narrow the same way as identical checks before the missing-property test, including the secondary example.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
compilers
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Clearly specified
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.