Const type parameters may resolve into non-const types when iterating over `Record<string, () => void>` parameter

[sanniassin]

🔎 Search Terms

const type parameters inference deep function return type

🕗 Version & Regression Information

• This is the behavior in every version I tried from 5.0.4 up to 5.9.3 and nightly builds, and I reviewed the FAQ for entries about type inference and const type parameters

⏯ Playground Link

https://www.typescriptlang.org/play/?ts=5.9.3#code/PQKhCgAIUgVALAppALgJwK6IMIHsB2AJgJYrEGQAOAhmipLgGapKQDGBJZB1ANpIgAelNIgDOY8vkhj4uDL0KR8iAG6I0kAEbJR1NkiXUi25NWW4AtLkoAaKDC0Z6xZgHdkAc0T00xJUwsyBxEpFJ8AsKiElIMmqIoGGjSxgCeKPDE+J4MGRosxnAAYhj4bNz4YkGi9tBB0lmMGohlyFp6ANZiDsDgKKmUyACSKBrUowDy6mglZRViADyws+VSVUKjRFUA3pAA2h2IqQBcMuhZngC6pwAUAJSQALwAfJCquP6QAL6vj1DFpVWBHWgk2hCqKmm-0gkAA-AC5mtIMBgJAhvgmqJWtpOlU3KQ5M4WMQQSJxJICNDIKdtlSYTC9gBpSBZSCHVKBZaA+bXBFAypMy6RMFVe5PV6NfKwABKPiS+FgA0QdPpMPhYpecFliWSisGKtVp0hGgA3CqvmbwCExPRqGI8JUUHrEEpHpAFv9rfQZXLdUrauxgd6VvNhS1wZBZRw0IQFja-NlbJANa8fTqFUrnvZnjd-tFcLxpmJTiMxpNpiG1ktK8Cs+AHpr84WNGJLV7A47na7IHaHTauzdaTCAELGDq3BuvQdU-ynADkWjHlgAjHOA187vYN5aUZBR-gOkVpABbDA2yBN9Qs-AoXCQAAGKcguz0hAIvFSLMIpwARIuDyuP4mt8959Eqe5jkeTyoEqgRel2AB0+4dCaQA

💻 Code

/**
 * The trueCondition part of the conditional expression should never be reached and be a no-op,
 * but if we get rid of the conditional expression or return anything other than TFunctions there,
 * then inference breaks
 */
type IterateOverFunctions<TFunctions extends { [key: string]: () => void }> =
  TFunctions extends never
    ? TFunctions // Inference breaks without this expression
    : {
        [K in keyof TFunctions]: TFunctions[K] extends () => infer TReturnType
          ? () => TReturnType
          : never;
      };

const asConstTyped = <
  const TReturnType,
  const TFunctions extends Record<string, () => TReturnType>,
>(
  resolvers: IterateOverFunctions<TFunctions>,
) => resolvers;

const constTyped = asConstTyped({
  Bank: () => ({
    id: 'bank-1',
  }),
});

// BankFn must resolve into `() => { readonly id: "bank-1"; }`
type BankFn = typeof constTyped.Bank;

🙁 Actual behavior

Without the seemingly meaningless conditional expression in IterateOverFunctions type constTyped.Bank resolves into

() => unknown

🙂 Expected behavior

IterateOverFunctions type without the conditional expression should resolve constTyped.Bank into the same narrowed down type as with it

() => {
    readonly id: "bank-1";
}

Additional information about the issue

The workaround in IterateOverFunctions doesn't work consistently and breaks when a more sophisticated iteration is going over the inferred types

[RyanCavanaugh]

This isn't meaningless, it changes whether the type is distributive or not

Paging resident reverse mapped type expert @Andarist

[Andarist]

This example tries to infer a reverse mapped type incorrectly. If you want to actually infer property positions, you need to use your T[K] (TFunctions[K] in the example) in some inferrable position. If we do it then it works:

