In mapped types with key remapping, any property involving a generic type argument is dropped.

[martaver]

Bug Report

When performing key remapping in mapped types, any property involving a generic type argument is dropped from the resulting type.

🔎 Search Terms

Mapped types with generic properties
Key remapping with generic properties
Properties with generic type dropped from mapped type with 'as' key remapping

🕗 Version & Regression Information

I first noticed it in 4.9.5 and still exhibited in nightly (5.1.*). Tried every version in playground down to 4.1.*, same behavior.

This is the behavior in every version I tried, and I reviewed the FAQ for entries about Type System Behavior, Classes, Generics.

⏯ Playground Link

Playground link with relevant code

💻 Code

export type FilterNothing<T> = { [P in keyof T as T[P] extends T[P] ? P : P]: T[P] }

class Test<Z> {
 foo(args: FilterNothing<{ key: number, value: Z, bar: Date }>) {

 const { key, value, bar } = args; // value is missing
 }
}

🙁 Actual behavior

value is omitted from the resulting type, even though all properties P are emitted. Any property that has a type involving a generic type parameter always gets dropped from the key remapping.

🙂 Expected behavior

value to be on the resulting type as Z, since its key would be emitted and type looked up by T[P].

[Andarist]

I bet that your real-life example looks quite different and I'm not sure if that would be fixable.

This simple case could potentially be fixed but this conditional type stays deferred in the generic context. I'm not exactly sure why but there are some tests with // error annotations on them. This suggests that it is intended... but again, i don't know the exact reason.

The potential fix that I had in mind for this is pretty easy:

