In TypeScript, what does a mapped type written as `{ [K in keyof T]: ... }` over a type parameter `T` preserve that a mapped type written as `{ [K in 'a' | 'b']: ... }` cannot, and why does that matter when `T` is an array or a tuple?

## Two shapes of mapped type A mapped type iterates a key set and produces a property per key. The syntax is the same either way, but the *source* of the key set changes the semantics profoundly. ```ts // (1) keys taken from a type parameter type Clone<T> = { [K in keyof T]: T[K] }; // (2) keys given as a fixed union of literals type Flags = { [K in "read" | "write"]: boolean }; // => { read: boolean; write: boolean } ``` Form (1) is called **homomorphic**: it maps over the keys of some other type, and the compiler keeps a link back to that type. Form (2) constructs a fresh object type out of thin air. Everything below follows from that link existing or not. ## What the homomorphic form preserves — modifiers ```ts interface Source { readonly id: number; nickname?: string; } type Copy = Clone<Source>; // { readonly id: number; nickname?: string } ``` `Clone` never mentions `readonly` or `?`, yet both survive. Because the key set is `keyof Source`, the checker knows which property each mapped member came from and copies its modifiers across. This is the default and it is usually what you want: a helper that transforms property *types* should not silently make optional fields required or drop immutability. (Deliberately adding or removing those modifiers is a separate mechanism with its own syntax; the point here is that doing nothing preserves them.) ## What it preserves — array and tuple structure This is the part that catches people out. An array type technically has a numeric index signature plus `length`, `push`, `map` and the rest. Naively mapping over its keys would produce a hideous object type with every array method mangled. Homomorphic mapping does not do that — it maps the *element* type and hands back an array: ```ts type Boxed<T> = { [K in keyof T]: { value: T[K] } }; type A = Boxed<string[]>; // { value: string }[] type B = Boxed<[number, string]>; // [{ value: number }, { value: string }] ``` Arrays stay arrays, tuples keep their length and their positions. This special case is what makes generic transform helpers usable on collection types at all, and it applies only to the literal `{ [K in keyof T]: ... }` form over a type parameter. Build the key set some other way and you get an object type instead. ## What it preserves — union distribution A homomorphic mapped type applied to a union distributes over the members rather than mapping the union's common keys: ```ts type C = Boxed<{ a: string } | { b: number }>; // Boxed<{ a: string }> | Boxed<{ b: number }> ``` That matters because `keyof` on a union is only the *shared* keys; without distribution, mapping a union would quietly discard the members' own properties. ## The fixed-key-union form ```ts type Keys = "a" | "b"; type Rec = { [K in Keys]: number }; // { a: number; b: number } ``` Here there is no source type. The compiler has nowhere to look up a `readonly` or a `?`, so every property is required and mutable — not because it decided to strip them, but because there is nothing to inherit. The result is always a plain object type; there is no way for this form to produce an array or a tuple, even if the values happen to be array types. This form is the right tool when you are *building* a shape from a known key set rather than *deriving* one from an existing type. ## Choosing between them Ask what the helper is for. - **Deriving from an existing type** — a transform that should behave like "the same shape, different value types" — write `{ [K in keyof T]: F<T[K]> }`. You get modifier preservation, array and tuple handling, and union distribution for free, and callers are not surprised when their `readonly` fields stay `readonly`. - **Constructing a shape from a key set** — a registry, a handler map, a set of flags — write the key union explicitly. You want uniform required members and you are not describing a transformation of anything. The failure mode is reaching for the second when you meant the first. A helper that rebuilds the property list by hand loses the array and tuple handling of every input type it is applied to, and callers get an unusable object type back. The bug does not show up in a simple `{ a: string }` test case, which is exactly why it survives review — it appears the first time someone applies the helper to a tuple. All of this is compile-time only. Whichever form you choose, the emitted JavaScript is unchanged: mapped types describe shapes for the checker and vanish at emit.