feat: support external turnkey dev servers

[brenelz]

Summary

• let provider-owned and non-runnable SSR environments serve the generated turnkey request handler in development
• transport entry CSS through an HMR-tracked virtual module and compose server functions in the external handler
• add ssr.external for integrations that own server build wiring, plus turnkey coverage for the external flow

Verification

• pnpm build
• pnpm check
• pnpm --filter example-turnkey test -- external (150/150 assertions)

[changeset-bot]

🦋 Changeset detected

Latest commit: 908e717

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

This PR includes changesets to release 1 package

Name	Type
vite-plugin-solid	Patch

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

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/vite-plugin-solid@286

commit: 908e717

[ryansolid]

Thanks @brenelz — great work tracking this through the environment API. We've landed this manually, rebased onto next: your commit is 8386fb4 (authorship preserved), followed by our touch-ups in eb039f8, 0b30ff2, d3c7875, and dc64f29.

What changed in transit, for the record:

• Rebase reconciliation in hotUpdate. Since you branched, next picked up a manual full-reload send for runner-based servers (62d9a89). Your non-runnable fall-through and that fix each covered half the story, so the landed hook composes both: runnable non-client environments still suppress the boundary-less full-reload race and send the reload on the environment's own channel, while provider-owned (non-runnable) environments fall through so their plugin sees the real module list and can invalidate its remote runner.
• Reverted the dev-manifest crawl rewrite back to env.fetchModule with importer threading (eb039f8). The moduleGraph/transformRequest-based lookup missed placeholder-wrapped virtual dep URLs (/@id/__x00__…), which dropped virtual-module CSS from dev SSR — the css-matrix suite caught it. We kept your onFile watch callback. If there was a workerd-specific motivation for moving off fetchModule there, we'd genuinely love to hear it — we'll revisit with a test covering that case.
• Docs and a detection test we added. A README section for ssr.external documenting the option hierarchy — zero-config capability detection (non-runnable ssr environment → automatic stand-down) → ssr.external: true (explicit, whole-server, also for differently named provider environments detection can't see) → serverFunctions.devMiddleware: false (narrow, endpoint-only) — with matching JSDoc, plus a turnkey e2e mode that probes the detection branch itself: a plain DevEnvironment in the ssr slot, asserting both dev middlewares stand down while the handler still self-serves when imported through a module runner.

One note on the PR description: the dispatchFetch/runner.import middleware tier described there wasn't in the diff, and isn't in what we landed — provider-owned environments get next() deferral, which we think is the right call for Cloudflare (the provider owns routing to workerd, and the handler self-serves once imported there).

Everything is green across the suites (turnkey 179/179 including your external mode, ssr, css-matrix, and Cypress + vitest on Vite 6/7/8), and it ships in the next 3.0.0-next release. Closing rather than merging via the button since it landed by hand — the work is on next at 8386fb4.