Unexpected lack of type error when the `exactOptionalPropertyTypes` flag is not set

[ugultopu]

Bug Report

🔎 Search Terms

is:issue exactoptionalpropertytypes

🕗 Version & Regression Information

This changed between versions 4.4.3 and later.

⏯ Playground Link

Playground link with relevant code

💻 Code

type BaseEntity = Object;

type DrillDownToEntity<T> = T extends BaseEntity ?
    T : T extends ReadonlyArray<infer U> ? DrillDownToEntity<U> : never;

type Relations<T extends BaseEntity> = {
    [K in keyof T as DrillDownToEntity<T[K]> extends never ? never : K]?: Relations<DrillDownToEntity<T[K]>>
}

/**
 * If T is not array-like, replace it with U. If it is, replace it with same level of arrays of U.
 */
type ChangeType<T, U> = T extends Array<infer A> ? Array<ChangeType<A, U>> : U;

type PickKeysInRelation<T extends BaseEntity, R extends Relations<T>> = {
  [K in keyof T as DrillDownToEntity<T[K]> extends never ? K : (K extends keyof R ? K : never)]: K extends keyof R ? ChangeType<T[K], PickKeysInRelation<DrillDownToEntity<T[K]>, R[K]>> : T[K]
}

🙁 Actual behavior

Following error occurs even when exactOptionalPropertyTypes flag is set.

Type 'R[K]' does not satisfy the constraint 'Relations<DrillDownToEntity<T[K]>>'.
  Type 'R[string] | R[number] | R[symbol]' is not assignable to type 'Relations<DrillDownToEntity<T[K]>>'.
    Type 'R[string]' is not assignable to type 'Relations<DrillDownToEntity<T[K]>>'.
      Type 'Relations<DrillDownToEntity<T[string]>> | undefined' is not assignable to type 'Relations<DrillDownToEntity<T[K]>>'.
        Type 'undefined' is not assignable to type 'Relations<DrillDownToEntity<T[K]>>'.(2344)

🙂 Expected behavior

No such error to occur, since when exactOptionalPropertyTypes flag is set, R[K] cannot be undefined according to the type definition.

ℹ️ Further information

The error is gone when I select 4.5.0-beta or Nightly (which is v4.5.0-dev.20211007 as of now). However, it is gone in these versions even when the exactOptionalPropertyTypes flag is not set. If my understanding is correct, the error should actually be there when this flag is unset, hence not sure why the error is gone in these versions even with the flag is unset.

Also, the following attempt to workaround this error does not work either:

type PickKeysInRelation<T extends BaseEntity, R extends Relations<T>> = {
  [K in keyof T as DrillDownToEntity<T[K]> extends never ? K : (K extends keyof R ? K : never)]:
    K extends keyof R ?
        (R[K] extends Relations<DrillDownToEntity<T[K]>> ? ChangeType<T[K], PickKeysInRelation<DrillDownToEntity<T[K]>, R[K]>> : never) :
        T[K]
}

[ugultopu]

@andrewbranch Well, both titles are valid technically. The former title is valid on v4.4.3, whereas apparently the latter title is valid on later versions. If the current behavior is incorrect on v4.4.3, then AFAICT this is a bug on v4.4.3 and should be fixed on v4.4.N, where N > 3.

[andrewbranch]

We don’t put all bug fixes into patch releases, only super critical ones. The fix for 4.4.3 will go out in 4.5. The behavior you’re currently seeing in nightly will probably not be addressed right away. It would be helpful if you could come up with the smallest repro possible that doesn’t depend on any external libraries.

[ugultopu]

@andrewbranch Removed external library from the code sample.

[RyanCavanaugh]

In 5.9, this isn't an error regardless of EOPT. Is the bug fixed? It wasn't clear from OP if an error is expected sometimes here or not (didn't dig too deep on it)

[andrewbranch]

Ignoring versioning confusion, the expected behavior was to have an error:

the error should actually be there when this flag is unset

Re-looking at it, the expectation is that the base constraint instantiation of R[K] where R extends RelationsandK extends keyof Tshould includeundefinedbecause of the?token in theRelationsmapped type. That seems like it might be right, but I don’t actually think indexed access on optional mapped types is governed byexactOptionalPropertyTypes(nor evennoUncheckedIndexedAccess). I think this instantiation of Relationsis creating an index signature whose value type lacksundefined` post-4.3, which seems inconsistent with the zero-order instantiation:

type HashMap<T> = {
  [K in keyof T]?: string
}

type V = HashMap<any>[string]
//   ^? string | undefined

The behavior in this snippet is independent of exactOptionalPropertyTypes and noUncheckedIndexedAccess.

There could be a reason the mapped type as key remapping should remove undefined from the domain in this instantiation, but I can’t immediately see it.