[lxsmnsyc]

Depends on #45. Its Health view is where server errors show, so this branch is stacked on feat/dock-redesign.

Replaces #32. That PR mounted the toolbar from a Vite plugin. A plugin is more useful as a channel for what only the dev server knows. @solidjs/vite-plugin already mounts the toolbar in Start mode, so it serves the other side of this channel: solidjs/solid-vite-plugin#530.

What the dev server gives the toolbar

• Server errors. Failures the server runtime reports (a render, a server function, a request) show in the Health view. The row subtitle starts with Server render:, Server function <id>: or Server request:. The error viewer maps their stack as it does for server frames today. An <Errored> that renders its fallback on the server sends the error with the page, and hydration throws it again. The two records merge into one row.
• Open in editor. One request to /__solid/devtools/open-in-editor?file=…. Like Vite's own /__open-in-editor, it does not take the Vite base. The plugin resolves the path against the Vite root, so the toolbar no longer sends one request per sub-path. Without the plugin the old fan-out to /__open-in-editor stays.
• Versions. The plugin resolves solid-js, @solidjs/web, @solidjs/vite-plugin and vite from the app root. The header uses its solid-js version when the page cannot import solid-js/package.json.

Protocol

@solidjs/start-devtools/protocol holds the event names, the endpoint path and the payload types. The plugin imports the types and declares each constant with the type of the one here, as it does for @solidjs/diagnostics. A change on either side then fails the other's compile.

1. The plugin's generated client entry calls connectDevServer(import.meta.hot). A pre-bundled package has no import.meta.hot, so the plugin passes its own.
2. The toolbar sends solid:devtools:hello with since: performance.timeOrigin.
3. The server answers solid:devtools:info with the versions and the errors it kept since then. The errors of the render that served the page come in this answer, since that render happens before the page can connect.
4. Each later error comes as solid:devtools:server-error. The toolbar drops an id it already has.

Changes

• src/protocol.ts, exported as ./protocol and built to dist/protocol.js with its types.
• src/dev-toolbar/dev-server.ts: the connection. It keeps the info and the errors that arrive before the toolbar renders and hands them to each listener.
• connectDevServer from the package entry. The server and no-op builds export a function that does nothing.
• ErrorRecord.server marks an error the server sent. Its time moves from the epoch clock to the page's. addPageError and addServerError merge the page's and the server's copy of a render error.
• openInEditor uses the plugin's endpoint when the plugin connected.

Testing

• src/dev-toolbar/dev-server.test.ts: the hello, late listeners, dropped duplicates, removed listeners.
• src/dev-toolbar/error-record.test.ts: the merge of a render error in either order, and the cases that stay apart.
• End to end with the build of feat: connect the devtools toolbar to the dev server solid-vite-plugin#530: a Start app whose component throws during the server render shows one Health row, Server render: server render boom.
• Two e2e tests with a fake dev server in tests/fixture/vite.config.ts that speaks the protocol. A server error from before the page loaded shows in Health. Open in editor sends one request to the endpoint.
• pnpm test, pnpm typecheck, pnpm format:check, pnpm build, pnpm check and the full e2e suite (27 tests) pass locally.

Not done

• Handler locations for Activity. They need a new kind in the compiler's sourceNames, not this channel.
• A source endpoint for the error viewer, for frames the browser cannot fetch over /@fs/.
• An HTTP endpoint for agents that returns the session report.
• The session report does not list the dev server's versions yet.
• Self-review only. A fresh review is still to do before this leaves draft.

🤖 Generated with Claude Code