Fails to propagate returned generic type as argument of another function

[TruffeCendree]

Bug Report

In the following example, wrongInference.properties.account inferred as unknown. I was hoping it would be inferred the same way as wellInferred.

// partialInferred.properties.name inferred as string, no other property as expected
const partialInferred = pickFromSchema(accountSchema, 'name')

// wellInfered.properties.account is well inferred
const wellInferred = propertiesToObjectSchema({ account: partialInferred })

// wellInferredAlternative.properties.account is well inferred
const wellInferredAlternative = {
  type: 'object',
  required: ['name'],
  additionalProperties: false,
  properties: pickFromSchema(accountSchema, 'name')
} as const

// wrongInferrence.properties.account inferred as `unknown`
const wrongInferrence = propertiesToObjectSchema({ account: pickFromSchema(accountSchema, 'name') })

I suppose this is a built-in mecanism to prevent too many recursions in typescript compiler.

🔎 Search Terms

• "typescript type propagation in nested function calls"
• "typescript max type recursion"
• "typescript wrongly inferred as unknown"

🕗 Version & Regression Information

I tried various versions in the playground UI, without finding one valid.
I am currently using version 4.9.4.

⏯ Playground Link

Full example available on playground.

💻 Code

interface BaseObjectSchema<Properties extends Record<string, unknown>> {
  type: 'object'
  properties: Properties
  additionalProperties?: boolean
  required?: ReadonlyArray<keyof Properties> | Array<keyof Properties>
}

/**
 * Returns a new schema that picks some of the properties of base schema.
 * Those properties are marked as required in the resulting schema.
 */
function pickFromSchema<
  Properties extends Record<string, unknown>,
  SubsetPropertyName extends keyof Properties & string,
  Return = Required<
    BaseObjectSchema<{
      [PropertyName in SubsetPropertyName]: PropertyName extends keyof Properties ? Properties[PropertyName] : never
    }>
  >
>(schema: BaseObjectSchema<Properties>, ...properties: SubsetPropertyName[]) {
  const newSchema = {
    type: 'object' as const,
    properties: {} as Record<string, unknown>,
    additionalProperties: false,
    required: properties
  }

  for (const property of properties) newSchema.properties[property] = schema.properties[property]
  return newSchema as Return
}

/**
 * Builds a new schema from a literal object, those keys are JSON schemas.
 * Some properties can be set as optional using opts.optional.
 */
function propertiesToObjectSchema<Properties extends Record<string, unknown>>(
  properties: Properties,
  opts: { optional?: (keyof Properties)[] } = {}
): Required<BaseObjectSchema<Properties>> {
  return {
    type: 'object' as const,
    properties,
    required: (Object.keys(properties) as (keyof Properties)[]).filter(key => !opts.optional?.includes(key)),
    additionalProperties: false
  }
}

const accountSchema = propertiesToObjectSchema({
  id: { type: 'string' },
  name: { type: 'string' },
  createdAt: { type: 'string', format: 'date-time' },
  updatedAt: { type: 'string', format: 'date-time' }
} as const)

// partialInferred.properties.name infered as string, no other property as expected
const partialInferred = pickFromSchema(accountSchema, 'name')

// wellInfered.properties.account is well infered
const wellInferred = propertiesToObjectSchema({ account: partialInferred })

// wellInferredAlternative.properties.account is well infered
const wellInferredAlternative = {
  type: 'object',
  required: ['name'],
  additionalProperties: false,
  properties: pickFromSchema(accountSchema, 'name')
} as const

// wrongInferrence.properties.account infered as `unknown`
const wrongInferrence = propertiesToObjectSchema({ account: pickFromSchema(accountSchema, 'name') })

🙁 Actual behavior

wrongInferrence.properties.account inferred as unknown

🙂 Expected behavior

Expecting wrongInferrence to have the same type as wellInferred and wellInferredAlternative,

[RyanCavanaugh]

There's some undesirable contextual inference going on here from the Properties extends Record<string, unknown> here. I recommend changing all instances of extends Record<string, unknown> to extends object; this fixes the issue.

Someone needs to create a simplified example that more clearly demonstrates the problem before we can investigate further.

[TruffeCendree]

@RyanCavanaugh

Switching to extends object solved both a performance issue and the inferred type. Thanks a lot.

On another side, it seems keyof of anything extending object is always inferred as never. Since the type of Properties can be inferred from the parameter, I supposed typescript could resolve itself the allowed keys, isn't it?

function example<
    Properties extends object,
    Schema extends { properties: Properties, required: (keyof Properties)[] }
> (schema: Schema) {}

// Type 'string' is not assignable to type 'never'.
example({ properties: { a: 1 }, required: ['a'] })

Playground link

---

After all, it works fine in that other example:

function example<Properties extends object> (properties: Properties, required: (keyof Properties)[]) {}

example({ a: 1 }, ['a'])

[dexx086]

