For some reason, the lockfile was not in sync anymore with the
package.json file:
> `npm ci` can only install packages when your package.json and package-lock.json or npm-shrinkwrap.json are in sync.
That may be linked to a new version of Node.js (v16.15.1).
This is similar to `onAny()`, but for outgoing packets.
Syntax:
```js
socket.onAnyOutgoing((event, ...args) => {
console.log(event);
});
```
Related: 531104d332
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]: socketio/socket.io-client#1536
Related: df32277c3f
The "disconnect" 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("disconnect", (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); // ""
});
```
Related: b9252e2074
Previously, calling `socket.disconnect().connect()` could, if the
connection was upgraded to WebSocket, result in "disconnect" being
emitted twice, and an engine being leaked.
Here's what happened:
> socket.disconnect()
- calls `socket.destroy()` so the socket doesn't listen to the manager events anymore
- then calls `manager._close()` which closes the underlying engine but not the manager itself (it waits for the "close" event of the engine)
> socket.connect()
- calls `socket.subEvents()` so the socket does listen to the manager events
- calls `manager.open()` which creates a new engine
And then the first engine emits a "close" event, which is forwarded to
the socket, hence the second "disconnect" event.
Related: https://github.com/socketio/socket.io-client/issues/1014
This restores the previous behavior, where the "io" object available in
the browser could be used as a function (`io()`) or as a namespace
(`io.connect()`).
The breaking change was introduced in [1].
Related: https://github.com/socketio/socket.io/issues/4121
[1]: 16b65698ae
This allows to control the behavior of mocked timers (@sinonjs/fake-timers),
depending on the value of the "useNativeTimers" option:
- true: use native setTimeout function
- false (default): use classic timers, that may be mocked
Related: 5d1d5bea11
Before this change, `require("socket.io-client").Socket` would return
"undefined".
Note: having access to the Socket class allows users to modify its
prototype.
Related: https://github.com/socketio/socket.io/issues/3726
Before this commit, an event sent in the "connect" handler could be
sent before the events that were buffered while disconnected.
```js
socket.on("connect", () => {
socket.emit("bar");
});
socket.emit("foo"); // buffered while disconnected
```
In the example above, the "bar" event was sent first, which is not
correct.
Related: https://github.com/socketio/socket.io-client/issues/1458
When passing the same `options` argument for two distinct Socket
instances, a new Manager was created:
```js
const opts = {};
const socket1 = io("/foo", opts);
const socket2 = io("/bar", opts);
console.log(socket1.io === socket2.io); // false
```
This bug was introduced by [1].
Note: the `options` argument is modified at the `socket.io-client`
level (path, query) and at the `engine.io-client` level (host, port),
which may not be optimal.
[1]: 7a0c2b504f
Related: https://github.com/socketio/socket.io/issues/3898
With autoUnref set to true (default: false), the Socket.IO client will
allow the program to exit if there is no other active timer/socket in
the event system.
```js
const socket = io({
autoUnref: true
});
```
Note: this option only applies to Node.js clients.
Related: https://github.com/socketio/socket.io-client/issues/1446
Previously, the following code:
```js
const socket1 = io({
path: "/test1"
});
const socket2 = io({
path: "/test2"
});
```
would result in one single Manager, with the "/test2" path being
silently ignored.
Two distinct Manager instances will now be created.
Related: https://github.com/socketio/socket.io-client/issues/1225
Having type `Object` it was not possible to set values, e.g.:
```ts
if (!this.socket.io.opts.query) {
this.socket.io.opts.query = {};
}
this.socket.io.opts.query.token = 'abc123';
```
Results in error:
> Element implicitly has an 'any' type because expression of type '"token"' can't be used to index type 'Object'.
When a given socket was disconnected, either by the server-side or by the client-side, the manager was closed too, regardless of the other connected sockets.
```js
const socket1 = io({
autoConnect: false
});
const socket2 = io("/test");
socket1.disconnect(); // also disconnect socket2
```
This bug was introduced in [1].
[1]: b60e909039
