fix(client): coerce ws scheme on forwarded upgrade target (fixes #1)

[tlgimenes]

Summary

Fixes #1 — WebSocket upstream URL not coerced to ws://, HMR fails under Bun.

handleWebSocket in handlers.client.ts was passing an http(s):-scheme URL straight to new WebSocket(...). Node's built-in WebSocket (undici) silently rewrites the scheme to ws:, so it worked there — but Bun keeps the http: scheme and the handshake fails immediately, killing every WebSocket forwarded through the tunnel.

In practice this broke any dev-server feature that rides a WebSocket (Vite HMR, Next.js webpack-hmr / Turbopack HMR) when the warp client ran under Bun — including bunx decocms link.

Change

In handlers.client.ts, coerce the URL's protocol from http(s): → ws(s): before constructing the WebSocket:

const target = new URL(message.url, state.localAddr);
target.protocol = target.protocol === "https:" ? "wss:" : "ws:";
const ws = new WebSocket(target);

Behavior under Node is unchanged (undici was already doing this conversion); Bun and any spec-strict runtime now work correctly.

Also includes a package-lock.json sync to match package.json (version + Node engines bump that was already in the lockfile-adjacent state).

Files

• handlers.client.ts — scheme coercion + explanatory comment
• package-lock.json — version/engines sync

Test plan

• npm run typecheck — clean
• npm test — 14/14 passing (vitest)
• Manual: run bunx decocms link against a Next.js / Vite dev server and confirm HMR WebSockets connect through the tunnel (previously failed before handshake under Bun)
• Confirm no regression under Node 22+ (undici path was already doing this conversion implicitly)

🤖 Generated with Claude Code