node-zwave-js fix(deps): update dependency xstate to ^4.33.6

trafficstars

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
xstate (source)	`^4.29.0` -> `^4.33.6`

Release Notes

statelyai/xstate

`v4.33.6`

Compare Source

Patch Changes

#3571 6fdaae710 Thanks @davidkpiano! - Reading state directly from ~~someService.state~~ is deprecated. Use someService.getSnapshot() instead.
#3555 4c13b3faf Thanks @davidkpiano! - The sendTo(actorName, event) action creator now accepts a string actorName.

`v4.33.5`

Compare Source

Patch Changes

#3559 ddbc9bc5c Thanks @Andarist! - Fixed minor compatibility issues with TypeScript 4.8 in the codebase. This fixes the typechecking with TypeScript 4.8 in projects that don't use skipLibCheck: true.
#3563 e3c7a9caf Thanks @Andarist! - Fixed an issue with not executing actions in response to received batched events when using predictableActionArguments.
#3520 95a6a06d0 Thanks @Andarist! - Fixed a runtime crash when sending multiple events as an array to a service. It is not recommended to use this feature though as it will be removed in the next major version.

`v4.33.4`

Compare Source

Patch Changes

#3549 768c4e938 Thanks @Andarist! - Fixed an issue with not being able to send events to initially started child actors when using predictableActionArguments.

`v4.33.3`

Compare Source

Patch Changes

#3540 121fad172 Thanks @Andarist! - Fixed an issue that caused invoked actors to be created before resolving assign actions from entry of the same state when using predictableActionArguments flag.
#3541 6c081ab87 Thanks @Andarist! - Fixed an issue with not being able to read the updated snapshot of a child when receiving and processing events from it and when using predictableActionArguments flag.

`v4.33.2`

Compare Source

Patch Changes

#3523 129bcf927 Thanks @Andarist! - Fixed a regression that caused child actors not being correctly stopped when their parent reached a final state.

`v4.33.1`

Compare Source

Patch Changes

#3514 b451f5789 Thanks @Andarist! - Fixed an issue with .nextState(event) calls accidentally executing actions in machines with predictableActionArguments.

`v4.33.0`

Compare Source

Minor Changes

#3289 c0a147e25 Thanks @Andarist! - A new predictableActionArguments feature flag has been added that allows you to opt into some fixed behaviors that will be the default in v5. With this flag:
- XState will always call an action with the event directly responsible for the related transition,
- you also automatically opt-into preserveActionOrder.
Please be aware that you might not able to use state from the meta argument when using this flag.
#3126 37b751cb3 Thanks @Andarist! - All exit actions in the machine will now be correctly resolved and executed when a machine gets stopped or reaches its top-level final state. Previously, the actions were not correctly resolved and that was leading to runtime errors.

To implement this fix in a reliable way, a new internal event has been introduced: { type: 'xstate.stop' } and when the machine stops its execution, all exit handlers of the current state (i.e. the active state nodes) will be called with that event. You should always assume that an exit handler might be called with that event.

Patch Changes

#3178 6badd2ba3 Thanks @davidkpiano! - Added a dev-only error when forwardTo accidentally ends up trying to forward an event to an undefined actor. Such a situation indicates a logical error and risks an infinite loop.
#3453 368ed9b1c Thanks @pixtron! - Call the complete callback of the subscribed observer when an interpreter gets stopped.
#3422 e35493f59 Thanks @Andarist! - Fixed an issue with parallel regions not always being correctly reentered on external transitions of the containing parallel state targeting another region within that parallel state.
#3447 e93754d7a Thanks @davidkpiano! - The types for state.nextEvents are now properly typed to the actual event types of the machine. Original PR: #1115 (Thanks @alexreardon!)
#3424 88d540eb8 Thanks @Andarist! - Fixed an issue with targeted ancestors not being correctly reentered during external transitions.

`v4.32.1`

Compare Source

Patch Changes

#3292 16514e466 Thanks @Andarist! - Fixed an issue in the EmittedFrom type helper that could prevent it from inferring the desired type from some services.

`v4.32.0`

Compare Source

Minor Changes

#3234 ce376b388 Thanks @Andarist! - Added a StateValueFrom helper that can be used to extract valid state values from a machine. This might specifically be useful with typegen because typegenless state.matches accepts any anyway.

Patch Changes

#3215 44c66e74f Thanks @tom-sherman! - Removing the timeout that's built in to waitFor is now supported by explicitly passing an Infinity value.

Example usage:
```
import { waitFor } from 'xstate/lib/waitFor';

// This will
const loggedInState = await waitFor(
  loginService,
  state => state.hasTag('loggedIn'),
  { timeout: Infinity }
);
```
This fixes a bug that causes waitFor to reject with an error immediately due to the behaviour of setTimeout.
#3230 780458c92 Thanks @Andarist! - Fixed an issue with typegen types not being able to provide events that had a union of strings as their type (such as { type: 'INC' | 'DEC'; value: number; }).
#3252 a94dfd467 Thanks @Andarist! - Fixed an issue with EventFrom not being able to extract events that had a union of strings as their type (such as { type: 'INC' | 'DEC'; value: number; }).
#3090 c4f73ca13 Thanks @Andarist! - Fixed an issue with action objects not receiving correct event types when used in the second argument to the createMachine.
#3238 3df6335ef Thanks @davidkpiano! - The typings for sendTo(...) have been fixed.
#3228 fe5f0e6c9 Thanks @Andarist! - Fixed an issue with inline functions in the config object used as transition actions not having their argument types inferred.
#3252 a94dfd467 Thanks @Andarist! - Fixed an issue with default TEvent ({ type: string }) not being correctly provided to inline transition actions.

`v4.31.0`

Compare Source

Minor Changes

#3190 fbf5ca0ad Thanks @davidkpiano! - The waitFor(...) helper function, which asynchronously waits for an actor's emitted value to satisfy a predicate before a timeout, is now available.

Example usage:

import { waitFor } from 'xstate/lib/waitFor';

// ...
const loginService = interpret(loginMachine).start();

const loggedInState = await waitFor(loginService, state =>
  state.hasTag('loggedIn')
);

loggedInState.hasTag('loggedIn'); // true

#3200 56c0a36 Thanks @Andarist! - Subscribing to a stopped interpreter will now always immediately emit its state and call a completion callback.

Patch Changes

#3166 be4c5c74d Thanks @Andarist! - Fixed an issue with state.tags not having correct values when resolving micro transitions (taken in response to raised events). This was creating issues when checking tags in guards.
#3171 14f8b4785 Thanks @Andarist! - Fixed an issue with onDone on parallel states not being "called" correctly when a parallel state had a history state defined directly on it.
#2939 360e85462 Thanks @Andarist! - Fixed issues with not disposing some cached internal values when stopping interpreters, which could have led to issues when starting such an interpreter again.
#3153 b36ef9dda Thanks @Andarist! - Made type displays (like in the IDE tooltips etc) more readable by using a type interface for the internal ResolveTypegenMeta type.

`v4.30.6`

Compare Source

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.

`v4.30.5`

Compare Source

Patch Changes

#3118 28e353081 Thanks @Andarist! - Fixed a bundling issue that prevented the keys() export to be preserved in the previous release.

`v4.30.4`

Compare Source

Patch Changes

#3104 3706c62f4 Thanks @Andarist! - Fixed ContextFrom helper type to work on typegened machines.
#3113 144131bed Thanks @davidkpiano! - The keys() utility function export, which was removed in #3089, is now added back, as older versions of XState libraries may depend on it still. See #3106 for more details.
#3104 3706c62f4 Thanks @Andarist! - Fixed EventFrom helper type to work on machines.

`v4.30.3`

Compare Source

Patch Changes

#3088 9f02271a3 Thanks @Andarist! - Added some internal @ts-ignore comments to fix consuming projects that do not use skipLibCheck.
#3082 8d3f2cfea Thanks @Andarist! - Fixed an issue with context type being inferred from too many places within createMachine call and possibly ending up as any for the entire machine.
#3027 97ad964bd Thanks @hedgepigdaniel! - Fixed an issue with not being able to call createMachine in a generic context when the type for the context was generic and not concrete.
#3084 50c271dc1 Thanks @Andarist! - Fixed an issue with context type defined using schema.context being sometimes widened based on config.context. If both are given the schema.context should always take precedence and should represent the complete type of the context.
#3089 862697e29 Thanks @Andarist! - Fixed compatibility with Skypack by exporting some shared utilities from root entry of XState and consuming them directly in other packages (this avoids accessing those things using deep imports and thus it avoids creating those compatibility problems).
#3087 ae9579497 Thanks @Andarist! - Fixed an issue with ActorRefFrom not resolving the typegen metadata from machine types given to it. This could sometimes result in types assignability problems, especially when using machine factories and spawn.

`v4.30.2`

Compare Source

Patch Changes

#3063 c826559b4 Thanks @Andarist! - Fixed a type compatibility with Svelte's readables. It should be possible again to use XState interpreters directly as readables at the type-level.
#3051 04091f29c Thanks @Andarist! - Fixed type compatibility with functions accepting machines that were created before typegen was a thing in XState. This should make it possible to use the latest version of XState with @xstate/vue, @xstate/react@^1 and some community packages.

Note that this change doesn't make those functions to accept machines that have typegen information on them. For that the signatures of those functions would have to be adjusted.
#3077 2c76ecac5 Thanks @Andarist! - Fixed an issue with nested state.matches calls when the typegen was involved. The state ended up being never and thus not usable.

`v4.30.1`

Compare Source

Patch Changes

#3040 18dc2b3e2 Thanks @davidkpiano! - The AnyState and AnyStateMachine types are now available, which can be used to express any state and state machine, respectively:

import type { AnyState, AnyStateMachine } from 'xstate';

// A function that takes in any state machine
function visualizeMachine(machine: AnyStateMachine) {
  // (exercise left to reader)
}

function logState(state: AnyState) {
  // ...
}

#3042 e53396f08 Thanks @suerta-git! - Added the AnyStateConfig type, which represents any StateConfig<...>:

import type { AnyStateConfig } from 'xstate';
import { State } from 'xstate';

// Retrieving the state config from localStorage
const stateConfig: AnyStateConfig = JSON.parse(
  localStorage.getItem('app-state')
);

// Use State.create() to restore state from config object with correct type
const previousState = State.create(stateConfig);

`v4.30.0`

Compare Source

Minor Changes

#2965 8b8f719c3 Thanks @satyasinha! - All actions are now available in the actions variable when importing: import { actions } from 'xstate'

#2892 02de3d44f Thanks @davidkpiano! - Persisted state can now be easily restored to a state compatible with the machine without converting it to a State instance first:

// Persisting a state
someService.subscribe(state => {
  localStorage.setItem('some-state', JSON.stringify(state));
});

// Restoring a state
const stateJson = localStorage.getItem('some-state');

// No need to convert `stateJson` object to a state!
const someService = interpret(someMachine).start(stateJson);

Patch Changes

#3012 ab431dcb8 Thanks @Andarist! - Fixed an issue with a reference to @types/node being inserted into XState's compiled output. This could cause unexpected issues in projects expecting APIs like setTimeout to be typed with browser compatibility in mind.
#3023 642e9f5b8 Thanks @Andarist! - Fixed an issue with states created using machine.getInitialState not being "resolved" in full. This could cause some things, such as after transitions, not being executed correctly after starting an interpreter using such state.
#2982 a39145580 Thanks @Andarist! - Marked all phantom properties on the StateMachine type as deprecated. This deprioritized them in IDEs so they don't popup as first suggestions during property access.
#2992 22737adf2 Thanks @Andarist, @mattpocock! - Fixed an issue with state.context becoming any after state.matches when typegen is used.
#2981 edf60d67b Thanks @Andarist! - Moved an internal @ts-ignore to a JSDoc-style comment to fix consuming projects that do not use skipLibCheck. Regular inline and block comments are not preserved in the TypeScript's emit.

Configuration

📅 Schedule: Branch creation - "before 8:00 am on the first day of the month" in timezone Europe/Berlin, Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, click this checkbox.

This PR has been generated by Mend Renovate. View repository job log here.