diff --git a/src/compiler/checker.ts b/src/compiler/checker.ts
index b975b98488..0a781288bd 100644
--- a/src/compiler/checker.ts
+++ b/src/compiler/checker.ts
@@ -17780,7 +17780,7 @@ export function createTypeChecker(host: TypeCheckerHost): TypeChecker {
 // Instantiate the extends type including inferences for 'infer T' type parameters
 const inferredExtendsType = combinedMapper ? instantiateType(root.extendsType, combinedMapper) : extendsType;
 // We attempt to resolve the conditional type only when the check and extends types are non-generic
- if (!checkTypeDeferred && !isDeferredType(inferredExtendsType, checkTuples)) {
+ if (checkType === inferredExtendsType || !checkTypeDeferred && !isDeferredType(inferredExtendsType, checkTuples)) {
 // Return falseType for a definitely false extends check. We check an instantiations of the two
 // types with type parameters mapped to the wildcard type, the most permissive instantiations
 // possible (the wildcard type is assignable to and from all types). If those are not related,

[martaver]

Do you think the problem is in conditional types? If I test the equivalent Noop without the as key remapping, value is persisted:

type FilterNoProps<T> = { [P in keyof T]: T[P] extends T[P] ? T[P] : T[P] }

This comment might give us a hint:

// We attempt to resolve the conditional type only when the check and extends types are non-generic

So maybe it's that as in key remapping drops unresolved (deferred) types?

I'm not sure about my terminology here, so please correct me if what I'm saying makes no sense...

[Andarist]

So maybe it's that as in key remapping drops unresolved (deferred) types?

Yes, that's exactly what happens. This conditional type stays deferred and thus it fails isTypeUsableAsPropertyName check later on and ain't added as a property to the result of this whole mapped type within this generic context.

[martaver]

Is there a reason why key remapping should drop deferred types, then, or is it just incomplete?

[Andarist]

How do you access a property name that is typed using a deferred type? This conditional type decides if that property got filtered out from the type or not. If TS can't resolve it immediately then it can't assume that it's there so it becomes inaccessible.

[martaver]

That makes sense! So in other words, "How can you name a property based on a type that hasn't been resolved?"

In the cases I provide, though, the only possible outcomes are never or P (a valid property name). never should be dropped, obviously...

Maybe typescript should attempt to resolve the conditional before evaluating the property name? That way it would be able to tell whether or not it can name the property, even if the type contains generic arguments.

[Andarist]

never is dropped from the union but it has a special meaning here - it makes the mapped type filter out given property. So it's not exactly the same.

I think that it's best to visualize this outcome as equivalent to:

type Preserved = { a: 1, b: 2 }
type Filtered = { a: 1 }

type Both = Preserved | Filtered

type Ok = Both['a']
type Err = Both['b']

Conceptually a very similar thing happens, at the generic level if your property name stays deferred it can end up being both (P or never). This makes us "expand" the result into a union of all possible outcomes.

[martaver]

But in the example I provide:

export type FilterNothing<T> = { [P in keyof T as T[P] extends T[P] ? P : P]: T[P] }

There isn't anything indeterminate emitted... the conditional type's output is always P. If typescript tried to resolve this, it would know that the fact that T[P] is generic doesn't matter - and know enough to leave the property included.

Instead it doesn't even attempt it... it just sees a deferred type and lazily (in the sense of little or no effort) drops it.

[Andarist]

This is what I mentioned in one of the previous comments (here). I'm not sure why this particular type has to be deferred.

[martaver]

Ahhh... okay a little more context then...

I came across the problem trying to filter our properties that have been explicitly marked as never from a type:

type FilterNeverProps<T> = { [P in keyof T as T[P] extends never ? never : P] : T[P] }

class Test<Z> {
 foo(args: FilterNeverProps<{ key: never, value: Z, bar: Date }>) {

 const { key, value, bar } = args; // 'key' is dropped, but 'value' is too...
 }
}

In the above, I expected key to be dropped, and Z to be retained. When I sought help, I was told that since never is assignable to Z, typescript had to consider all indeterminate cases and also dropped it.

So I tried a different approach, using a branded type to mark properties I wanted dropped:

interface ignore { readonly __ignore__: "__ignore__" }

type FilterIgnoreProps<T> = { [P in keyof T as ignore extends T[P] ? never : P]: T[P] }

class Test<Z> {
 foo(args: FilterIgnoreProps<{ key: ignore, value: Z, bar: Date }>) {

 const { key, value, bar } = args; // 'key' is dropped, but again 'value' is dropped too...
 }
}

In this approach, I flipped the extends to ensure that only properties that were exactly of the ignore type are dropped. In this case, never is still assignable to Z, but if Z is never then the conditional resolves as P because ignore is NOT assignable to never:

type x = ignore extends never ? 1 : 0; // Resolves as '0'

That's what led me to try a noop conditional where both branches return P and I found that no matter what I tried, any generic type is ALWAYS dropped when used in an as key remapping.

The same is not true in a simple Identity mapped type, where Z and never are all passed through:

type Identity<T> = { [P in keyof T]: T[P] }

class Test<Z> {
 foo(args: Identity<{ key: never, value: Z, bar: Date }>) {

 const { key, value, bar } = args; // 'value' DOES exist 
 }
}

So I thought this inconsistency might be a bug!

---

Edited to emphasise that in the last case value does get passed through as Z in the mapped type.

[RyanCavanaugh]

The inconsistency is an intentional difference.

You're one of the lucky 10,000 today to learn about homomorphic mapped types - see #26063

[Andarist]

Ryan Cavanaugh (@RyanCavanaugh) do you happen to know why T extends T ? 1 : 0 gets deferred?

[martaver]

I don't quite see the link between what I'm pointing out and homomorphic mapped types, Ryan Cavanaugh (@RyanCavanaugh) do you think you could explain?

Is it that the as operator transforms the keys as a homomorphic mapped type? In that case, which rule is filtering out the value property? Particularly in the case of the noop where all properties will resolve as P regardless of their type?

I don't understand why as T[P] extends T[P] ? P : P should drop any properties, ever, even if their types were never.

In fact, in the noop key remapping, properties whose type are explicitly never are preserved, while Z is dropped!

e.g.

type FilterAsNoProps<T> = { [P in keyof T as T[P] extends T[P] ? P : P ]: T[P] }

class Test<Z> {
 foo(args: FilterAsNoProps<{ key: never, value: Z, bar: Date }>) {

 const { key, value, bar } = args; // 'value' should exist 
 }
}

In the above:

1. key is never, but is preserved, because the resolved as type is always P.
2. Z COULD be never, but in that case should be treated like key, which is: preserved.
3. Z, if its NOT never, should just be considered Z, and preserves, since the as type will still always be P.

But in case 3 it's dropped...?

What am I missing here?

P.S. I've actually noticed this in many cases that the possibility of a generic type being assigned never gets in the way of doing otherwise very useful things.

[RyanCavanaugh]

I think the example given is degenerate to the point that it's not useful to discuss. If you write T[P] extends T[P] ? P : P expecting it to just exactly like P, well, then you should obviously just have written P, P is already the thing that behaves exactly like P. Discussing the behavior of that example is misleading because it has invariants that real usages with different behavior would not.