Issue: Blob payload is not handled

[blouflashdb]

Issue: Browser WebSocket Converts Binary Data to Blob

Description

When using @open-rpc/client-js with a WebSocketTransport in a browser environment, binary data sent from the server is received as a Blob. This behavior causes issues when trying to process the payload in resolveResponse with JSON.parse(payload), as Blob cannot be directly parsed into JSON.

In contrast, when using the library in a Node.js environment, the WebSocket receives binary data as a Buffer, which can be directly passed to JSON.parse to obtain the desired object.

Expected Behavior

The library should handle WebSocket messages consistently across browser and Node.js environments. Binary data sent from the server should be correctly converted into a string or JSON object, regardless of whether the client is running in a browser or Node.js.

Actual Behavior

In the browser:

• Binary data sent from the server is received as a Blob.
• The Blob cannot be directly processed by JSON.parse.

In Node.js:

• Binary data is received as a Buffer.
• The Buffer can be successfully processed by JSON.parse.

Steps to Reproduce

1. Use @open-rpc/client-js with WebSocketTransport in a browser.
2. Connect to a WebSocket server that sends JSON-RPC notifications as binary data.
3. Observe that the incoming data is a Blob and cannot be processed by JSON.parse.

Proposed Solution

• Modify the WebSocketTransport implementation to detect when incoming messages are Blob objects in the browser.
• Convert the Blob to a string using Blob.text() or a similar method before passing it to JSON.parse.

Environment

• @open-rpc/client-js version: 1.8.1
• Browser: Brave Version 1.73.105 Chromium: 131.0.6778.265 (Official Build) (64-bit)
• Node.js version: 22.11
• Operating System: Ubuntu 24.04.1 LTS

Additional Context

This discrepancy between browsers and Node.js arises because the browser WebSocket implementation defaults to converting binary data into Blob, while Node.js treats it as a Buffer.

It would be great if the library could handle this scenario internally to ensure consistent behavior across environments.

[zcstarr]

@blouflashdb would you mind testing the latest version 2.0.0, we now bundle the browser esm with bun which might polyfill the ws more accurately than before.

would be awesome if you took another look, if not we're not in a better position to actually make the PR such that it's consistent across both environments.

[blouflashdb]

@blouflashdb would you mind testing the latest version 2.0.0, we now bundle the browser esm with bun which might polyfill the ws more accurately than before.

would be awesome if you took another look, if not we're not in a better position to actually make the PR such that it's consistent across both environments.

I will take a look when I have the time.