This major bump creates a lot of noise, but it is necessary for
prettier to be able to parse new syntax such as:
- typed imports: `import { type xxx } from ...`
- private attributes: `class A { #b; #c() {} }`
The "addTrailingSlash" option allows to control whether a trailing
slash is added to the path of the HTTP requests created by the library:
- true (default): "/engine.io/"
- false: "/engine.io"
Related: https://github.com/socketio/socket.io-client/issues/1550
Signed-off-by: iifawzi <iifawzie@gmail.com>
This commit allows to:
- provide an ESM version of those modules ([1])
- reduce the attack surface in case of supply chain attacks
- reduce the size of the bundle with tree-shaking
As a downside, we won't receive security updates for those modules
anymore.
[1]: https://github.com/socketio/socket.io-client/issues/1536
In the past, there were two implementations of the HTTP long-polling
feature, one with XMLHttpRequest and one based on JSONP for ancient
browsers (IE7/IE8). The JSONP implementation has been removed in [1].
[1]: b2c73812e9
The close event will now include additional details to help debugging
if anything has gone wrong.
Example when a payload is over the maxHttpBufferSize value in HTTP
long-polling mode:
```js
socket.on("close", (reason, details) => {
console.log(reason); // "transport error"
// in that case, details is an error object
console.log(details.message); "xhr post error"
console.log(details.description); // 413 (the HTTP status of the response)
// details.context refers to the XMLHttpRequest object
console.log(details.context.status); // 413
console.log(details.context.responseText); // ""
});
```
Note: the error object was already included before this commit and is
kept for backward compatibility
Example when a payload is over the maxHttpBufferSize value with
WebSockets:
```js
socket.on("close", (reason, details) => {
console.log(reason); // "transport close"
// in that case, details is a plain object
console.log(details.description); // "websocket connection closed"
// details.context is a CloseEvent object
console.log(details.context.code); // 1009 (which means "Message Too Big")
console.log(details.context.reason); // ""
});
```
Example within a cluster without sticky sessions:
```js
socket.on("close", (reason, details) => {
console.log(details.context.status); // 400
console.log(details.context.responseText); // '{"code":1,"message":"Session ID unknown"}'
});
```
Note: we could also print some warnings in development for the "usual"
errors:
- CORS error
- HTTP 400 with multiple nodes
- HTTP 413 with maxHttpBufferSize
but that would require an additional step when going to production
(i.e. setting NODE_ENV variable to "production"). This is open to
discussion!
Related:
- https://github.com/socketio/socket.io/issues/3946
- https://github.com/socketio/socket.io/issues/1979
- https://github.com/socketio/socket.io-client/issues/1518
The server will now include a "maxPayload" field in the handshake
details, allowing the clients to decide how many packets they have to
send to stay under the maxHttpBufferSize value.
Related:
- https://github.com/socketio/socket.io-client/issues/1531
- 088dcb4dff
This restores the possibility to import the bundle directly, without
getting the following error:
> [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './dist/engine.io.min.js' is not defined by "exports"
On macOS the script was interpreted as the value of the `-i` option. It
will now use an empty extension for the `-i` option and the `-e` option
to specify the script.
Some bundlers (like vite) do not support having a "browser" field in a
nested package.json.
Note: the previous commit ([1]) fixed the resolution of the "browser"
field in the dev bundle, but the production bundle still failed.
Related: https://github.com/socketio/socket.io-client/issues/1504
[1]: 49719142f6
