statelyai/xstate xstate@4.30.6 on GitHub

Patch Changes

#3131 d9a0bcfc9 Thanks @Andarist! - Fixed an issue with event type being inferred from too many places within createMachine call and possibly ending up as any/AnyEventObject for the entire machine.
#3133 4feef9d47 Thanks @fw6! - Fixed compatibility with esoteric Mini Program environment where global object was available but global.console wasn't.
#3140 502ffe91a Thanks @Andarist! - Fixed an issue with interpreters started using a persisted state not being "resolved" in full. This could cause some things, such as after transitions, not being executed correctly after starting an interpreter like this.
#3147 155539c85 Thanks @Andarist! - Fixed a TS inference issue causing some functions to infer the constraint type for the event type even though a StateMachine passed to the function was parametrized with a concrete type for the event. More information can be found here.
#3146 4cf89b5f9 Thanks @Andarist! - Fixed compatibility of Interpreter with older versions of TypeScript. This ensures that our interpreters can correctly be consumed by functions expecting ActorRef interface (like for example useSelector).
#3139 7b45fda9e Thanks @Andarist! - InterpreterFrom and ActorRefFrom types used on machines with typegen data should now correctly return types with final/resolved typegen data. The "final" type here means a type that already encodes the information that all required implementations have been provided. Before this change this wouldn't typecheck correctly:
```
const machine = createMachine({
  // this encodes that we still expect `myAction` to be provided
  tsTypes: {} as Typegen0
});
const service: InterpreterFrom<typeof machine> = machine.withConfig({
  actions: {
    myAction: () => {}
  }
});
```
#3097 c881c8ca9 Thanks @davidkpiano! - State that is persisted and restored from machine.resolveState(state) will now have the correct state.machine value, so that state.can(...) and other methods will work as expected. See #3096 for more details.