feat(hub): bake mounts outside the hub base as deploy-root siblings - #355
Conversation
Relax buildHub's resolveOutPath so a mount base outside the hub base resolves to outDir's parent (the deploy root) by its absolute path, with the hub subtree still at outDir. This lets buildHub bake a context whose devframe SPAs and assets are served as top-level siblings of the hub base (Vite DevTools' layout) rather than children of it. Closes #353
◈ PR Lens
Architecture 2 components touched across 3 lanes. Data flow
Drill down
|
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
What
buildHub'sresolveOutPaththrewDF8006for any mount whose URL base didn't start with the hubbase, so it could only bake a hub where every devframe mounts under the hub base. Vite DevTools serves its hub at/__devtools/but keeps its devframe SPAs and vendored assets as top-level siblings (/__devframes_plugin_inspect/,/__devtools-assets/), sobuildHub({ context })couldn't bake that layout.This relaxes
resolveOutPath(option 2 from the issue): a mount under the hub base still writes intooutDir(the hub subtree), and any other absolute base resolves tooutDir's parent — the deploy root — by its absolute path. No new option; per-frame metas and the index follow automatically since they already readctx.frames+ctx.views.buildStaticDirs.DF8006now only fires for a non-absolute base, and its message/docs page are updated to match.Why
The hub base is a protocol namespace deliberately distinct from where each integration's SPA and assets are served. A deploy-root layout where the hub base and the devframe/asset bases are siblings under a common root is a legitimate deploy shape, and this was the last gap before Vite DevTools can retire its hand-rolled
build-static.tsand bake purely throughbuildHub.Closes #353.
This PR was created with the help of an agent.