Multiple keys being remapped to same key causes unstable modifier propagation

[cm-ayf]

🔎 Search Terms

Mapped Types, Key Remapping

🕗 Version & Regression Information

• This has been happening since first release of key remapping at 4.1 (tested with v4.1.5 at Playground) until nightly (tested with v6.0.0-dev.20250822 at Playground).

⏯ Playground Link

https://www.typescriptlang.org/play/?#code/C4TwDgpgBAShC2BDMBpCIAqB7AkgOwEtgDEAbABUQCdgAeDAPigF4oBvAKCm6gG0UoBPFADW6LADMoGKIgDOUARAAewCHgAmCgAYASNkIkQqUAGIEqc4AF8AdPsPGoAfThXr2qAH4zFq1AAuRQBdILwAV1JSAG4Oa1iOUEhfS2AAeTBiLDwyFlgEZDRMXEJiMkoaWk4eKAB6WqgAPS8uHgAiCSwsWwAjajavIKsqIQBzWJqOrt7EAC82sPD4HuNY6wYEpOhzVLgAR3CLCA08uCRUdGx8IhIKajpqnnqmlsnO7r75xeXV1u4pj79QZQYZjNYbDhAA

💻 Code

type RemapKeyToInitialPart<T> = {
    [K in keyof T as K extends `${infer First}.${infer _Rest}` ? First : K]: null;
};

type FirstOptional = RemapKeyToInitialPart<{
    // ^?
    "foo.bar"?: string;
    "foo.baz": number;
}>;

type FirstRequired = RemapKeyToInitialPart<{
    // ^?
    "foo.baz": number;
    "foo.bar"?: string;
}>;

🙁 Actual behavior

type FirstOptional and type FirstRequired results in different types:

• type FirstOptional has optional property foo
• type FirstRequired has required property foo

🙂 Expected behavior

type FirstOptional and type FirstRequired results in same type. I would expect it to be same as type FirstRequired type FirstOptional.

Additional information about the issue

My motivation was to implement a utility type Expand<T> which transforms { "foo.bar": number } to { foo: { bar: number } } (playground)

[jcalz]

I agree that you want the output not to depend on the order of properties in the input, since order of properties is supposed to be unobservable.

But I don't see why you expect the property to be required. When you collapse multiple input properties to a single property with key remapping you get the union of the property types, e.g:

type Collapse<T> = { [K in keyof T as "x"]: T[K] }
type X = Collapse<{ a: string, b: number, c: boolean }>
//   ^? type X = { x: string | number | boolean; }

Playground link

So I'd expect to see the sort of thing you get when you combine unions of optional-and-required, which is effectively optional (you can think of | undefined as being sort of optional, and so if any one of the inputs is optional and included | undefined, the output should also).

[cm-ayf]

@jcalz Thank you for the comment! I've changed the description.

By the way, the selection would be a sort of design decision, so my (stronger) expectation is that TypeScript team decide whether it should or should not be optional.

[RyanCavanaugh]

Discussed at design meeting:

• a merged property should be optional if any of its input properties are optional
• same for readonly