Connect to a socket.io cause an this error:
(node:66998) UnhandledPromiseRejectionWarning: TypeError: Cannot read property '_cookieJar' of null
at resolve (/Users/xxx/node_modules/jsdom/lib/jsdom/living/websockets/WebSoc
ket-impl.js:124:39)
test('connection', async () => {
const port = await getPort({ port: getPort.makeRange(8080, 65535) })
const io = socketIO(port)
const connection = new Promise(resolve => {
io.on('connection', resolve)
})
const client = socket('http://localhost:' + port)
await connection
})
no errors log
Have you tried newer version of JSDOM, e.g. https://www.npmjs.com/package/jest-environment-jsdom-fifteen? Jest uses pretty outdated one because of Node 6 support (will be dropped in next major).
Have you tried newer version of JSDOM, e.g. https://www.npmjs.com/package/jest-environment-jsdom-fifteen? Jest uses pretty outdated one because of Node 6 support (will be dropped in next major).
I just tried jest-environment-jsdom-fourteen and errors also logged, but when I register an connect handler to the client-side socket intance, these errors disappears.
So it looks like it's not an issue with Jest but with jsdom or the way you use the library in tests. I'm gonna close this issue, as we can't help on that.
@chillyond did you figure this out? I am running into the same issue
@chillyond did you figure this out? I am running into the same issue
Yes, it seems if you listening connection on io instance(server side), and doesn't listening connect on socket instance(client side), then the error will appears. So you can either add a
connect listener or remove the connection listener, hope this helps you.
Hey @chillyond I am running into the same error and jest-environment-jsdom-fourteen also doesn't solve the problem for me.
Could you explain your solution a bit better? Where do you add the connect listener, on the client side or on the server side?
My stacktrace:
UnhandledPromiseRejectionWarning: TypeError: Cannot read property '_cookieJar' of null
at resolve (/home/cdimitroulas/code/headstart/hs-student-web/node_modules/jest-environment-jsdom-fourteen/node_modules/jsdom/lib/jsdom/living/websockets/WebSocket-impl.js:124:39)
at new Promise (<anonymous>)
at WebSocketImpl.openingQueues.set.openingQueues.get.then (/home/cdimitroulas/code/headstart/hs-student-web/node_modules/jest-environment-jsdom-fourteen/node_modules/jsdom/lib/jsdom/living/websockets/WebSocket-impl.js:112:94)
at <anonymous>
at process._tickCallback (internal/process/next_tick.js:189:7)
@cdimitroulas Yes, jest-environment-jsdom-fourteen doesn't solve this problem, my workround is, in brief, the client side's connect listener and the server side's connection listener must all be registered, or all not be registered, it works for me.
In my case, the transports option was mismatched between client and server, and that also triggered this bug.
@beaniemonk can you elaborate on how you fixed that?
Sure,
So on the server side I had this (short version):
// server
const sio = require("socket.io")({
transports: ["websocket", "polling"],
});
(This specific configuration is OK for our specific case, but may or may not be a good idea for yours).
On the client side, I did not specify this option, so presumably it was rolling with the default transports: ["polling", "websocket"] instead. When I changed it to match:
// client
const socket = require("socket.io-client")("foo/bar", {
transports: ["websocket", "polling"],
});
This error went away for me.
This mismatch should not be an issue normally, as far as I know -- it's something specific to the Jest/JSDOM environment.
@chillyond's suggestion of adding a socket.on("connect", ...) event handler unfortunately did not work in my case, but this did for some reason.
Most helpful comment
Sure,
So on the server side I had this (short version):
(This specific configuration is OK for our specific case, but may or may not be a good idea for yours).
On the client side, I did not specify this option, so presumably it was rolling with the default
transports: ["polling", "websocket"]instead. When I changed it to match:This error went away for me.
This mismatch should not be an issue normally, as far as I know -- it's something specific to the Jest/JSDOM environment.
@chillyond's suggestion of adding a
socket.on("connect", ...)event handler unfortunately did not work in my case, but this did for some reason.