# Feature request: document (or preset) the consumer vitest setup for `.jsx` deps

> **RESOLVED — docs shipped (`docs/testing.md`).** Chose option 1 (docs) over
> option 2 (a shipped config helper): a version-coupled inline regex list is a
> maintenance tail for marginal gain. The guide gives the exact `server.deps.inline`
> set, `resolve.dedupe:['solid-js']`, and the happy-dom note, indexed from
> `docs/README.md` + AGENTS.md.
>
> **Two corrections to the recipe in this request, verified against the tree:**
> - The load-bearing inline set is **four** packages — `@kobalte/core`,
>   `@corvu/utils`, `solid-presence`, `solid-prevent-scroll`. `@kobalte/utils`
>   ships **plain JS** (0 `.jsx`) and does *not* need inlining; nor does the new
>   `@formkit/drag-and-drop` dep (0 `.jsx`).
> - You do **not** need to inline `@dolphinspired/solid-stage` itself — it ships
>   pre-compiled JS, so the `.jsx` only ever comes from the Kobalte-ecosystem
>   deps. dsts-viewer can drop the `/@dolphinspired\/solid-stage/` entry from its
>   inline list (harmless to keep, but redundant). Reconcile per validation step 1.

- **Status:** RESOLVED (docs shipped — `docs/testing.md`)
- **Component:** docs (`docs/guides.md` or a new `docs/testing.md`); optionally a
  shipped vitest config helper
- **Pulled by:** dsts-viewer (every component test that imports the library failed until configured)
- **Severity:** medium (blocks consumer testing until solved; pure archaeology to discover)
- **Date:** 2026-06-18

## What happens

Any consumer whose vitest suite imports `@dolphinspired/solid-stage` (directly or via
a component under test) hits:

```
TypeError: Unknown file extension ".jsx" for …/@kobalte/core/dist/text-field/index.jsx
```

The library is compiled JS, but `@kobalte/core` — and its transitive
`@corvu/utils`, `solid-presence`, `solid-prevent-scroll` — ship **`.jsx` in their
dist**, which Node can't parse and vitest externalizes by default. The fix isn't
obvious: the consumer must inline those packages so `vite-plugin-solid` transforms
them, and dedupe Solid:

```ts
// vitest.config.ts
test: {
  server: {
    deps: {
      inline: [
        /@dolphinspired\/solid-stage/, /@kobalte\/core/,
        /@corvu\/utils/, /solid-presence/, /solid-prevent-scroll/,
      ],
    },
  },
},
resolve: { dedupe: ['solid-js'] },  // else "multiple instances of Solid"
```

…and a `// @vitest-environment happy-dom` on any test file that imports the library
(it touches `window` at module load via the canvas/chrome).

dsts-viewer spent real time discovering this. It's not a library bug (it's Kobalte's
packaging), but solid-stage is the thing consumers `import`, so it's the natural place
to document the workaround.

## Recommended implementation

Pick one (or both):

1. **A `docs/testing.md` (or a "Testing your consumer" section in `guides.md`)** with
   the exact `server.deps.inline` list (the Kobalte-ecosystem `.jsx` packages),
   `resolve.dedupe: ['solid-js']`, and the happy-dom note. Cheapest, highest value.
2. **A shipped config helper** consumers spread into their vitest config, e.g.
   `import { vitestDeps } from '@dolphinspired/solid-stage/testing'` exposing the inline
   regex list — so the list stays correct as the dependency set evolves and consumers
   don't hand-maintain it.

## Validation in dsts-viewer (separate from the playground)

> Run from `/home/developers/Repos/dsts-viewer`; this validates the **documented/preset
> setup against dsts-viewer's actual suite**, independent of the playground.

1. If a helper ships (option 2): bump the dep and replace dsts-viewer's hand-written
   `server.deps.inline` list in `vitest.config.ts` with the helper; if only docs ship,
   diff dsts-viewer's existing config against the documented recipe and reconcile.
2. `pnpm test` → all suites green (currently 251 tests), no `Unknown file extension
   ".jsx"` and no "multiple instances of Solid" warning.
3. Spot-check a library-importing test runs under happy-dom (e.g.
   `src/components/BrowseTable.test.tsx`).
4. `pnpm prebuild` clean.