Add bun support

[aron-cf]

Add Bun ServerWebSocket support to capnweb.

Bun's server-side WebSocket uses callback-based handlers registered on Bun.serve() rather than the standard addEventListener interface. Passing a Bun ServerWebSocket to newWebSocketRpcSession() silently fails because the event listeners never fire. (#61)

A new BunWebSocketTransport implements the RpcTransport interface using the same resolver pattern as the existing WebSocket and MessagePort transports. It exposes dispatchMessage, dispatchClose, and dispatchError methods that Bun's handler callbacks invoke to feed messages into the transport.

Two convenience functions sit on top of the transport. newBunWebSocketRpcHandler() returns a complete handler object you can pass straight to Bun.serve(), wiring everything up automatically via ws.data. newBunWebSocketRpcSession() returns the stub and transport for users who need custom handler logic.

The readme now documents both approaches and notes that Bun is a supported runtime.

Quick start with the handler helper

import { RpcTarget, newBunWebSocketRpcHandler } from "capnweb";

class MyApi extends RpcTarget {
  greet(name: string) { return `Hello, ${name}!`; }
}

let rpcHandler = newBunWebSocketRpcHandler(() => new MyApi());

Bun.serve({
  fetch(req, server) {
    if (server.upgrade(req)) return;
    return new Response("Not Found", { status: 404 });
  },
  websocket: rpcHandler,
});

Escape hatch with manual wiring

import { newBunWebSocketRpcSession, RpcTarget } from "capnweb";

class MyApi extends RpcTarget {
  greet(name: string) { return `Hello, ${name}!`; }
}

Bun.serve({
  fetch(req, server) {
    let userId = authenticate(req);
    server.upgrade(req, { data: { userId } });
  },
  websocket: {
    open(ws) {
      let { stub, transport } = newBunWebSocketRpcSession(ws, new MyApi());
      ws.data.transport = transport;
    },
    message(ws, msg) { ws.data.transport.dispatchMessage(msg); },
    close(ws, code, reason) { ws.data.transport.dispatchClose(code, reason); },
    error(ws, err) { ws.data.transport.dispatchError(err); },
  },
});

Testing locally

Run the test suite with npm test. The new tests in __tests__/bun.test.ts exercise the transport, both convenience functions, and full round-trip calls through a loopback pair without needing a real Bun server.

Unit tests cover message queuing, close and error propagation, abort semantics, buffer-to-string conversion, and end-to-end calls including bidirectional callbacks and error forwarding. All existing tests continue to pass.

Closes #61

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/cloudflare/capnweb@159

commit: 60f740e

[changeset-bot]

🦋 Changeset detected

Latest commit: 60f740e

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
capnweb	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[aron-cf]

I have read the CLA Document and I hereby sign the CLA

[aron-cf]

recheck

[kentonv]

In package.json we currently have a special separate build for workerd that includes the workers-only stuff. Maybe we should have a separate build for bun, too? Avoid code bloat for other runtimes.

  "exports": {
    ".": {
      "types": "./dist/index.d.ts",
      "import": {
        "workerd": "./dist/index-workers.js",
        "default": "./dist/index.js"
      },
      "require": {
        "workerd": "./dist/index-workers.cjs",
        "default": "./dist/index.cjs"
      }
    }
  },

[kentonv]

I'm a bit confused how the bun test passes on node, unless it's not actually testing integration with Bun's builtin APIs. If it isn't testing integration then I don't think it's a useful test.

Can we add Bun to the test matrix, and write a test that actually tests against Bun's built-in APIs?