Apollo-link: [apollo-link-ws] Uncaught DOMException: Failed to construct 'WebSocket': The URL 'undefined' is invalid.

[nuragic]

Hi,

The issue is described in https://github.com/prisma/graphql-playground/issues/600 but I think it should be opened here.

To summarise:

// Using the SubscriptionClient syntax stopped working for some reason
const subscriptionClient = new SubscriptionClient(GRAPHQL_ENDPOINT, {
  reconnect: true,
  connectionParams: {
    authToken: access_token,
  },
});
const link = new WebSocketLink(subscriptionClient);  // throws


// This one still works
const link = new WebSocketLink({
  uri: GRAPHQL_ENDPOINT,
  options: {
    reconnect: true,
    connectionParams: {
      authToken: access_token,
    },
  }
});

Please read the original issue above; if you can't reproduce the problem I'll try to setup a CodeSandbox ASAP.

Thanks in advance! ❤️

[frandiox]

@nuragic It sometimes works when I remove node_modules/yarn.lock and reinstall. But normally after installing a new dependency it breaks again 🤔
I've checked the dependencies and both apollo-link-ws and subscriptions-transport-ws are updated to the latest version.

[frandiox]

@nuragic Just found the issue. apollo-link-ws has "subscriptions-transport-ws": "^0.9.0" as a peerDependency. If you have two different packages installing different versions of subscriptions-transport-ws, the SubscriptionClient object created and the one expected by apollo-link-ws could be created by different versions.

In my case, prisma-binding includes other versions of both apollo-link-ws and subscriptions-transport-ws and this is being merged by yarn workspaces.

As a quick workaround, I explicitly installed subscriptions-transport-ws@^0.9.14 and apollo-link-ws@^1.0.8 and it works again.

I think apollo-link-ws shouldn't use instanceof to check the SubscriptionClient received to avoid issues like this. Perhaps checking url and other properties would be better.

[nuragic]

@frandiox Ohhh! Thanks for digging into this, I think I've got the problem... FYI I'm also using yarn workspaces + lerna to manage a monorepo (we have both client and server in separate packages).

I agree about not using instanceof; I guess duck typing is better suited here. 🦆

Are you going to send a PR to fix that? 😄

[weizihua]

The program comes here, using instanceof to make the judgment, the returned result is actually false

[DecentM]

I've done some digging and after setting a few breakpoints, it looks like that on line #42 of webSocketLink.ts, paramsOrClient.uri should be paramsOrClient.url instead.

I haven't looked into where that comes from, so I think it would be a good idea to do this instead until the correct name can be determined:

this.subscriptionClient = new SubscriptionClient(
  paramsOrClient.uri || paramsOrClient.url,
  paramsOrClient.options,
  paramsOrClient.webSocketImpl,
);

[frandiox]

@DecentM SubscriptionClient's constructor has its own input different from SubscriptionClient instance itself. It gets uri, options and wsImpl while the instance has url and other different properties instead (no options, looks like). Therefore, the problem here is likely in instanceof check as mentioned in https://github.com/apollographql/apollo-link/issues/773#issuecomment-420171145

@hwillson Should it check paramsOrClient.url instead of instanceof SubscriptionClient?

[j-oshb]

Check that you only have subscriptions-transport-ws package installed once, e.g.:

$ find . -name subscriptions-transport-ws

Should only return one line:

./ui/node_modules/subscriptions-transport-ws

In my case it was installed twice, and despite being the same version, if an instance is created using one package, it will fail the instanceof check against the other package.

I ended up with two packages because apollo-link-ws has subscriptions-transport-ws in both devDependencies and peerDependencies.

I got it to work by removing the dev dependency.

[nuragic]

@j-oshb

apollo-link-ws has subscriptions-transport-ws in both devDependencies and peerDependencies.

Boom! You got it. 😄

I guess that by changing the package.json and doing a patch release it'll work...however, I'm not sure if they did so for some reason... anyway, not sure if the same dependency could exist in both dependencies|devDependencies and peerDependencies ... 🤔