Skip to content

Property ... is missing in type ... but required in type ... when uncertainty is introduced during assignment to variable of discriminated union type #54676

Description

Bug Report

🔎 Search Terms

No idea how to search for this.

🕗 Version & Regression Information

  • This is the behavior in every version I tried, and I reviewed the FAQ for entries about nothing

⏯ Playground Link

Playground link with relevant code

💻 Code

type A =
  | {
      prop: {
        type: "number";
        num: number;
        str?: undefined;
      };
    }
  | {
      prop: {
        type: "string";
        num?: undefined;
        str: string;
      };
    };

// Expected: No error
// Actual: Property 'str' is missing in type '{ type: "number"; num: number; }' but required in type '{ type: "string"; num?: undefined; str: string; }'.
const a: A = {
  prop:
    // Introducing uncertainty in the assignment
    // appears to be key to triggering this bug
    Math.random() > 0.5
      ? {
          type: "string",
          str: "hello",
        }
      : {
          type: "number",
          num: 123,
        },
};

🙁 Actual behavior

Type '{ prop: { type: "string"; str: string; } | { type: "number"; num: number; }; }' is not assignable to type 'A'.
  Type '{ prop: { type: "string"; str: string; } | { type: "number"; num: number; }; }' is not assignable to type '{ prop: { type: "string"; num?: undefined; str: string; }; }'.
    Types of property 'prop' are incompatible.
      Type '{ type: "string"; str: string; } | { type: "number"; num: number; }' is not assignable to type '{ type: "string"; num?: undefined; str: string; }'.
        Property 'str' is missing in type '{ type: "number"; num: number; }' but required in type '{ type: "string"; num?: undefined; str: string; }'.

🙂 Expected behavior

No error

Activity

  1. fatcerberus commented on Jun 16, 2023

    @fatcerberus

    In general, { foo: A | B } is not assignable to { foo: A } | { foo: B } (there are some exceptions, but that's the general rule). This happens to be safe with one property, but not when there are multiple. Since the uncertainty is specifically in the value of prop and not the entire object, the structure of the type should reflect that.

  2. FelixZY commented on Jun 16, 2023

    @FelixZY
    Author

    I see. For this particular case I wanted very specifically to have a single property and to do

    type ABase = {
      // ...
    }
    
    export type AString = ABase & {
      prop: {
        type: "string";
        num?: undefined;
        str: string;
      };
    }
    
    export type ANumber = ABase & {
      prop: {
        type: "number";
        num: number;
        str?: undefined;
      };
    }
    
    export type A = AString | ANumber;

    I guess this could be done with even more type variables or Extract instead but I find the lack of intellisense (vscode) on the second type parameter makes Extract a bit unfriendly/unsafe to use.


    EDIT:

    Solved this by doing:

    type AStringProp = {
      prop: {
        type: "string";
        num?: undefined;
        str: string;
      };
    }
    
    type ANumberProp = {
      prop: {
        type: "number";
        num: number;
        str?: undefined;
      };
    }
    
    type AProp = AStringProp | ANumberProp;
    
    export type A = {
      // ...
      prop: AProp,
    }
    export type AString = A & { prop: AStringProp };
    export type ANumber = A & { prop: ANumberProp };
  3. fatcerberus commented on Jun 16, 2023

    @fatcerberus

    You could write it like this:

    type ABase = {
      // ...
    }
    
    export type AStringProp = {
        type: "string";
        num?: undefined;
        str: string;
    };
    
    export type ANumberProp = {
        type: "number";
        num: number;
        str?: undefined;
    };
    
    export type A = ABase & {
      prop: 
        | AStringProp
        | ANumberProp
    };
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Design LimitationConstraints of the existing architecture prevent this from being fixed

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions