Possible regression in error elaboration for optional properties

[tomrav]

Bug Report

It is my understanding that PR #47738 made changes to the elaborations of certain error messages. For me it had an adverse effect in a somewhat simple use case that includes optional parameters passed to an object.

I tried reproducing it in the TS playground, but version 4.6 is not yet available there and the latest nightly playground build doesn't seem to include this change yet.

Getting the following error in v4.6.2:
Type 'boolean' is not assignable to type 'string'

The error in v4.5.5 used to be:
Type 'true' is not assignable to type 'string | undefined'

I'll note that this happens whether undefined is allowed explicitly in the type definition, or defined only as an optional parameter.

🕗 Version & Regression Information

• This changed between versions 4.5.5 and 4.6

⏯ Playground Link

Here's a playground with the required setup, but as noted above, the playground doesn't seem to have the change that causes this issue yet.

Playground link with relevant code

💻 Code

type states = {
  state1?: string | undefined;
};

function x(y: states) {}

x({ state1: true });

🙁 Actual behavior

Error message ignores optional definition, or explicit undefined definition, and returns an error that only mentions the allowed primitives.

🙂 Expected behavior

Error message should mention undefined as an allowed value.

[MartinJohns]

as noted above, the playground doesn't seem to have the change that causes this issue yet.

Playgrounds nightly is over two weeks old. I've created microsoft/TypeScript-Website#2292. Most likely it's fixed on the next Playground deployment.

The latest nightly (20220302) still has the issue you mention.

[DanielRosenwasser]

I can see that there's some desire to talk about the possible values, but I'm tempted to say that this isn't a regression.

It's intentional that we give simplified diagnostics that don't leak literal types when they're not helpful (preferring boolean over true for example), and it's intentional that we drop undefined/null types when they function as noise (i.e. if the source type contained undefined, we will mention it, but won't otherwise).

Maybe there's a middle ground here? Something to do with whether a type explicitly names undefined, or something to do with the size of the union?

[fatcerberus]

if the source type contained undefined, we will mention it, but won't otherwise

type states = {
  state1: string | undefined;
};

function x(y: states) {
    return y;
}

x({ state1: true });

(property) state1: string | undefined
Type 'boolean' is not assignable to type 'string'. (2322)

Playground

[barak007]

With just a small adjustment the undefined is shown again this might be inconsistent with hiding it in the first place

type states = {
  state1: string | number |undefined;
};

function x(y: states) {
    return y;
}

x({ state1: true });

(property) state1: string | number | undefined
Type 'true' is not assignable to type 'string | number | undefined'.(2322)

Playground