I ran into a very similar issue. I think I was able to simplify my case even more to a quite basic use-case, I hope it has more potential to find the reason of this issue.

class Schema<SHAPE> {
    __shape?: SHAPE; // Just a holder for the generic type
}

class Entity { }

class Manufacturer extends Entity {
    name?: string
}

class Car extends Entity {
    manufacturer?: Manufacturer
}

const entity2schema = <
        CLASSTYPE extends typeof Entity,
        INSTANCE extends InstanceOfClass<CLASSTYPE>,
        RELATIONS extends {[K in keyof INSTANCE]?: Schema<any>} | undefined = undefined
    > (entityClass: CLASSTYPE, relations?: RELATIONS):
        Schema<INSTANCE & (RELATIONS extends undefined ? Record<never, never> : RELATIONS)>
    => /* empty implementation */ null as any;

// Good 'manufacturer' type
const manufacturerSchema = entity2schema(Manufacturer); // <-- stored in variable in advance
const carWithRelationsGood = entity2schema(Car, {
    manufacturer: manufacturerSchema // <-- using the inner schema from the variable
});

// Bad 'manufacturer' type
const carWithRelationsBad = entity2schema(Car, {
    manufacturer: entity2schema(Manufacturer) // <-- creating the inner schema INLINE! = Schema<any> will be the type for 'manufacturer' property instead of Schema<Manufacturer ...>
});

Full example is available on this playground link.

The main goal of my use-case (which is simplified to a maybe not too realistic example) is to have a function, that creates a Schema around a given entity, where also allows to specify its internal relations as well (with Schema around them as well).

And the issue happens exactly at these relations, because if a 'sub' schema is stored in advance in a variable (manufacturerSchema: with the same entity2schema call), the final type holds the 'sub' schemas inner type well (Schema<Manufacturer...>).

But if the entity2schema is called INLINE, then its final type will be Schema<any>, the inner schema type is lost.

So the only difference is that in the 'good' case the inner entity2schema call is stored in advance in a variable, where in the 'bad' case this (same) method is simply called inline. It should not really make any difference in the final type, right?

I hope my, a bit more simplifed case can be used better to find some reasons for the loss of such type information.

[dexx086]

Can we expect any update on this?

@RyanCavanaugh: your idea with the extends object is unfortunately not applicable to my simplified use case. Btw. I think my use-case is a bit different than @TruffeCendree's, but they possibly share a common root of cause?

In my most cases, sadly, this issue causes any types to be inferred badly (in contrast to @TruffeCendree's unknown), which hides many possible errors because if I try to assign anything to such badly inferred value, TS will allow everything as it's an any type.

I hope there's a chance to find some reason why it makes such difference if a function call is done in advance into a variable, or called inline during another generic function's call. Makes no sense to have any difference just because of this, right?

[RyanCavanaugh]

Can we expect any update on this?

Same thing I said before: Someone needs to create a simplified example that more clearly demonstrates the problem before we can investigate further. This example is much too long for anyone to investigate (prior to doing other work that is more immediately approachable)

[dexx086]

Same thing I said before: Someone needs to create a simplified example that more clearly demonstrates the problem...

@RyanCavanaugh I tried to simplify even more my use case, I think this is the most basic situation I can come up with to demonstrate the issue.
Do you think it is suitable now for an investigation?

Here's the more simplified code: Playground link

class Schema<SHAPE> {}
class Manufacturer {}
class Car {}

// Convert a class to Schema<...class...> but allowing to extend with additional properties which must also be a Schema<...> type
const entity2schema = <ENTITY, ADDITIONS extends Record<string, Schema<any>> | undefined = undefined>
    (entity: ENTITY, additions?: ADDITIONS): Schema<ENTITY & (ADDITIONS extends undefined ? {} : ADDITIONS)> => null as any; /* empty implementation */

// GOOD case
const manufacturerSchema = entity2schema(new Manufacturer()); // <-- stored in variable IN ADVANCE
const carWithManufacturerGood = entity2schema(new Car(), {
    manufacturer: manufacturerSchema // <-- GOOD: 'manufacturer' property = Schema<Manufacturer>
});

// BAD case
const carWithManufacturerBad = entity2schema(new Car(), {
    manufacturer: entity2schema(new Manufacturer()) // <-- BAD: 'manufacturer' property = Schema<any> (should be Schema<Manufacturer> like in the 'GOOD' case)
});

// And the only difference between GOOD and BAD case that is in GOOD case the same entity2schema call is used through an extracted variable, while in BAD case the same entity2schema function is called inline

[dexx086]

Meanwhile I figured out the source of the problem in my simplified example.

I had to change ADDITION extends undefined to undefined extends ADDITION and now the "bad" case has Schema<Manufacturer> type as well!

I still have some strange things going on with the code I created this simplified example from, but as for this example my issue is resolved.

@TruffeCendree: if your case is resolved as well, you might close this ticket.