Intersected type variable with a recursive constraint fails to infer

[Andarist]

🔎 Search Terms

intersection type variable parameter inference recursive constraint

🕗 Version & Regression Information

• This is the behavior in every version I tried

⏯ Playground Link

https://www.typescriptlang.org/play?ts=5.3.0-dev.20230906#code/C4TwDgpgBAysCGwIGED2A7AZgSwOYB4AVAQQGNhsMoIAPJdAEwGcongAnbdXAPigF4oAbwBQUaug4gA-AC4oJcpXRjWCJEzlQAShFKp2DfG07cANLHUoMOAoooYePANwiAvq5GhIlxBBikABYQALbwAsKqbH6a8rr6hsYcXLgWcH4BwWEu7p4MegA28OzQmACu6EpUpCV+ALLwQVwQ+Kr2ytR0EIwsJilmbWhYeJ30zL5ImaHwAzwAFPrDuPKEQ7ZQAGQT1ktEZA7oPACU8gDa7RgWqzZ4ALqei2xQXJgQ7CUMAArF8CEsgjUIPVGoFmnNROJulJ5AAiTCoVAwgbiaIaeQQ8RQeDo1SYiTQqAwgBGxSRuKgbmRFIGbiOnhebw+33YvyYrgA9OyoAA9aQiIA

💻 Code

type StateConfig<TAction extends string> = {
  entry?: TAction
  states?: Record<string, StateConfig<TAction>>;
};

type StateSchema = {
  states?: Record<string, StateSchema>;
};

declare function createMachine<
  TAction extends string,
  TConfig extends StateSchema,
>(config: TConfig & StateConfig<TAction>): [TAction, TConfig];

const inferredParams = createMachine({
  entry: "foo",
  states: {
    a: {
      entry: "bar",
    },
  },
});

inferredParams; // ["foo" | "bar", StateSchema]

🙁 Actual behavior

TConfig gets inferred as its constraint

🙂 Expected behavior

I'd expect TConfig to infer successfully

Additional information about the issue

This is very related to the other issue I just created (see here). The underlying problem of this particular example is the same. The inferredType for TConfig fails the compareTypes check in getInferredType here. This time there is no excess property errors apparent to the user because the excess properties are satisfied through the intersection.

Despite the problem having the same root cause I think it's worth discussing this separately. The other issue could be closed as design limitation/working as intended but this one feels to me a lot closer to being an actual bug that would be worth fixing.

[Andarist]

Perhaps this is a design limitation/working as intended since manual type parameters "suffer" from the same problem in this example:

// 2nd constraint errors here
createMachine<"foo" | "bar", { entry: "foo"; states: { a: { entry: "bar"; }; }; }>({
  entry: "foo",
  states: {
    a: {
      entry: "bar",
    },
  },
});

I guess it makes sense if we consider type arguments as assignments and the argument itself as a completely separate piece. From that PoV, it doesn't matter that the argument would succeed if we had used the "original" inferred type (available in inference candidates) and let it flow to the parameter type of the instantiated~ signature.

[RyanCavanaugh]

I'd expect TConfig to infer successfully

What is your definition of success here?

[Andarist]

I expected TConfig to be roughly inferred as the type of the argument. So whatever got gathered here as the inference candidate ({ entry: "foo"; states: { a: { entry: "bar"; }; }; }).

Based on this late conclusion I don't expect this anymore. Or at least - not with the current model for how type arguments work in regards to this. I find it unfortunate that the final structural check of intersected candidates would succeed in this case and yet the candidate is rejected based on common property check failure against its constraint here. It makes it increasingly challenging to infer a recursive structure like this due to various current limitations.

In a way, I don't even want to infer TConfig here but I'd love to have a way to "capture" the argument's type as-is. Inference seemed like a great tool for the job (it's definitely a very close approximation of what I want) but it turns off the excess property check and that's immensely useful in my case. I figured out some ways to preserve or mimic excess property check in simpler situations but they don't work for recursive structures like this. They also require workarounds and just add unnecessary complexity to my types.

Another example of this need would be the queryOptions helper from @tanstack/react-query:

import { useQuery, queryOptions } from "@tanstack/react-query"; // types: 5.0.0-beta.25

const options = queryOptions({
  queryKey: ["foo"] as const,
  queryFn: () => Promise.resolve(5),
  staleTime: 10 * 1000,
});

useQuery({
  ...options,
  placeholderData: (previousData) => {
    previousData;
    // ^?
    return previousData;
  },
});

This is a helper that is needed~ to infer things within those "partial" options (especially the contextual parameter types between dependent properties). Its result i reusable and is later meant to be spread into useQuery - but since useQuery is also inferring things, it's best to use the narrowest possible type for options. When returning what might be used as the constraint of TOptions there it could return many optional properties that could accidentally be used as inference sources by useQuery. Inferring TOptions here:

• turns off excess property check (undesirable)
• breaks intra-expression inference (smth that could be fixed but it has to be challenging if a scenario like this was not fixed in 4.7 when improvements to that were introduced).

Sorry for somewhat offtopic train of thought :P

[RyanCavanaugh]

I don't entirely follow tbh, but I'm open to a well-explained PR if that's what you're saying 😅