Member-wise checks give incorrect errors for type assertions

[DanielRosenwasser]

Playground Link

// No error. ✅
let okay = { id: 123, blah: "extra" } as { id: number };

// Errors. ❌
let waat = [{ id: 123, blah: "extra" }] as { id: number }[];
// ~~~~
// Conversion of type '{ id: number; blah: string; }[]' to type '{ id: number; }[]' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the expression to 'unknown' first.
// Type '{ id: number; blah: string; }' is not comparable to type '{ id: number; }'.
// Object literal may only specify known properties, and 'blah' does not exist in type '{ id: number; }'.

Expected: Both of these type assertions should consistently apply the appropriate relationship check, and both should be free of errors.

Actual: The first assertion is free of errors, while the second has an excess property error.

Similar example I found over at https://github.com/microsoft/TypeScript/pull/55152/files#r1275497478:

let okay = { foo: "" } as { id: 123 };
// ~~~~~~~~~~~~~~~~~~~~~~~~~~
// Conversion of type '{ foo: string; }' to type '{ id: 123; }' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the expression to 'unknown' first.
// Property 'id' is missing in type '{ foo: string; }' but required in type '{ id: 123; }'.

let waat = [{ foo: "" }] as { id: 123 }[];
// ~~~
// Conversion of type '{ foo: string; }[]' to type '{ id: 123; }[]' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the expression to 'unknown' first.
// Type '{ foo: string; }' is not comparable to type '{ id: 123; }'.
// Object literal may only specify known properties, and 'foo' does not exist in type '{ id: 123; }'.

[DanielRosenwasser]

I'm guessing this behavior has probably been around for at least a few years, so realistically this issue is a suggestion that we loosen behavior that...maybe nobody finds objectionable.

That said, we now have satisfies. If you want the error, you should probably use that.

// Errors as expected! ❌
let okayA = { id: 123, blah: "extra" } satisfies { id: number };
// ~~~~

// Errors as expected! ❌
let okayB = [{ id: 123, blah: "extra" }] satisfies { id: number }[];
// ~~~~

Not sure what others think here.

[fatcerberus]

As a user, any case that involves an EPC error on a type assertion feels like a clear bug to me. EPC is designed as a linter-style check for catching wrong properties in object literals; a type assertion feels like a strong enough indicator of intent to rule out such mistakes (IOW the user is likely casting because the “wrong” properties are intended to be there).

I’d understand the team not wanting to take a breaking change on behavior that nobody has yet complained about, though.