feat: upgrade devframe to v0.9.1 and adopt bare-specifier dock client script resolution - #534
Merged
Conversation
…nt scripts Bump the shared devframe ref to ^0.9.1 and adopt devframes/devframe#257. Vite DevTools calls initHub directly, so it advertises the Vite clientModuleResolution template ('/@id/{specifier}') itself — gated on a live Vite dev server so bare-specifier dock client scripts (e.g. vue-tracer's) resolve through the inspected app's module graph, while the standalone CLI and static build snapshots keep the URL contract.
@vitejs/devtools
@vitejs/devtools-kit
@vitejs/devtools-oxc
@vitejs/devtools-rolldown
@vitejs/devtools-vite
@vitejs/devtools-vitest
commit: |
v0.9.1's Services feature (devframes/devframe#256) has the client read the devframe:services shared state on load. A static snapshot doesn't stand up the live hub, so nothing fired the services barrier that publishes that state — leaving the RPC dump without a match and the client logging a hard error. Fire context.services.ready() before collecting the dump (idempotent; publishes an empty state when no services are installed), mirroring the dock-renderers seeding.
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.
What
Upgrades the shared
devframecatalog ref from^0.9.0to^0.9.1and adopts the follow-up work named in devframes/devframe#257.Why
Since v0.9's init/middleware refactor, hub assets are served verbatim ahead of Vite's transform pipeline, so a dock client script declared with a bare npm specifier (e.g. vue-tracer's
importFrom: 'vite-plugin-vue-tracer/client/vite-devtools', used inplaygrounds/core) reaches the browser's nativeimport()unresolved and throws.devframe v0.9.1 lets a Vite host advertise a client-module resolution template via
initHub({ clientModuleResolution }).@devframes/vite/hubpasses'/@id/{specifier}'by default, but Vite DevTools callsinitHubdirectly, so it has to declare the template itself — PR #257 calls this out as the one-line adoption for@vitejs/devtools-kit.How
createDevToolsHubnow passesclientModuleResolution: '/@id/{specifier}', gated oncontext.viteServer. Only the serve path has a live Vite dev server whose/@id/can resolve modules through the inspected app's graph; the standalone CLI and static build snapshots have no module graph, so the template stays undeclared there (preserving devframe's URL contract). Added a test covering both branches.The rest of v0.9.1 (Services, hub-ui / json-render-ui / hub-next fixes) is additive and needs no adaption.
Verified with
pnpm build && pnpm typecheck && pnpm test && pnpm lint.This PR was created with the help of an agent.