fastify websockets breaking change about graphql-ws HOT 4 OPEN

Hey hey, thanks for reporting this! We could detect the socket location during runtime, but the hard part is actually the TS types...

IDK how to approach this. Maybe release a new major version of graphql-ws that has no support for the legacy fastify? What do you think?

from graphql-ws.

It may be better yes, a runtime check doesn't feel right.
I'm a bit surprised by their change: even if under a new major version it is only referenced as a "fix" on the release. But the correction breaks the interface with much more to do on the user side.

from graphql-ws.

@enisdenjo would you be open to having v10 support behind a config option? e.g. rawWebSocket and when it's set to true the first parameter of the handler is treated as the websocket instead of a connection object.

When the config option is used, the extra data can switch from providing connection to providing socket.

This would keep functionality the same for v9 and below while allowing v10 and above to be supported with only a minor release as these changes are technically not a breaking change due to having to explicitly opt-in.

Example usage for v10:

fastify.get('/graphql', { websocket: true }, makeHandler({ schema, rawWebSocket: true }));

from graphql-ws.

@charsleysa the issue is not only in runtime, but also with TS types - they dont work when using the latest fastify websockets.

from graphql-ws.