add TagsFrom helper type

[with-heart]

Hi yall! I saw a helper type request on Discord today that seemed easy enough to implement: TagsFrom

TagsFrom allows us to access the typegen tags type of a Machine State, or Interpreter:

import { TagsFrom } from "xstate";

const machine = createMachine({
  tsTypes: {} as {
    "@@xstate/typegen": true;
    tags: "a" | "b" | "c";
  }
});

type Tags = TagsFrom<typeof machine>; // 'a' | 'b' | 'c'

If typegen isn't enabled, TagsFrom returns string (which matches hasTag):

import { TagsFrom } from "xstate";

const machine = createMachine({});

type Tags = TagsFrom<typeof machine>; // string

[changeset-bot]

🦋 Changeset detected

Latest commit: 38dea6d

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
xstate	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[ghost]

👇 Click on the image for a new way to code review

Legend

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 38dea6d:

Sandbox	Source
XState Example Template	Configuration
XState React Template	Configuration

[with-heart]

How do you feel about the tests for this @Andarist?

Edit: Ugh I just noticed that @ts-expect-error covers both actual type errors and syntax warnings like unused vars. Didn't realize that and makes the types tests kind of awkward imo.

[with-heart]

Ugh, we should achieve formatting parity with xstate-tools bc I keep forgetting that imports aren't managed automatically like they are over there 😭

[Andarist]

Ugh, we should achieve formatting parity with xstate-tools bc I keep forgetting that imports aren't managed automatically like they are over there 😭

yeah, the situation is unfortunate - but we don't want to enable things like this at the moment here to avoid unnecessary merge conflicts when merging main to next

[with-heart]

@Andarist makes perfect sense. nice changes, appreciate it!