Inconsistent enforcement of allowed keys on an object when using 'extends'

[AustinGrey]

🔎 Search Terms

"extends", "mapped", "extra keys"

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about structural typing. There wasn't really much in there about mapped types or extends for me to look at.

⏯ Playground Link

https://www.typescriptlang.org/play?ts=5.4.3#code/KYDwDg9gTgLgBDAnmYcAqBDKBzY8C8cA3gFACQAZhBAFxwBKwAxtACYA8AzjFAJYB22ADRwArv1bAKA4KwB8AbnIAjLHUYsoHbn0Ejxk6f1mKSAXyUlQkWAmSoAwhH7TsoqBhi9n7cphx4AJL83Bj8TKigMMASnOhYuDAkcnCEpJTUTi682AD8dP6JwaHhwADaAERUEBUAunBRMaxxGmxcPALCcMYAbsBQcuRkud3AfVBDdAAKWF4YADbs6WQrZVNQEGAAchgAtqgCcADWwIgQFPEBMMUwYRGV1XW1dAZSMqxKK3BwZqZkqlAsq58pciiFbqVKgC6g0QNFYgxmG0dJ0RL1+oMViN0RMVtNZrwFkshqsAKK7XgwHb7OCHE5nC6FILgu7lCrQ2rPMQSN7GD5Db6-JQWEgkAD0ACoJSQ4BK4AARXmoDBwTi8XZgeaoCjiJheZwIAAWnjgAHcPGA4irblc4GFWLSYAByOIsbJuDz6-gICB2zhq7i071IFCqjAUPCIGUSsVWcDQeA68JeuBu1zuYBMmC+MiFWHw5qgvBCchAnL5ppxMsezzefjsQpyEtyAAUhQKCREaZydGrAEoXjyjLJiOQoHh3N7XsP+WZRd2PZmEngW+RltU6Mt-oPDO8SyszPv-mpiIfyGeyOvMs5XJuScod0rWEeyExN4e4GKxXAAOqGxC0nEMCGrwcT8BA8BhA0UAbFAuRDBeZ59pYC4Zlmq6XkMG6jis27crufJHhex5QO++4XleEDVneuEPvhT4vm+p4iF+https://www.typescriptlang.org/play?ts=5.4.3#code/KYDwDg9gTgLgBDAnmYcAqBDKBzY8C8cA3gFACQAZhBAFxwBKwAxtACYA8AzjFAJYB22ADRwArv1bAKA4KwB8AbnIAjLHUYsoHbn0Ejxk6f1mKSAXyUlQkWAmSoAwhH7TsoqBhi9n7cphx4AJL83Bj8TKigMMASnOhYuDAkcnCEpJTUTi682AD8dP6JwaHhwADaAERUEBUAunBRMaxxGmxcPALCcMYAbsBQcuRkud3AfVBDdAAKWF4YADbs6WQrZVNQEGAAchgAtqgCcADWwIgQFPEBMMUwYRGV1XW1dAZSMqxKK3BwZqZkqlAsq58pciiFbqVKgC6g0QNFYgxmG0dJ0RL1+oMViN0RMVtNZrwFkshqsAKK7XgwHb7OCHE5nC6FILgu7lCrQ2rPMQSN7GD5Db6-JQWEgkAD0ACoJSQ4BK4AARXmoDBwTi8XZgeaoCjiJheZwIAAWnjgAHcPGA4irblc4GFWLSYAByOIsbJuDz6-gICB2zhq7i071IFCqjAUPCIGUSsVWcDQeA68JeuBu1zuYBMmC+MiFWHw5qgvBCchAnL5ppxMsezzefjsQpyEtyAAUhQKCREaZydGrAEoXjyjLJiOQoHh3N7XsP+WZRd2PZmEngW+RltU6Mt-oPDO8SyszPv-mpiIfyGeyOvMs5XJuScod0rWEeyExN4e4GKxXAAOqGxC0nEMCGrwcT8BA8BhA0UAbFAuRDBeZ59pYC4Zlmq6XkMG6jis27crufJHhex5QO++4XleEDVneuEPvhT4vm+p4iF+cAAEKiPAwGgYB8EHiW3yCYJALUaen7fmgIFxDxUHWMw0QOv0sHniWyFAA

💻 Code

export type Target = {
	foo: Record<string, undefined>;
	bar: Record<string, undefined>;
};

export type Configuration<
	TargetInstance extends Target
> = {
	fooConfig?: TargetInstance["foo"] extends Record<string, never>
		? never
		: Partial<{
				[PropName in keyof TargetInstance["foo"]]: undefined;
		  }>;
	barConfig?: TargetInstance["bar"] extends Record<string, never>
		? never
		: Partial<{
				[EmitName in keyof TargetInstance["bar"]]: undefined;
		  }>;
};

/**
 * Define a simple function that wraps a target and it's configuration to assist in type safety
 */
export function configureTarget<
	Targ extends Target,
	Config extends Configuration<Targ>,
>(Targ: Targ, config: Config): undefined {
	return undefined;
}

configureTarget(
	{
		foo: {
			b: undefined,
		},
		bar: {},
	},
	{
		fooConfig: {
			b: undefined,
			c: {}, // Why is this not an error?
		},
	},
);

configureTarget(
	{
		foo: {
			b: undefined,
		},
		bar: {},
	},
	{
		fooConfig: {
			b: undefined,
			c: {}, // But this is?
		},
        barConfig: {} // This is an expected error
	},
);

🙁 Actual behavior

In one case, no errors are found, including on the extra key c, but in the other and error is found on the extra key 'c'

🙂 Expected behavior

'c' should either raise an error in both or neither cases.

Additional information about the issue

I thought this might be related to # 57860, but that's a regression in nightly and I can't imagine how that could effect prior versions (admittedly I don't understand that issue very well even after looking at the examples).

Honestly I don't actually know what the expected behaviour here is. I feel, given my understanding of 'extends' that it's likely the right behaviour to not have any error on 'c' in both cases. Since the 'fooConfig' object in both scenarios would extend the resulting mapped type it's supposed to fit into. But I could be wrong. The inconsistency was what had me pulling my hair out wondering what I had done wrong for a few hours yesterday :P

I do also apologize for the size of my reproduction, tried to make it as small as I could in the time I had.

[Andarist]

Admittedly, this is a little bit confusing. In the second example, it fails to infer Config since that empty barConfig: {} doesn't satisfy your constraint (Configuration<Targ>). So in this case, it errors on those excess properties as the target type is just Configuration<Targ>. On the other hand, in the first example, it manages to infer it successfully and it can't error there. The point of inference is to infer types more specific than the constraint and that's true about what it inferred there.

[fatcerberus]

Your playground link is broken, just to let you know.

Keep in mind, for future reference, that the excess property check is more of a built-in lint rule than a type check, so in general there's no guarantee that it will be consistently applied; the type rules themselves do allow excess properties, even in non-generic contexts.

Honestly I don't actually know what the expected behaviour here is. I feel, given my understanding of 'extends' that it's likely the right behaviour to not have any error on 'c' in both cases.

I'd be inclined to agree; T extends U is an explicit signal that you accept subtypes of U. It's probably a bug that EPC kicks in here at all.
edit: Andarist explained it above. EPC is done against Configuration<Targ> because generic inference from the object literal itself failed.

[RyanCavanaugh]

I don't think there's any way to come up with a consistent set of rules when there's an object that doesn't satisfy the constraint. Once there's a contradiction in the system, nothing's going to "make sense".

[typescript-bot]

This issue has been marked as "Not a Defect" and has seen no recent activity. It has been automatically closed for house-keeping purposes.