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:

// 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.