Bug: A context property on a machine blows away actor input type checking

[SlexAxton]

XState version

XState version 5

Description

My actor inputs are typechecked until I add a context function to my machine, and then they're no longer typechecked. ts playground has reproduction

Expected result

I think the ts-expect-error should be correct regardless of if the context function is being set.

Actual result

Reproduction

https://www.typescriptlang.org/play/?ts=5.6.3#code/JYWwDg9gTgLgBAbzgZwKYwK5gDRwGZQQgAKhIwacAvvmXAEQAeyMAhjKvQNxwD0vcGAE8wqZAC44AVgB0ARgAcMgEwAoVcNFwAwhAB2HRvAC8iOBAwcokllGB6A5tS7qAxvpZwQrVwAt7qHCmaJhgABQIqnCCImKSCDSsyIhR0XDuBqhGkrqZRi5pcPZgljn6hjAF1NipPjDQEimFACYQAMqYeHiSBESkRBSoYamFSUJ6rnARRXol8FTxM3OL9nqo1nB6GCAARuvU1ACUQQB8TYVpUOgYUHpwALLsvjJQrHqtIGHHANRLljKrdZVQpUEZwQ41aJUGpUQ4yVxXdioR5+AIRVL8OAASTwcCEFnSRBAqAM5ksgn8yQANgFcDBfIFNIE-KhXABrexOfQUwJ1aBwADu0DZyVYDlY9lSGQqkmmxXJsNOfxgkJmADcIGzUPEwcgoK5JPRWh0MF16KrovKYDqLnwBAABGDIAC0WVErhgrqghCgYOirTEBgAoowKNaGHgIBBzX6ZmsNlIwdDUsnYS4gA

Additional context

No response

[SlexAxton]

Ah quick note that it doesn't actually have to be a context function to break the types: https://www.typescriptlang.org/play/?ts=5.6.3#code/JYWwDg9gTgLgBAbzgZwKYwK5gDRwGZQQgAKhIwacAvvmXAEQAeyMAhjKvQNxwD0vcGAE8wqZAC44AVgB0ARgAcMgEwAoVcNFwAwhAB2HRvAC8iOBAwcokllGB6A5tS7qAxvpZwQrVwAt7qHCmaJhgABQIqnCCImKSCDSsyIhR0XDuBqhGkrqZRi5pcPZgljn6hjAF1NipPjDQEimFACYQAMqYeHiSBESkRBSoYamFSUJ6rnARRXol8FTxM3OL9nqo1nB6GCAARuvU1ACUQQB8TYVpUOgYUHpwALLsvjJQrHqtIGHHANRLljKrdZVQpUEZwQ41aJUGpUQ4yVxXdioR5+AIRVL8OAASTwcCEFnSRBAqAM5ksgn8yQANgFcDBfIFNIE-KhXABrexOfQUwJ1aBwADu0DZyVYDlY9lSGQq8TBFiskgA5IrIdVUvYAG4QNmoWWFZBQVySeitDoYLr0VXRYqlc6FTEAARgyAAtFlRK4YG6oIQoGDoq0xAYAKKMCgwY14CAQS3+mZrDZSMHQ1Ip2EuIA

Just setting an initial context breaks it as well.

[SlexAxton]

Maybe another interesting version of types getting wonked in this case: it also stops checking the context types:

https://www.typescriptlang.org/play/?ts=5.6.3#code/JYWwDg9gTgLgBAbzgZwKYwK5gDRwGZQQgAKhIwacAvvmXAEQAeyMAhjKvQNxwD0vcGAE8wqZAC44AVgB0ARgAcMgEwAoVQGMIAOxZwQrDQAtg21HAC8KdFgAUCVXEEixkhDVbJEjp3C3aORhg3OAgMDihJFihTAHNqLh8qbB9DGGgJb184ABMIAGVMPDxJAiJSIgpUWx9szyFtDTh7OFMwcOoQtvCu7TNIuG0MEAAjVChqagBKSwA+LOzfKBsobTgAWXYjGShWbTyQWxmAalbtdpgZU37ExepauCmUp2TVKimZDWX2VE3jU2qDic-DgAEk8HAhGE-EQQKgAqEOjATF4ADYA3DI8zCUR+IyoDQAazioTWWLgaWgcAA7tBCV5WLFWKYfP5AsEFk4whFJAByXnPXwggACMGQAFpUIxRBoYJKoIQJqxUcgICgjGFUTk4GBCCNWCNUUJBhB4LSoISHtpTaDtABhHTsvkCpKC0wANwghNQbgeyCgGkk9DyhQwxXogqc3Q5QMWIrFkulBLl40V6s12uRhGpcDGGlYGEowHgeTECKlFBgDycpeQAQAooxK0G8BAIBHq2d+pIpA9Xi8Uu9EkA

[with-heart]

Maybe another interesting version of types getting wonked in this case: it also stops checking the context types:

Yeah it's really weird that the presence of a nested type error disables the expected "missing context" type error for the entire config object, even if you use @ts-expect-error or @ts-ignore to disable the nested type error.

Something else I noticed while playing around with your examples is that the type of invoke is either inferred or an assigned type depending on whether context is present or not:

• with context (inferred):

  {
    readonly src: "doStuff"
    readonly input: {
      readonly inner: number
    }
  }

• without context (assigned type):

  (property) invoke?: SingleOrArray<{
      systemId?: string | undefined;
      src: "doStuff";
      id?: string | undefined;
      input: {
          inner: number;
      } | Mapper<{
          outer: string;
      }, AnyEventObject, {
          inner: number;
      }, AnyEventObject> | undefined;
      onDone?: SingleOrArray<...>;
      onError?: SingleOrArray<...>;
      onSnapshot?: SingleOrArray<...>;
  } | {
    ...;
  }> | undefined

ts playground example of the above.

And if we modify your first example a tiny bit, we can see that the above holds true. When context is commented out and the type error is thrown on invoke.input.doesntExist, invoke has an assigned type, but if we uncomment context then invoke becomes inferred and the type error on invoke.input.doesntExist disappears: ts playground

This switch between inferred and assigned type seems to be the difference in whether an error is thrown on invoke.input or not.