chore(infra): add turbosnap

[daneah]

This change: (check at least one)

• Adds a new feature
• Fixes a bug
• Improves maintainability
• Improves documentation
• Is a release activity

Is this a breaking change? (check one)

• Yes
• No

Is the: (complete all)

• Title of this pull request clear, concise, and indicative of the issue number it addresses, if any?
• Test suite(s) passing?
• Code coverage maximal?
• Changeset added?

What does this change address?

Resolves #514

We have a lot of components. We are very cross-browser. We don't want to build so many things. TurboSnap makes it faster and cheaper to test Storybook by testing only changed components.

How does this change work?

Add the config for TurboSnap to the Chromatic workflow

Additional context

Docs

[changeset-bot]

⚠️ No Changeset found

Latest commit: a075a49

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

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

[github-actions]

size-limit report 📦

Path	Size
packages/pharos/lib/index.js	1.05 MB (+0.01% 🔺)

[daneah]

Hmm, I would've hoped #1345 would trigger and catch a change to the alert 😖

[daneah]

The issue with TurboSnap detecting changes is ultimately related to the fact that Vite can't properly infer the dependency tree because in story files we use the registered custom element tags (e.g. <storybook-pharos-alert>) instead of importing the PharosAlert from its module.

Possible avenues:

1. We could import the class and use it as meta.component in each story, but that may not be sufficient for page-level stories and also breaks automatic docgen.
2. We could import the files just for the side effects, but that is easy to forget/miss/update. 1. I started looking into using ESLint as a way to identify when a file has a custom element reference but not an import of the related component module, and that's when I ran into ESLint not actively checking TS[X] files #1356.
3. We could do something in the Vite transform level to auto-insert imports, but the code is a bit hairy.