tsconfig plugin error when using the standalone TS Language Server outside of VSCode

[gnakic]

Describe the bug

1. Fortunately, this still doesn't break functionality as when I highlight a symbol, be it a TS one or a GQL one, the error disappears. It is still distracting as the error tray bounces up and down as I scroll through code.
2. As soon as I highlight a keyword or a blank line, the following appears

   LSP :: Error from the Language Server: <semantic> TypeScript Server Error (5.5.2)
   Cannot read properties of undefined (reading 'kind')
   TypeError: Cannot read properties of undefined (reading 'kind')
   at Object.isCallExpression (node_modules/typescript/lib/typescript.js:30145:15)
   at isTadaPersistedCall (node_modules/@0no-co/graphqlsp/dist/chunks/api-chunk.js:1450:19)
   at Object.getPersistedCodeFixAtPosition (node_modules/@0no-co/graphqlsp/dist/chunks/api-chunk.js:3875:8)
   at a.getApplicableRefactors (node_modules/@0no-co/graphqlsp/dist/graphqlsp.js:3223:11)
   at IpcIOSession.getApplicableRefactors (node_modules/typescript/lib/typescript.js:190987:49)
   at getApplicableRefactors (node_modules/typescript/lib/typescript.js:189208:43)
   at node_modules/typescript/lib/typescript.js:191397:69
   at IpcIOSession.executeWithRequestId (node_modules/typescript/lib/typescript.js:191389:14)
   at IpcIOSession.executeCommand (node_modules/typescript/lib/typescript.js:191397:29)
   at IpcIOSession.onMessage (node_modules/typescript/lib/typescript.js:191439:51)
   at process.<anonymous> (node_modules/typescript/lib/tsserver.js:523:14)
   at process.emit (node:events:518:28)
   at emit (node:internal/child_process:951:14)
   at process.processTicksAndRejections (node:internal/process/task_queues:83:21) (Unknown error)

3. This happens when using emacs lsp. The following configuration parameter lsp-clients-typescript-prefer-use-project-ts-server is set to true to ensure the project tsserver.js is used.

Reproduction

No response

gql.tada version

gql.tada 1.8.0

Validations

• [X] I can confirm that this is a bug report, and not a feature request, RFC, question, or discussion, for which GitHub Discussions should be used
• [X] Read the docs.
• [X] Follow our Code of Conduct

[kitten]

I don't know what specific code this is caused by, but I did fix an issue that looked similar to this earlier today.

Upgrading @0no-co/graphqlsp should resolve this since we shipped this fix: https://github.com/0no-co/GraphQLSP/pull/335

[gnakic]

@kitten does tada 1.8.0 use the latest version of the lsp plugin with that fix? Asking because I don't use the lsp plugin directly anymore but gql.tada/ts-plugin instead, as per new devlog instructions

[JoviDeCroock]

It's a dependency so it would be installed under the hood, you could try bumping it yourself with a resolution or something like npm install @0no-co/graphqlsp@latest

[gnakic]

Got it. I've put @0no-co/graphqlsp at version 1.12.9 into resolutions, but still get the same error.

[kitten]

Without a code snippet of the graphql.persisted call that's causing this, it's unlikely we can issue a targeted fix, but I can at least push a stopgap solution https://github.com/0no-co/GraphQLSP/pull/337

[kitten]

@gnakic: You should be able to try this by upgrading to @0no-co/graphqlsp@1.12.10. Just to note this, basically, we may not always bump graphqlsp inside gql.tada going forward. But it's a transitive dependency for you, so instead of a resolution, a simple update command should most of the time do the trick. (e.g. pnpm update @0no-co/graphqlsp et al) I'll have to look into our CLI doing some of these checks for people.

[gnakic]

@kitten can confirm the error is gone as well as things still working. Thank you for such a quick fix! Let me know if you're still considering a targeted fix, as I can try and share more meaningful output as soon as I figure out how.

[kitten]

I think the targted fix will only be necessary if you see anything wrong with the graphql.persisted detection or logic (e.g. in check commands as well, etc). If not, then this is likely an "intermediary" error that occurs when you write a semantically valid graphql.persisted call but it isn't quite in the complete shape we expect it to be.