graphiql: lsp server doesn't start using coc.vim

@benjie thank you! Hopefully someone has time or interest. @stonexer perhaps you‘d be interested in taking a look? Both vscode and nvim coc have changed their exception handling all of a sudden and I just resolved the former.

I think it’s just a lingering uncaught exception somewhere, or just that the LSP server is behaving differently because of something the nvim coc client expects. I tried debugging the LSP server with vim to log to output channel uncaught exceptions using process.on(), but i couldn’t get my vim instance to load the locally built LSP server I was trying to debug, or this was not showing an uncaught exception. I at least figured out some of the COC commands for debugging the lsp server in vim.

@wongjiahau glad to hear it’s not just me and that there are workarounds for both CoC and the native LSP client.

The other issue could be the difference between what we are returning to the client in terms of specified capabilities, and what we are using.

I will set up nvim coc later this week or next and take a look, I am on holiday this week

I am having the same issue with the version 3.2.27, using vanilla config provided by neovim/nvim-lspconfig so still no fix…

There are others having the same problem

3.3.0 of the cli has been released! i think this should take care of it. if anyone else is having issues after this update, please re-open

Thank you very much @acao graphql-language-service-cli@3.3.0-canary-0ab0e498.0 works for me.

Just another update on this before doing some more digging.

I have managed to get this working by building graphql-language-service-cli locally and then symlinking that package instead of using the downloaded one.

For my installation this looks like:

❯ pwd
/Users/wilhelmeek/.local/share/nvim/lsp_servers/graphql

❯ ls -F node_modules 
graphql/                      graphql-language-service-cli@

As to why the downloaded package differs from a locally-build one—I do not know.

I am curious to hear if this also resolves the issue for others.

3.2.27 as well using neovim/nvim-lspconfig.

My logs show the following errors:

graphql-language-service-usage-logs: Error: Cannot read property 'catch' of undefined\n"
UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'getProjectForFile' of undefined\n    at MessageProcessor.handleDidOpenOrSaveNotification (/Users/wilhelmeek/.config/yarn/global/node_modules/graphql-language-service-server/dist/MessageProcessor.js:193:44)\n    at processTicksAndRejections (internal/process/task_queues.js:95:5)\n    at async /Users/wilhelmeek/.config/yarn/global/node_modules/graphql-language-service-server/dist/startServer.js:145:29\n"
UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'catch' of undefined\n    at reply (/Users/wilhelmeek/.config/yarn/global/node_modules/vscode-languageserver-protocol/node_modules/vscode-jsonrpc/lib/common/connection.js:375:41)\n    at /Users/wilhelmeek/.config/yarn/global/node_modules/vscode-languageserver-protocol/node_modules/vscode-jsonrpc/lib/common/connection.js:454:25\n"

Haven’t looked into it deeply, but quick skim looks like it may be related to the GraphQLCache object on the MessageProcessor.

@acao tagging you because you asked for a stack trace above

I’m afraid the fix is not enough for yarn user like me (install graphql-language-service-cli with yarn global add)

Go to yarn global dir, and run yarn why vscode-languageserver-protocol show

yarn why v1.22.18
warning package.json: No license field
[1/4] 🤔  Why do we have the module "vscode-languageserver-protocol"...?
[2/4] 🚚  Initialising dependency graph...
[3/4] 🔍  Finding dependency...
[4/4] 🚡  Calculating file sizes...
=> Found "vscode-languageserver-protocol@3.15.3"
info Reasons this module exists
   - "graphql-language-service-cli#graphql-language-service-server" depends on it
   - Hoisted from "graphql-language-service-cli#graphql-language-service-server#vscode-languageserver-protocol"
info Disk size without dependencies: "284KB"
info Disk size with unique dependencies: "836KB"
info Disk size with transitive dependencies: "836KB"
info Number of shared dependencies: 2
=> Found "vscode-languageserver#vscode-languageserver-protocol@3.17.1"
info This module exists because "graphql-language-service-cli#graphql-language-service-server#vscode-languageserver" depends on it.
info Disk size without dependencies: "504KB"
info Disk size with unique dependencies: "1.03MB"
info Disk size with transitive dependencies: "1.03MB"
info Number of shared dependencies: 2
✨  Done in 0.23s.

yarn doesn’t select the hoisted version for vscode-languageserver#vscode-languageserver-protocol, but instead use the latest version satisfy version range specified in vscode-languageserver package.json.

I guess we have to upgrade vscode-languageserver to latest version to fix this completely (which could be very time consuming)

---

Workaround: add resolutions field to package.json file in yarn global dir force yarn to choose vscode-languageserver-protocol@3.15.3

  "resolutions": {
    "graphql-language-service-cli/graphql-language-service-server/vscode-languageserver/vscode-languageserver-protocol": "3.15.3"
  }