type IterateOverFunctions<TFunctions extends { [key: string]: () => void }> = {
  [K in keyof TFunctions]: TFunctions[K] extends () => infer TReturnType
    ? (() => TReturnType) & TFunctions[K]
    : never;
};

That said, this type is somewhat weird but maybe because it has been reduced from a larger example. I don't see any value here in this infer TReturnType so this could just be simplified to:

type IterateOverFunctions<TFunctions extends { [key: string]: () => void }> = {
  [K in keyof TFunctions]: TFunctions[K] extends () => unknown
    ? TFunctions[K]
    : never;
};

Furthermore, the "outer" TReturnType in asConstTyped isn't used anywhere else than in the TFunctions' constraint. This can't be inferred anyhow, it actually does become unknown (given that's the constraint of TReturnType) so the TFunctions' constraint is effectively just Record<string, () => unknown>. Note also that this is an unrelated TReturnType to the one defined originally at infer TReturnType.

However, removing it loses the constness of those return types:

type IterateOverFunctions<TFunctions extends { [key: string]: () => void }> = {
  [K in keyof TFunctions]: TFunctions[K] extends () => unknown
    ? TFunctions[K]
    : never;
};

const asConstTyped = <const TFunctions extends Record<string, () => unknown>>(
  resolvers: IterateOverFunctions<TFunctions>,
) => resolvers;

const constTyped = asConstTyped({
  Bank: () => ({
    id: "bank-1",
  }),
});

type BankFn = typeof constTyped.Bank;
//   ^? type BankFn = () => { id: string; }

So there is some, kind of unexpected, value in that extra TReturnType type param that stays unused...

The simplest formulation of this signature that comes to my mind is this:

const asConstTyped = <const T,>(resolvers: {
  [K in keyof T]: () => T[K];
}) => resolvers;

const constTyped = asConstTyped({
  Bank: () => ({
    id: "bank-1",
  }),
});

type BankFn = typeof constTyped.Bank;
//   ^? type BankFn = () => { readonly id: "bank-1"; }

---

As to why TFunctions extends never ? TFunctions : ... changes the inferred results here - at the inference time TFunctions is still unknown and the compiler tries to infer into both targets (false type and true type of this conditional type). It likely succeeds in both cases and then just picks up the first inferred candidate, so the one gathered from the true type of this conditional type (TFunctions) and not the created reverse mapped type coming from the false type

[sanniassin]

@Andarist Thanks, so it seems that the problem has nothing to do with const typed parameters in the first place, but with how inference and reverse mapped types work.

That said, this type is somewhat weird but maybe because it has been reduced from a larger example. I don't see any value here in this infer TReturnType

You're right, the skimmed down example doesn't do anything meaningful.

The actual code implements a mock utility for tests, which enforces camelCasedPrefix_${number} format for ids on given mock entities (E.g. worKind_1 is fine, but WorKind-1 is not).

In broader terms, the idea is to enforce any constraints on string format, which can't be expressed without generics. As far as I understand, there's no way to declare a non-generic type like type ID = `${CamelCase<string>_${number}`, but we can do case check on the inferred exact string. Since enforcing camel case is quite cumbersome, here's a simplified version enforcing ids to have no leading zeroes in the numeric part.

type ID = `${string}_${number}`;
type GraphQLTypes = {
  Bank: {
    id: ID;
    createdBy: GraphQLTypes['User'];
  };
  User: {
    id: ID;
  };
};

type WithoutLeadingZeroes<T extends string> =
  T extends `${infer FirstCharacter}${infer RemainingCharacters}`
    ? FirstCharacter extends ''
      ? T
      : FirstCharacter extends '0'
        ? WithoutLeadingZeroes<RemainingCharacters>
        : T
    : never;

type WithoutLeadingZeroesInIdFieldSuffix<
  TFields extends Record<string, unknown>,
