feat(hub): cross-iframe dock activation with terminal session focus#103
Merged
Conversation
Let any connected client — including a mounted devframe running in its own iframe on its own RPC client — steer the host shell's active dock, which is otherwise client-local and unreachable from a mounted iframe. The terminals dock reads the activation params to focus a specific session, so a tool can spawn a build and navigate the user straight to its terminal output. Co-authored-by: opencode agent
✅ Deploy Preview for devfra ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
antfu
approved these changes
Jul 16, 2026
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
2 participants
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.
Why
Vite DevTools' Rolldown analyzer wants a "Run build with devtools" button that spawns a
vite buildviactx.terminals.startChildProcessand then navigates the user straight to that build's Terminals session. Two multi-integration capabilities were missing, and both are dock/terminal-navigation concerns that belong in the hub layer rather than any single integration:What
Capability A — hub-level cross-iframe dock activation. A new built-in RPC any client may call,
hub:docks:activate({ dockId, params? }), backed byctx.docks.activate(dockId, params?). The hub broadcasts the request live over a newdevframe:docks:activateclient function — the client host registers a handler that calls its localswitchEntry(dockId), mirroring the existingdevframe:messages:updated/devframe:terminals:updatedbroadcast pattern — and mirrors it into a newdevframe:docks:activeshared-state slot so a dock that mounts because of the switch still converges on the request. Unknown dock ids degrade to a no-op, warned server-side asDF8107.Capability B — terminal session focus by id. The Terminals panel reacts to
devframe:docks:active: when an activation targets its dock and carriesparams.sessionId, it focuses that session — whether the panel was already open or mounts in response to the switch. Focus is one-shot; an unknown / not-yet-arrived session id waits for that session to appear (then the user's own tab clicks are honored), and a session that never appears is a no-op (the most-recent-session default stands).Once released, Vite DevTools can drop its interim Vite-side dock-activation shim and consume
hub:docks:activatedirectly for exact-session focus.Acceptance criteria
hub:docks:activatewith{ dockId: 'devframes-plugin-terminals', params: { sessionId } }and the host shell switches to Terminals with that exact session focused.DF8107, docks sub-range, warn-level + docs page).pnpm lint && pnpm test && pnpm typecheck && pnpm build(671 tests; API snapshots regenerated for the new exports).Design decisions & open question
hub:docks:activate(consistent with the otherhub:*server built-ins); the server→client broadcast isdevframe:docks:activate(consistent with thedevframe:*client functions). The proposal suggested a singledevframe:docks:activatename — happy to rename the RPC if you'd prefer it to match verbatim.params.sessionIdis interpreted (open question). Rather than a dedicateddevframe:terminals:activeslot written by the hub (which would couple the hub to the terminals plugin id), the terminals panel reads the genericdevframe:docks:activeslot and owns the interpretation ofparams.sessionIditself — one protocol, no hub→plugin coupling, and it keeps the hub free of terminals-specific knowledge. This is the deliberate default; if you'd rather have a purpose-builtdevframe:terminals:activeslot, that's a small follow-up.This proposal originated from the Vite DevTools team. This PR was created with the help of an agent.