3.2.30 works for me too! Thank you @acao and @howlinbash 🙏

Thanks @acao and @howlinbash — works great now 🙏

I can’t say anything about coc, but 3.2.30 fixed the graphql language service with the neovim lsp client (which I think was the same issue)! Thanks for the release 🙏🏻

I have the same problem. I wont be able to do much work on it today but I can offer a slight improvement to graphql-lsp binary.

https://github.com/graphql/graphiql/blob/main/packages/graphql-language-service-cli/src/cli.ts#L113-L115

      process.stdout.write(
        'An error was thrown from GraphQL language service: ' + String(error),
      );

This line should be changed to

process.stderr.write(

Also I console.logged the error and I got a stack trace from :CocCommand workspace.showOutput

TypeError: Cannot read properties of undefined (reading 'catch')
    at reply (/home/bash/.nvm/versions/node/v16.15.1/lib/node_modules/graphql-language-service-cli/node_modules/vscode-languageserver-protocol/node_modules/vscode-jsonrpc/lib/common/connection.js:375:41)
    at /home/bash/.nvm/versions/node/v16.15.1/lib/node_modules/graphql-language-service-cli/node_modules/vscode-languageserver-protocol/node_modules/vscode-jsonrpc/lib/common/connection.js:454:25
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
An error was thrown from GraphQL language service: TypeError: Cannot read properties of undefined (reading 'catch')[Info  - 10:59:56] Connection to server got closed. Server will restart.

This line in the vscode-jsonrpc is returning undefined from the write method

    messageWriter.write(message).catch(() => logger.error(`Sending response failed.`));

I will have a little bit more time to look at this next week perhaps but thought I should at least share these findings for now.

@acao, Would you like me to make a PR for the stdout --> stderr change?

Hey @acao very sorry for the delay in replying. I’d be happy to schedule some time to have a look at this together 😄 Not sure what the best way is to get this arranged, but I can hop on a Discord or Zoom (or equiv) sometime that suits both of our timezones

@acao I’m not using Berry so global why didn’t work, but can confirm that the version of CLI I have installed is

❯ yarn global list                          
yarn global v1.22.19
info "graphql-language-service-cli@3.2.28" has binaries:
   - graphql-lsp
info "neovim@4.10.1" has binaries:
   - neovim-node-host

and my global installation for graphql-language-service-server is:

❯ pwd               
/Users/wilhelmeek/.config/yarn/global/node_modules/graphql-language-service-server

❯ cat package.json | jq '.version'
"2.7.27"

Another release inbound! Be sure that graphql-language-service-server is the latest version. If that doesn’t work, another easier workaround that might work would be to npm install -g graphql-language-service-cli@latest graphql-language-service-server@latest in case for some reason CLI is causing an outdated server version to resolve.

@wilhelmeek i could not get nvim coc working but I will try to trigger a new release of the language server soon to fix this issue. Following the github actions log for the last cli/server releases, it was a clean build from source & release, so I still don’t understand how this could happen, but hopefully another deploy just resolves it

@wilhelmeek I got it working too by building the executable locally. The one installed from npm is not working.

This is what I did:

cd ~
git clone https://github.com/graphql/graphiql.git
cd graphiql
yarn install
npm run build

Then in coc-settings.json, change the following:

 "languageserver": {                                                                                                                                                                      
   "graphql": {     
+    "command": "~/graphiql/packages/graphql-language-service-cli/bin/graphql.js",
-    "command": "graphql-lsp",
     "args": ["server", "-m", "stream"],
     "filetypes": ["typescript", "typescriptreact", "graphql"],
     "trace.server": "verbose"
   }                
 }                  

@acao enjoy your holiday! I’ll update here if I manage to resolve this in the mean time.

For posterity I am using .graphqlrc.yaml and have verified that the graphql-lsp executable on my PATH is version 3.2.19.

it works for me

does this canary release work for y’all?

graphql-language-service-cli@3.2.19-canary-5991895d.0

aka

npm install -g graphql-language-service-cli@3.2.19-canary-5991895d.0

Another change I had to make because it kept crashing “randomly”

https://github.com/graphql/graphiql/blob/e793f887b28af471c4d55522a57b61ebadafd14f/packages/graphql-language-service-server/src/MessageProcessor.ts#L291

this._settings.load?.fileName

@acao I finally make it work!

I changed these lines from here:

https://github.com/graphql/graphiql/blob/e793f887b28af471c4d55522a57b61ebadafd14f/packages/graphql-language-service-server/src/startServer.ts#L369

to

  connection.onNotification(DidChangeConfigurationNotification.type, params =>
      messageProcessor.handleDidChangeConfiguration(params)
  )

The only changes I’ve made have been to update the babel parser, which shouldn’t be causing this I imagine - can coc.vim use a different logging level to show some useful information?