Skip to content

6.6.0

Latest
Compare
Choose a tag to compare
@darrachequesne darrachequesne released this 21 Jun 12:16
· 2 commits to main since this release
a17cbc5

Features

Custom transport implementations

The transports option now accepts an array of transport implementations:

import { Socket, XHR, WebSocket } from "engine.io-client";

const socket = new Socket({
  transports: [XHR, WebSocket]
});

Here is the list of provided implementations:

Transport Description
Fetch HTTP long-polling based on the built-in fetch() method.
NodeXHR HTTP long-polling based on the XMLHttpRequest object provided by the xmlhttprequest-ssl package.
XHR HTTP long-polling based on the built-in XMLHttpRequest object.
NodeWebSocket WebSocket transport based on the WebSocket object provided by the ws package.
WebSocket WebSocket transport based on the built-in WebSocket object.
WebTransport WebTransport transport based on the built-in WebTransport object.

Usage:

Transport browser Node.js Deno Bun
Fetch ✅ (1)
NodeXHR
XHR
NodeWebSocket
WebSocket ✅ (2)
WebTransport

(1) since v18.0.0
(2) since v21.0.0

Added in f4d898e and b11763b.

Transport tree-shaking

The feature above also comes with the ability to exclude the code related to unused transports (a.k.a. "tree-shaking"):

import { SocketWithoutUpgrade, WebSocket } from "engine.io-client";

const socket = new SocketWithoutUpgrade({
  transports: [WebSocket]
});

In that case, the code related to HTTP long-polling and WebTransport will be excluded from the final bundle.

Added in f4d898e

Test each low-level transports

When setting the tryAllTransports option to true, if the first transport (usually, HTTP long-polling) fails, then the other transports will be tested too:

import { Socket } from "engine.io-client";

const socket = new Socket({
  tryAllTransports: true
});

This feature is useful in two cases:

  • when HTTP long-polling is disabled on the server, or if CORS fails
  • when WebSocket is tested first (with transports: ["websocket", "polling"])

The only potential downside is that the connection attempt could take more time in case of failure, as there have been reports of WebSocket connection errors taking several seconds before being detected (that's one reason for using HTTP long-polling first). That's why the option defaults to false for now.

Added in 579b243.

Bug Fixes

  • add some randomness to the cache busting string generator (b624c50)
  • fix cookie management with WebSocket (Node.js only) (e105551)

Links