Bug: Unable to define `invoke` without providing actors

[Sebastian-G]

XState version

XState version 5

Description

Hi, I'm currently facing an issue with the invoke section of a state. For some reason, it is not possible to add any information in my current installed version "xstate": "^5.19.2", and "typescript": "^5.6.3",. I always end up with the following Typescript issue.

TS2353: Object literal may only specify known properties, and src does not exist in type readonly never[]
types.d.ts(285, 5): The expected type comes from property invoke which is declared here on type

Is it any unknown bug in the type definitions, or is it just the wrong place?

I needed to add a fake actor to use the invoke statement for adding a callback inline.

see:

const machine = setup({
  actors: {
    // FIXME: This is a workaround to make the `invoke` work and fix `never` type issues.
    fake: {} as any,
  },
}).createMachine({
  //...
  states: {
    //...
    exampleState: {
      invoke: {
        src: fromCallback(({ sendBack, self, input, system }) => {
          //...
        }),
      },
    },
  },
});

Expected result

const machine = setup({
  //...
}).createMachine({
  //...
  states: {
    //...
    exampleState: {
      invoke: {
        src: fromCallback(({ sendBack, self, input, system }) => {
          //...
        }),
      },
    },
  },
});

Actual result

TS2353: Object literal may only specify known properties, and src does not exist in type readonly never[]
types.d.ts(285, 5): The expected type comes from property invoke which is declared here on type

Reproduction

https://stackblitz.com/edit/github-xtgithyn?file=src%2FfeedbackMachine.ts&view=editor

Additional context

"xstate": "^5.19.2",

[Andarist]

This is, currently, by design - all actors should be known upfront so we can build correct and safe type for the .children

[woutrbe]

@Andarist I'm relatively new to xstate, and this was honestly incredibly frustrating. The document here - https://stately.ai/docs/invoke#invoking-promises - has no mention of having to define actors, and this example would also result in type errors being show.

It would be great if the documentation can be improved to reflect this. I'd also like to see if there's a better suggestion than

actors: {
    fake: {} as any,
},