Resolve the devtools import afresh after re-optimization; pre-bundle the diagnostics bridge - #351
Conversation
🦋 Changeset detectedLatest commit: a3cc782 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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 |
commit: |
…the diagnostics bridge New Solid 2 projects created with the development toolbar broke under `vite dev` on first load: the toolbar's lazy chunks answered `504 Outdated Optimize Dep`, a second solid-js instance entered the page, and hydration failed (REACTIVITY_HALTED). The generated entries' `@solidjs/start-devtools` import reused the id captured when the toolbar was detected. In the client environment that id is the optimizer's pre-bundled URL, stamped with the browserHash of the pass that produced it. Any dependency discovered after the initial scan re-optimizes — the toolbar's chunks are re-emitted under new names and the hash moves on — and the frozen id kept the entry on the previous pass. resolveId now resolves the package afresh on every request, from the app importer detection probed; detection itself stays memoized, verdict only. The trigger every fresh template project hit is removed too: the agent diagnostics bridge reaches the page through a virtual module the scanner never crawls, so its two imports (`@solidjs/diagnostics/browser` and `/protocol`) were only discovered on the first page load, forcing exactly that re-optimize + reload. The diagnostics plugin pre-bundles them whenever the surface is enabled. The start-ssr dev harness gains a regression check: a probe import forces a reload-class re-optimization and the generated entry's toolbar import must move to the same hash as its `@solidjs/web` import. It fails on the previous code (66/67) and passes with this change (67/67).
6d8d6be to
a3cc782
Compare
|
Reviewed for the rc.7 release train. The fresh Rebased onto |
Problem
A new Solid 2 project created with the development toolbar (
create-solid --devtools, which adds@solidjs/start-devtools) breaks undervite devon first load:Two things combine:
resolveDevtoolsmemoized the id it detected@solidjs/start-devtoolswith andresolveIdhanded that id back for the generated entries' import. In the client environment that id is the optimizer's pre-bundled URL, stamped with the browserHash of the pass that produced it. Any dependency discovered after the initial scan re-optimizes — the toolbar's chunks are re-emitted under new names and the hash moves on — and the frozen id kept the entry on the previous pass: the toolbar's lazy chunks answer504 Outdated Optimize Dep, and the stale bundle brings a secondsolid-jsinstance into the page. In the served entry every import carried the new hash except the toolbar's.virtual:solid-diagnostics/clientimports@solidjs/diagnostics/browserand/protocol, but the scanner never crawls that virtual module and nothing pre-bundled them, so the first page load discovered them, re-optimized and reloaded. The solid-v2 templates all enable diagnostics, so every fresh project hit this.Fix
src/ssr/index.ts:resolveIdresolves@solidjs/start-devtoolsafresh on every request, from the app importer detection probed. Detection is still memoized per consumer, but only its verdict.src/diagnostics/index.ts: aconfighook pre-bundles the bridge's two imports whenever the surface is enabled (explicittrue, or auto-detected from the app manifest — same gate as before).Test
examples/start-ssr/test/run.mjs(dev mode) gains two assertions: a probe module imports@solidjs/web/frames/client, which forces a reload-class re-optimization (it shares chunks with the already-bundled deps, so Vite has to rewrite them; a dependency that only adds a standalone bundle keeps the old hashes and reloads nothing), and the generated entry's toolbar import must move to the same hash as its@solidjs/webimport.start-devtools ?v=5784662f -> ?v=5784662f, @solidjs/web ?v=ba4c7b03)Also verified against a
create-solid --solid basic --devtools --ssrproject with this build installed: first load has no re-optimize, and after a forced mid-session re-optimization the reloaded page fetches the toolbar and its error-viewer chunk at the new hash with a clean console.🤖 Generated with Claude Code