> = {
  [K in keyof TFields]: K extends 'id'
    ? TFields[K] extends `${infer Prefix}_${infer Suffix}`
      ? `${Prefix}_${WithoutLeadingZeroes<Suffix>}`
      : never
    : TFields[K] extends Record<string, unknown>
      ? WithoutLeadingZeroesInIdFieldSuffix<TFields[K]>
      : TFields[K];
};

const withoutLeadingZeroesInIdFieldSuffix = <
  TMocks extends {
    [K in keyof GraphQLTypes]?: () => Partial<GraphQLTypes[K]>;
  },
>(resolvers: {
  [K in keyof TMocks]: TMocks[K] extends () => infer R
    ? R extends Partial<GraphQLTypes[keyof GraphQLTypes]>
      ? () => WithoutLeadingZeroesInIdFieldSuffix<R>
      : never
    : TMocks[K]; // TMocks[K] must be referred somewhere within the conditional type, otherwise the R type is inferred incorrectly
}) => resolvers;

withoutLeadingZeroesInIdFieldSuffix({
  Bank: () => ({
    id: 'MyBank_01',
    // ^ reports Type '"MyBank_01"' is not assignable to type '"MyBank_1"'

    createdBy: {
      id: 'MyUser_01',
      // ^ reports Type '"MyUser_01"' is not assignable to type '"MyUser_1"'
    },
  }),
});

In the example above everything works as expected, even with non-const parameters, but the part with referring TMocks[K] here still looks ambiguous. The trick works, but is this a documented behavior I can read about in more details somewhere? Or I'm relying on undocumented specifics of how exactly the compiler does inference in conditional types and this might break if this part of the compiler gets changed?

  [K in keyof TMocks]: TMocks[K] extends () => infer R
    ? R extends Partial<GraphQLTypes[keyof GraphQLTypes]>
      ? () => WithoutLeadingZeroesInIdFieldSuffix<R>
      : never
    : TMocks[K]; // TMocks[K] must be referred somewhere within the conditional type, otherwise the R type is inferred incorrectly

[Andarist]

Yeah, I would also consider this to be somewhat iffy to rely on T[K] being in the target type in a position that isn't really meant to be matched up. I don't expect it to break any time soon but still...

I'd rewrite the example to this: TS playground

There is a problem with it though... it lost constness coming from the type parameter. I'm not sure why this doesn't fix it:

type WithoutLeadingZeroesInIdFieldSuffix<TFields> = {
  [K in keyof TFields]: K extends "id"
    ? TFields[K] extends `${infer Prefix}_${infer Suffix}`
-      ? `${Prefix}_${WithoutLeadingZeroes<Suffix>}`
+      ? `${Prefix}_${WithoutLeadingZeroes<Suffix>}` & TFields[K]
      : never
    : TFields[K] extends Record<string, unknown>
    ? WithoutLeadingZeroesInIdFieldSuffix<TFields[K]>
    : TFields[K];
};

Note that all of those work as expected in respect to return types and their constness: TS playground

[Andarist]

Oh, it works even without the intersection proposed above as long as you allow string types in WithoutLeadingZeroesInIdFieldSuffix:

type WithoutLeadingZeroes<T extends string> =
  T extends `${infer FirstCharacter}${infer RemainingCharacters}`
    ? FirstCharacter extends ""
      ? T
      : FirstCharacter extends "0"
      ? WithoutLeadingZeroes<RemainingCharacters>
      : T
-    : never;
+    : T;

This is kinda what you get by trying to emulate negated types. Right now, the values of id properties are not treated as const in my version of your type because the constraint of this conditional is never:

TFields[K] extends `${infer Prefix}_${infer Suffix}`
  ? `${Prefix}_${WithoutLeadingZeroes<Suffix>}`
  : never

It's never because Prefix and Suffix get replaced with string by the constraint computation and currently WithoutLeadingZeroes<string> is never. I'd have to think about it more but it feels like this might be a design limitation.