Skip to content

Surprising excess property check with recursive generic constraintΒ #55644

Open
@Andarist

Description

@Andarist

πŸ”Ž Search Terms

excess property check recursive generic contraint type variable inference

πŸ•— 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/C4TwDgpgBAysCGwIwMYAsIFt5QLxQG8AoKKAZwSTIH4AuKAJQhQHsAnAEwB4K2BLAHYBzADSxKydFngA+ANxEAvgqIdmAG3htoAMwCuAlMD4sBUFNsQQAsvHSCIXACoBhUzr5CoEAB5IBHGTiVqgY2DIAFCTm7p70rrGiRACU8W4CHkIqFhBWtvYCEBHEpBACwGwg9ADaBFCgkPQARDosLE1QigC6ItEUVmT0JaRQ8EPRI97llTV1DRDNAEZaHd29k4rrnb2KyQpAA

πŸ’» Code

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

declare function createMachine<TConfig extends StateSchema>(
  config: TConfig,
): TConfig;

createMachine({
  entry: [{ type: "foo" }],
  states: {
    a: {
      entry: [{ type: "bar" }],
    },
  },
});

πŸ™ Actual behavior

At the nested entry property the error is raised:

Object literal may only specify known properties, and 'entry' does not exist in type 'StateSchema'.(2353)

but it isn't raised at the entry property at the root of this object.

πŸ™‚ Expected behavior

I'd expect no excess property error to be raised with a recursive constraint like this.

Additional information about the issue

This particular case is somewhat easily fixable by adding [k: string]: unknown to StateSchema. I still find the reported behavior to be a problem though.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Help WantedYou can do thisPossible ImprovementThe current behavior isn't wrong, but it's possible to see that it might be better in some cases

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions