# XState 6.0.0-alpha.14

- Product: XState (https://whatsnew.fyi/product/xstate)
- Vendor: Stately
- Date: 2026-07-01
- Version: 6.0.0-alpha.14
- Original notes: https://github.com/statelyai/xstate/releases/tag/xstate%406.0.0-alpha.14
- Permalink: https://whatsnew.fyi/product/xstate/releases/6.0.0-alpha.14
- Labels: Pre-release

What's New is an index, not a publisher: every entry below links to the vendor's own release notes, which are the authoritative source. Entries are labelled where they are hand-curated sample data, pre-releases, or drawn from a secondary source such as a developer blog.

Reuse: the summaries, labels and curation here are © What's New. Quote freely with attribution and a link back; wholesale republication of the corpus is not permitted — terms: https://whatsnew.fyi/terms. The vendors' own release notes remain their publishers'.

---

- **added** — Add a path-bound overload to `setup(...).createStateConfig(path, config)` that binds the config to a specific setup-declared state by dotted path and narrows the input schema accordingly
- **fixed** — Fix `snapshot.matches(...)` narrowing so repeated checks like `snapshot.matches('loaded') || snapshot.matches('failed')` compile correctly
- **changed** — Make `StateFrom<typeof machine>` preserve the machine's concrete state value
- **fixed** — Fix function-syntax transitions to pass `input` to target state entry actions

###### Minor Changes

-   c0c21d0: Add a path-bound overload to `setup(...).createStateConfig(path, config)`.

    When a state declares its own input schema, the anonymous `createStateConfig(config)` form types `input` as a broad union across all states. This makes the resulting config incompatible with the specific state it's meant for — assigning it inside `createMachine` produces a type error because the input types don't match.

    The new `createStateConfig(path, config)` overload binds the config to a specific setup-declared state by dotted path (e.g. `'loading'` or `'parent.child'`). The addressed state's own input schema is used inside `entry`/`exit` args, and bare transition targets are validated against the state's siblings.

    ```ts
    const s = setup({
      states: {
        idle: {},
        active: {
          schemas: { input: z.object({ userId: z.string() }) }
        }
      }
    });

    // Before: anonymous form — `input` is typed broadly, and assigning this
    // config to the `active` state in createMachine fails with a type error.
    const active = s.createStateConfig({
      entry: ({ input }) => {
        // input is not narrowed to { userId: string }
      }
    });

    // After: path-bound form — `input` is narrowed to `active`'s own schema.
    const active = s.createStateConfig('active', {
      entry: ({ input }) => {
        input.userId; // string
      }
    });

    // Works for nested states too:
    const child = s.createStateConfig('parent.child', { ... });
    ```

###### Patch Changes

-   8e3cce6: Fix `snapshot.matches(...)` narrowing so repeated checks like `snapshot.matches('loaded') || snapshot.matches('failed')` compile correctly, and make `StateFrom<typeof machine>` preserve the machine's concrete state value.
-   0c2a6e5: Fix function-syntax transitions not passing `input` to target state entry actions.

    ```ts
    on: {
      FETCH: ({ context, event }) => ({
        target: 'fetching',
        input: { url: event.url, token: context.authToken }
      });
    }
    ```

    Previously, `input` returned from function-syntax transitions was silently ignored. Now it is correctly forwarded to the target state's `entry` action.