Question about excess property checks and an opt-in strict option

[Matheus Mol (oMatheusmol)]

Hey! I've been reading through the typescript-go checker to learn how it works, and a question came up.

I noticed excess property checks only catch object literals directly. Like, this errors:

type Person = { name: string; age: number };
const p: Person = { name: "M", age: 21, active: true };

but if I store it in a variable first, it slips through:

const o = { name: "M", age: 21, active: true };
const p: Person = o; // no error

I know TS is structural on purpose so JS projects can migrate gradually, and that being strict by default would break everything.
But these days a lot of systems start as 100% TS. Would it make sense to have an opt-in option (like a tsconfig flag) to be stricter in those cases?

Just an idea, and I'm probably missing something. Is something like this doable, or is there a reason it wouldn't work? Mostly just curious and trying to learn.
Thanks!

[Ryan Cavanaugh (RyanCavanaugh)]

If you say that excess properties are never allowed in the subtype/assignability relation, you quickly run into problems.

For example, the difference between HTMLElement and HTMLImageElement is the existence of excess properties like alt and src. So this means that any function that currently accepts an HTMLElement can no longer accept an HTMLImageElement, which is by far not the intended design of 99.9% of those functions.

You need some way to distinguish cases which are OK with excess properties and cases that aren't, which is basically just the "exact types" proposal you can find in the TS issue tracker.

[Matheus Mol (oMatheusmol)]

Thanks for the detailed explanation! I was wondering if it would be possible to distinguish between user-created code and something from a library or JavaScript itself, but I understand that would be overly complex. Anyway, I really appreciate the clarity.