Summary
instance-shell always loads the Node crossws adapter, so the WebSocket RPC transport throws on Bun even though devframe ships a Bun transport.
Reproduction
Any consumer of the hub running on the Bun runtime. Smallest one I have is Vite DevTools:
bun add -d @vitejs/devtools
bunx --bun vite-devtools
error: [crossws] Using Node.js adapter in an incompatible environment.
at nodeAdapter (crossws/dist/_chunks/node.mjs:16:61)
at attachWsRpcTransport (devframe/dist/ws-server-BdSLrhxE.mjs:214:13)
at bindHttpAndWs (devframe/dist/instance-shell-CpVW4zG0.mjs:65:21)
at async init (devframe/dist/instance-shell-CpVW4zG0.mjs:342:20)
at async createDevToolsHub (@vitejs/devtools/dist/server-BZxhAPhu.js:82:8)
at async configureServer (@vitejs/devtools/dist/server-BWaga9SM.js:347:27)
The same command on Node (bunx vite-devtools, no --bun) starts normally, so the runtime is the only variable.
Cause
crossws's Node adapter refuses non-Node runtimes by design:
if ("Deno" in globalThis || "Bun" in globalThis)
throw new Error("[crossws] Using Node.js adapter in an incompatible environment.");
Everything needed to avoid it is already here — packages/devframe/src/rpc/transports/ws-bun.ts exists and is exported as devframe/rpc/transports/ws-bun — but packages/devframe/src/node/instance-shell.ts reaches for the Node transport unconditionally:
const { attachWsRpcTransport } = await import("./rpc/transports/ws-server.mjs");
There is no runtime check and, as far as I can see, no option letting a caller pick the transport, so a consumer on Bun cannot route around it.
Suggestion
Either detect the runtime in instance-shell and pick ws-bun / ws-deno / ws-server accordingly, or accept the transport as an option so downstream tools can choose. Happy to open a PR for whichever you prefer.
Versions
- devframe 0.9.7,
@devframes/hub 0.9.7
- crossws 0.4.12
- Bun 1.4.0, macOS (arm64)
- Reproduced through
@vitejs/devtools 0.6.2 with Vite 8.2.2
Summary
instance-shellalways loads the Nodecrosswsadapter, so the WebSocket RPC transport throws on Bun even though devframe ships a Bun transport.Reproduction
Any consumer of the hub running on the Bun runtime. Smallest one I have is Vite DevTools:
The same command on Node (
bunx vite-devtools, no--bun) starts normally, so the runtime is the only variable.Cause
crossws's Node adapter refuses non-Node runtimes by design:Everything needed to avoid it is already here —
packages/devframe/src/rpc/transports/ws-bun.tsexists and is exported asdevframe/rpc/transports/ws-bun— butpackages/devframe/src/node/instance-shell.tsreaches for the Node transport unconditionally:There is no runtime check and, as far as I can see, no option letting a caller pick the transport, so a consumer on Bun cannot route around it.
Suggestion
Either detect the runtime in
instance-shelland pickws-bun/ws-deno/ws-serveraccordingly, or accept the transport as an option so downstream tools can choose. Happy to open a PR for whichever you prefer.Versions
@devframes/hub0.9.7@vitejs/devtools0.6.2 with Vite 8.2.2