Bug Report: TS creates contravariant intersection when K extending keyof T assigned new type

[RoboZoom]

Bug Report

🔎 Search Terms

T[K] assignment does not transform type of T

🕗 Version & Regression Information

Version: 4.8.4 to Present

This is bug became relevant when 4.8.4 released.

⏯ Playground Link

Playground link with relevant code

💻 Code

const joinSample = <T, K extends keyof T, U extends HasID>(
  parent: T,
  parentKey: K,
  children: U[],
) => {
  const keyArray = parent[parentKey] as string[];
  return {
    ...parent,
    [parentKey]: keyArray.map((k) => findOneById(children, k)) // Returns type U | undefined
  };
}

🙁 Actual behavior

The above code infers the output to joinSample as T & [x: string] : (U | undefined)[] which indicates that the T has the same key twice, with different types.

This is demonstrated in the playground when joined is typed to FullFoo. Untyped, when run, it produces an object that meets the criteria for FullFoo. When declared with type FullFoo, it raises an error.

🙂 Expected behavior

I would expect Typescript to substitute the type of parentKey from its previous value (in this case, always string[]) to (U | undefined)[]. The compiler knows that K is a keyof T - instead of creating a never condition, it should replace the type of T[K] to U.

[RyanCavanaugh]

The Playground link is very very long, and the sample here has unbound identifiers. Can you please provide a minimal sample that more clearly demonstrates the problem you're describing?

[RoboZoom]

This is as condensed as I can get it: Typescript Playground

Most of the space is scaffolding. The link above doesn't represent the desire to re-type the output in accordance with the generic input so that the object[K] has type U[], but I think it does represent the problem. Everything is still scaffolding to demonstrate the following:

const joinSample = <T, K extends keyof T, U extends HasID>(
  parent: T,
  parentKey: K,
) => {
  const keyArray = parent[parentKey] as string[];
  return {
    ...parent,
    [parentKey]: keyArray.map((k) => 123) // This assignment causes the problem
  };
}
//...
const joined: FullFoo = joinSample(sampleFoo, 'bars'); // Error - the type for joined is inferred as {id: string, bars: string[], bars: number[]}

The expectation is that when constructing the return object, it would understand the standard JS behavior that if you spread a parent, then add a specific child key, that it will overwrite the specific key if in the parent.

[RyanCavanaugh]

The problem here is that there isn't a correct type to describe what joinSample actually does, so TypeScript errs on the side of caution when describing it.

First let's fix joinSample to do what you want, then show why that's "wrong":

const joinSample = <T, K extends keyof T>(
  parent: T,
  parentKey: K,
) => {
  const keyArray = parent[parentKey] as string[];
  return {
    ...parent,
    [parentKey]: keyArray.map((k) => 123)
  } as T & Record<K, number[]>;
}

This behaves as desired.

However, if you invoked this as

const joined: FullFoo = joinSample<typeof sampleFoo, 'bars' | 'id'>(sampleFoo, 'bars');

then the implied behavior based on the type definition is that you'd have an object with bars: number[], id: number[], but that's obviously not what's happening -- the function can't (as in, can't possibly) runtime-enumerate all possible inhabitants of K to provide properties of it.

[fatcerberus]

Chalk up another use case for #27808.

[RoboZoom]

First, you if you're having to cast the output, then you aren't getting appropriate inference and I'd argue it's still a problem.

Second, your application of joinSample typing isn't an appropriate application of logical types. If you are looking at K as a union, then the output should be a union of each of the different possibilities driven by the input union.

So T has keys id and bars, then K is by definition id and bars, then in this case the output should reasonably be (and is certainly computable):

{ bars: number[]; id: string } | {bars: string[]; id: number[]}

This could be further narrowed when the function is called.

[fatcerberus]

@RoboZoom I think Ryan’s point is, ultimately, that there’s no way to represent that type operation generically (since your implementation is generic) using the type operators that are currently available. That would require spread types.

Basically there’s no type that TypeScript can currently infer that would accurately represent the output of this function.

[RyanCavanaugh]

First, you if you're having to cast the output, then you aren't getting appropriate inference and I'd argue it's still a problem.

The point of that example is to show that the inferred signature is the more correct one. If we gave it the type you're saying it should have, the output would be wrong.