solid-start

Current behavior When a file has a file-level directive and exports a function wrapped in or , the export is silently dropped from the client bundle: Expected behavior The export should be preserved on the client with the inner function replaced by an RPC stub: Root cause (client mode, ) calls for each export to generate RPC stubs. only returns a binding when the variable's is directly a function expression: only matches . When is — a — returns , so is never added to . Then at : Suggested fix Option A (targeted): When returns for a init, fall back to the function-level transform: traverse the arguments for nested functions, replace them with , and include the modified declaration in the output. This generalizes to any HOF wrapper (, , , custom wrappers), not just . Option B (cleaner): Transform the import site instead of the module — when the client bundle imports a named export from a module, inline the RPC stub at the call site so the server module never enters the client bundle at all (similar to how React Server Components handles server actions). Environment OS: Windows 11 Node: v26.2.0 pnpm: 11.8.0 @solidjs/start: 2.0.0-rc.7 Some of the content was generated by AI.

Redesign for the dev toolbar Mainly layout changes Fix dev toolbar popovers affected by dragging interaction Change seroval viewer to tree layout instead of cascade Fix error viewer to capture unhandled rejections Replace with Aims to replace #2282

What runs on the first dev request and emitted a event for every existing route file it discovered. The fs-watcher's debounced handlers then invalidated (ssr) / d (client) the manifest ~200ms later — after the manifest had already been served — pushing a spurious HMR update that re-imported , 's , and the user's as fresh -stamped module instances while hydration was still in flight. This PR keeps the events quiet during the initial scan. Edits, additions, and removals of route files after the scan still emit as before. Symptoms Depending on where the update landed relative to hydration, dev sessions intermittently saw: two pages rendered simultaneously (#2297) client-side navigation updating the URL but not the content / handlers never firing (the handler lives in the stale module instance while the DOM belongs to the new one) The race is nondeterministic twice over: server-side, if the debounced handler fires before the manifest module exists in the graph, the event degrades to a harmless sent to zero connected clients — so cold starts only misbehaved ~50% of the time; client-side, damage depends on whether the HMR update lands before or after hydration completes, so heavier apps fail much more often than small ones. This matches an A/B on a real site where 16/20 cold dev runs broke client-side navigation. Verification Against the published with this change patched into , driving cold dev starts with Playwright (fresh + fresh server per run): before: 3/6 cold loads received a spurious push ~420ms after the first request, with the browser re-importing and after: 0/6, across repeated batches editing an existing route file still hot-updates just that module; adding a new route file still reloads the manifest and the new route navigates correctly and the fs-routes unit tests (28) pass. 🤖 Generated with Claude Code