Repository navigation
Conversation
…gram Under vite dev, a <style> edit in a non-entry module never reached the page, because the program's whole stylesheet came only on the entry and the plugin recompiles CSS per file. Under Vitest's fsModuleCache, a cached entry left builds empty, so the next changed dependency threw "no program built so far contains it".
A dependency compiles to a factory over the app, so Solid's refresh pass finds no component to swap, and the entry's watch on every module of its program reloads the page on any edit. The front end now wraps the factory with the runtime's new hot entry, which re-runs a new version against the same app with its module-level calls answered from the first run, and its hotUpdate leaves the entry out when no other module compiles differently and the text outside the components' bodies is unchanged.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Under
vite dev, every edit to a non-entry.rxmodule reloads the page (page reload src/components/Counter.rx), so all app state is lost.This branch is stacked on #66 (its first commit). Review only the second commit,
feat(vite): hot-swap a dependency's components under vite dev. It needs the solid-vite-plugin change in solidjs/solid-vite-plugin#539, which addsFrontendContext.hotandFrontend.hotUpdate. With an older plugin nothing changes: no HMR code is emitted, and edits reload as before.Root cause
A dependency compiles to
export default function module(__rt), a factory over the app (09 MO-1b, CP-4bmodule). Solid's refresh pass registers only top-level components, so it emits nothing for it, and the update travels up to the page. Even with an accept handler, the entry still reloads the page: it callsaddWatchFileon every module of its program, so each edit also reaches it through a watch-only module that it does not accept.What changed
app()now returnsmodules[path].hotfor each dependency: its exported components, and a hash of its declarations with component bodies left out (each component's name and props stay in).hotis absent when that text names a binding from a JS import or calls an.rximport, because a replay would make that call again outside its record. The emitted JS is unchanged.compiler/vite.mjs.hotis set, a dependency's factory is wrapped by@reactivescript/runtime/hot, and the module accepts its own updates. The wrap is skipped when the project's runtime has no./hotentry.hotUpdaterebuilds each program that holds the file. When no other module compiles differently and the file's hash and component list are unchanged, it keeps only the?rx-depmodules, so the entry is left out. Otherwise it leaves Vite's list alone, and the page reloads.ref/compile/rt-hot.ts, published as@reactivescript/runtime/hot).solid-js/refreshproxies ($$component), and the factory's top-level calls on__rtare recorded.guesschanges how a module-level source is made), when the new version throws, or when the module's own code is unchanged. The last case means an import changed, and the recorded top level may have read the old version.compiler/test/vite.mjsnow gives each project its owncacheDir. The default sat undercompiler/package.json, so one run's pre-bundled runtime was served to the next.Spec questions this leaves open
@reactivescript/runtime/hotis runtime surface that CP-4b does not list. The front end emits it in dev client transforms only, but spec/11 may want to name it.<style>edit changes the module's JS too, because the scoped class hash changes. So the component re-renders and loses its own state.Verification
With
SOLID_VITE_PLUGINset to a build of the plugin PR:node compiler/test/vite.mjs: 17 pass. The newhot (dev)block covers:source totaland another module's component state surviving markup,<style>and logic edits, and the new handler running.It fails with the published next.57 plugin (
after a markup edit: … kept: false). The JS-import step fails without the code check, and the step after a failed compile fails with the previousvite.mjs.cargo test --release,node compiler/test/node.mjsandnode runtime/test.mjspass.In the
solid-v2/with-reactivescripttemplate, with the three packages linked, Playwright checked edits toCounter.rx. Markup,<style>and logic edits hot-swap with no reload and keep the guestbook's entries and the current user. A top-level edit and anApp.rxedit reload.🤖 Generated with Claude Code