fix(devframe): carry meta base for cross-base RPC inheritance; surface missing mountConnectionMeta#98
Merged
Merged
Conversation
…e missing mountConnectionMeta A mounted devframe SPA inherits the connection meta from a same-origin parent window before it fetches its own `__connection.json`. The meta was published with a relative `websocket.path` but without the base it was resolved against, so a child mounted at a different base resolved the path against its own mount and dialed the wrong endpoint. Publish the meta paired with the absolute (proxy-safe) base it was resolved from, and have the client inherit that base. Backward-compatible: a bare ConnectionMeta on the shared key is still accepted. Exposes `readPublishedConnectionMeta` + `PublishedConnectionMeta` so hosts can reuse the shape. Also make a missing host `mountConnectionMeta` non-silent: mounting a devframe with a servable distDir on a host lacking the hook previously fell through to the HTML fallback and broke the SPA silently. Emit a new DF8106 diagnostic instead.
✅ Deploy Preview for devfra ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Replace the published `{ meta, metaBaseUrl }` wrapper with an optional
`baseUrl` field annotated directly onto the ConnectionMeta the client
publishes on the shared window. The value on the window stays a plain
ConnectionMeta, dropping the wrapper type and the dual-form detection
helper. `baseUrl` is client-annotated (not served), documented as such.
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.
Background
vitejs/devtools#414 is a downstream workaround in
@vitejs/devtools-kitfor two root causes its author flags as living upstream in devframe. This PR fixes both here, so the kit (and any other hub) no longer has to work around them.Root cause 1 — same-origin meta inheritance dropped its base
A mounted devframe SPA inherits the connection meta from a same-origin parent window before it fetches its own
__connection.json. The meta was published with a relativewebsocket.pathbut without the base it was resolved against, so a child mounted at a different base (a hub mounting Terminals, the Inspector, …) resolved that path against its own mount and dialed the wrong endpoint. The kit worked around this with an entiregetDevToolsRpcClientwrapper that republishes an absolute path.Now the client annotates the meta it publishes on the shared window with an optional
baseUrlfield — the absolute, browser-derived (proxy-safe) URL of the__connection.jsonit was loaded from — and an inheriting client resolves the WS path against that base rather than its own. The value on the window stays a plainConnectionMeta(no wrapper object), andbaseUrlis client-annotated, not part of the served JSON.Root cause 2 — missing
mountConnectionMetafailed silentlymountDevframeinvokedctx.host.mountConnectionMeta?.(base), so a host that forgot to implement the hook became a silent no-op: the SPA's./__connection.jsonfetch fell through to the HTML fallback and its panel stayed empty / stuck loading. Mounting a devframe with a servabledistDiron such a host now emits a new DF8106 diagnostic. Static-snapshot hosts that bake the file can implement a no-op to acknowledge it.Also
ConnectionMeta.baseUrl(optional, client-annotated) and documented it.DevframeHost.mountConnectionMetadoc,docs/guide/hub.md, and addeddocs/errors/DF8106.md.Verification
pnpm lint,pnpm typecheck,pnpm build, andpnpm test(664 passed) all pass.This PR was created with the help of an agent.