Skip to content

fix(devframe,hub): republish remote-dock WS endpoint once it resolves - #217

Merged
antfu merged 1 commit into
mainfrom
fix/standalone-ws-endpoint-republish
Aug 14, 2026
Merged

fix(devframe,hub): republish remote-dock WS endpoint once it resolves#217
antfu merged 1 commit into
mainfrom
fix/standalone-ws-endpoint-republish

Conversation

@antfubot

Copy link
Copy Markdown
Collaborator

Context

Closes #206, which asked to verify the second half of vitejs/devtools#520 ("allocate standalone WebSocket ports atomically") by @webfansplz, fixing vitejs/devtools#517: once an async WS bind resolves its port, already-registered remote iframe docks need their connection URL republished.

The atomic-bind half already shipped in #171 (merged, in 0.9.0-beta.2). This PR closes the remaining gap: the WS-endpoint republish.

The gap

initHub installs every mounted devframe — and registers their docks — before resolving the WS transport (an async side-car port probe, or the unbound tier waiting on the host's own attach()). A remote iframe dock registered in that window got projected into devframe:docks shared state without a connection descriptor, because DevframeInternalContext.wsEndpoint wasn't set yet. Nothing re-ran that projection once the port resolved, so the dock kept a bare/unusable URL for the life of the process — the same class of bug as the old ws.ts's dock:entry:updated re-emit that #520 fixed upstream, just in this repo's hub-internals path instead.

Fix

  • DevframeInternalContext gains setWsEndpoint() / onWsEndpointChange() — every WS-binding tier (side-car, shared-server, and the unbound tier's attach()) now sets the endpoint through this instead of a plain field assignment, so subscribers learn when it changes.
  • The hub context subscribes and re-projects every dock into devframe:docks shared state whenever the endpoint resolves (or is torn down), alongside the existing dock:entry:updated trigger.

Testing

  • Added a regression test (packages/hub/src/node/__tests__/context.test.ts) that registers a remote dock before the WS endpoint is known, asserts it's un-enriched, then resolves the endpoint and asserts the shared-state entry picks up the connection URL. Verified it fails without the fix and passes with it.
  • pnpm build && pnpm vitest run && pnpm typecheck all pass.

Credit to @webfansplz for the original diagnosis and fix upstream (vitejs/devtools#520, vitejs/devtools#517).


This PR was created with the help of an AI agent.

Port the second half of vitejs/devtools#520: a remote iframe dock
registered before the standalone WebSocket transport finishes binding
(the common `initHub` sequence — devframes, and their docks, install
before an async side-car/shared-server port resolves) was projected
without a connection descriptor, since `wsEndpoint` wasn't set yet.
Nothing re-registered that dock once the port resolved, so it kept a
stale/empty connection URL for the life of the process.

`DevframeInternalContext` now exposes `setWsEndpoint`/`onWsEndpointChange`
so subscribers learn when the endpoint changes instead of reading a
plain field once at registration time. The hub context subscribes and
re-projects every dock into `devframe:docks` shared state whenever the
endpoint resolves (or is torn down).

#171 already covers the atomic-bind half of #520.

Co-authored-by: webfansplz <webfansplz@gmail.com>

Refs: vitejs/devtools#520, vitejs/devtools#517
@netlify

netlify Bot commented Aug 14, 2026

Copy link
Copy Markdown

Deploy Preview for devfra ready!

Name Link
🔨 Latest commit cc32745
🔍 Latest deploy log https://app.netlify.com/projects/devfra/deploys/6a7ea875f3825000086d9126
😎 Deploy Preview https://deploy-preview-217--devfra.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.
🤖 Make changes Run an agent on this branch

To edit notification comments on pull requests, go to your Netlify project configuration.

@antfu
antfu merged commit 595eb81 into main Aug 14, 2026
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Port fix from vitejs/devtools#520: allocate standalone WebSocket ports atomically

2 participants