You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(examples): serve the demo dock client from source; diagnose resolved-but-unservable client scripts
The hub-vite demo failed with 'Failed to fetch dynamically imported
module' whenever demo-dock-client's dist was absent (running vite
without the repo build): Vite couldn't resolve the /@id/ request's
exports target and the SPA index.html fallback answered 200 with HTML.
The package's '.' export now points at src/index.ts — a Vite host
transforms the linked source directly, so the bare-specifier path needs
no build at all; tsdown keeps building only the URL-shape artifacts
(dist/bundle.mjs + dist/node.mjs for the Next host).
Both browser loaders also gain a second diagnosis branch via the shared
clientScriptFailureHint(): when a bare specifier WAS resolved through
the host template and the import still failed, the error now points at
the module being unservable on the host (package not installed/built)
instead of leaving only the browser's opaque TypeError.
Copy file name to clipboardExpand all lines: examples/demo-dock-client/README.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,15 +2,15 @@
2
2
3
3
The shared dock client script the two reference hubs consume in their two supported shapes — one package, both `importFrom` forms:
4
4
5
-
-**`hub-vite`** registers it by **bare specifier** (`action: { importFrom: 'demo-dock-client' }`). The Vite host advertises `clientModuleResolution: '/@id/{specifier}'` (the `@devframes/vite/hub` default), so the client host imports `dist/index.mjs` through Vite's own module graph — its bare `nanoevents` import resolves there too.
5
+
-**`hub-vite`** registers it by **bare specifier** (`action: { importFrom: 'demo-dock-client' }`). The Vite host advertises `clientModuleResolution: '/@id/{specifier}'` (the `@devframes/vite/hub` default), so the client host imports `src/index.ts` through Vite's own module graph — Vite transforms the linked source directly (no build needed on this path) and resolves its bare `nanoevents` import there too.
6
6
-**`hub-next`** mounts the prebuilt **self-contained bundle** (`dist/bundle.mjs`, nanoevents inlined) statically and passes the served URL. Next declares no `clientModuleResolution`, so the URL shape is the supported one there.
7
7
8
8
The script itself demonstrates the state pattern bare-specifier plugins should follow: shared state anchored on `globalThis` (`__devframes_demo_dock_client__`), the same design as `vite-plugin-vue-tracer`'s `__vue_tracer__` store — realm identity is the contract, module identity is best-effort. On each dock activation it bumps the shared counter and reports into the hub's messages feed, naming the URL it was loaded from.
9
9
10
10
## Entries
11
11
12
-
| Entry |Built as| Role |
12
+
| Entry |Resolves to| Role |
13
13
|---|---|---|
14
-
|`demo-dock-client`|`dist/index.mjs` (deps external) | Bare-specifier consumption through a host's module graph |
15
-
| — |`dist/bundle.mjs` (self-contained) | URL consumption on hosts without bare-specifier resolution |
16
-
|`demo-dock-client/node`|`dist/node.mjs`| Node helper exporting `demoDockClientBundlePath` for static mounting |
14
+
|`demo-dock-client`|`src/index.ts` (source, deps bare) | Bare-specifier consumption through a host's module graph |
15
+
| — |`dist/bundle.mjs` (self-contained build) | URL consumption on hosts without bare-specifier resolution |
16
+
|`demo-dock-client/node`|`dist/node.mjs`(build) | Node helper exporting `demoDockClientBundlePath` for static mounting |
0 commit comments