Indirect mapped type drops property modifiers

[matt-tingen]

TypeScript Version: 3.4.0-dev.20190311

Search Terms: mapped modifier indirect optional readonly

Property modifies only seem to be copied in mapped types if the mapping is performed directly.

This seems to be a duplicate of #13724, but that issue was marked "Working as Intended" (for removing modifiers) around the release of 2.8 when the explicit syntax was added for adding/removing property modifiers. I was wondering if that conclusion would be reconsidered since there is a more explicit way of achieving that. I do understand that changing this behavior could be a potentially troublesome breaking change, though.

This came up in DefinitelyTyped/DefinitelyTyped#33742 as part of the implementation of React's JSX.LibraryManagedAttributes.

Code

type Foo = { bar?: string }
type Keys = keyof Foo

// okay; bar is optional
const direct: { [K in keyof Foo]: Foo[K] } = {}

// error; bar is required
const parentheses: { [K in (keyof Foo)]: Foo[K] } = {}
const indirect: { [K in Keys]: Foo[K] } = {}
const literal: { [K in 'bar']: Foo[K] } = {}

Expected behavior:
Creating a mapped type over the exact keys will copy property modifiers, resulting in no errors on any of the last 3 lines.

Actual behavior:
All 3 assignments error with Property 'test' is missing in type '{}' but required in type '{ test: string; }'.

Playground Link: Playground

Related Issues:
#13724 #28483 #24679

[dragomirtitian]

This is by designed as explained in the PR introducing homomorphic mapped types:

WIth this PR we preserve property modifiers in homomorphic (structure preserving) mapped types. A mapped type of the form { [P in keyof T]: X } is homomorphic with T (because it has the same set of properties as T) and now preserves the optional and readonly modifiers as they exist on the properties in T.

Also the other possibility for preserving modifiers is if we map over a type parameter constrained to keyof T as described here:

With this PR we more consistently propagate property modifiers in mapped types. For a given type parameter T, mapped types declared as { [P in keyof T]: X } or { [P in K]: X}, where K is a type parameter K extends keyof T, now propagate property modifiers from T. This in particular means that the predefined type Pick<T, K> now propagates property modifiers from T.

If typescript can trace a direct link to T in the in clause of the mapped type it will preserve modifiers. In the case of 'bar', that is just a string literal type so there is no link to any other type. In the case of Keys the type does come from the keys of another type but does not fit into the scenarios outlined above. Maybe something could be done to preserve the relation in this case but I suspect it would be a breaking change at this point.

[matt-tingen]

@dragomirtitian Is correct behavior for modifiers to be copied on homomorphic mappings or when TypeScript can trace a direct link to T?

I'm now realizing that copying modifiers with the string literal case could be quite confusing because there's no guarantee the mapping will remain homomorphic in future changes. If a property were later added to Foo, bar's modifiers would change due to a seemingly unrelated change.

I do acknowledge that this would be a breaking change, but I feel it's worth at least considering for three reasons:

1. If the correct behavior is for modifiers to be copied on homomorphic mappings, one could consider the other two error cases above (Keys, (keyof Foo)) to be bugs because the key type which is mapped over is keyof Foo (though indirectly).
2. The current behavior seems to have been done that way for the purpose of removing modifiers which now has it's own explicit syntax.
3. There is also precedent for similar breaking changes with e.g. Pick.

[dragomirtitian]

@matt-tingen The generalization with direct link was mine, perhaps not the best choice of words. The PR #12826 outlines clearly when modifiers are preserved.

One problem with preserving modifiers over Keys, at least currently, is that keyof is not always preserved in declarations (it is expanded to the actual literal string union). So while inside your code it might be possible to trace that Keys is not just a union of string literal types but that this union has a keyof origin, this information might be lost in declarations.

In general, I think it might be a bit confusing to map over a union and have modifiers randomly appear from a source that is not very clear at declaration site. At least with the current behavior it should be clear by looking just at the mapped type itself why those modifiers appear and once you know the build-in mapped types you don't have to think about it. With your proposed writing Record<Keys, boolean> could introduce modifiers unexpectedly from a type that is not present at all in Record<Keys, boolean>

[matt-tingen]

@dragomirtitian

I'm not familiar enough with TS internals to speak to the implementation, although I can see how it could be a large change for questionable benefit.

I can agree that excessive indirection here would lead to confusing behavior. To avoid that confusion we would have to draw the line somewhere and the existing line (only copying modifiers on direct mappings) seems like the only reasonable solution.

Thanks for talking through this with me.