New GraphQL LSP Design

[acao]

This is a long time in the making. The graphql-language-server was architected before adopting graphql-config and LSP protocol and it shows! The current design makes the code extremely difficult to understand, and almost instantly leads to smells and features that work for single files but not the entire project or workspace.

This is an extremely rough partial draft of a design proposal that will be fleshed out and accompanied with a blog post and/or slide deck soon. But I wanted to get the basic idea out there so that in-flight contributors could understand what changes will happen.

Before any of this happens or new features are added, we will be adding many more unit tests and end to end tests.

This is partially inspired by other LSP implementations, and by contributors like @Foo-x who had some incredible vision, such as #2594 and in #2609

Key Changes

• If we are able to add some features to graphql-config and possibly some breaking changes, we may be able to simplify this and reduce encapsulation.
• If we aren't able to get GraphQLProject to provide us everything that we need to replace our own implementations, then we should still use @graphql-tools/* packages to normalize pointers and load files

Preliminary Work

beforehand, we must add much more unit and end to end test coverage!

• vscode-graphql should be set up to for end to end tests attempt to get vscode working in an e2e runner #3288 for completion, diagnostics, etc on init with several file configurations
• graphql-language-service-server should have near complete unit test coverage before undergoing major changes
• graphql-language-service should have naer complete unit test coverage before undergoing major changes

[JoviDeCroock]

Hey,

I have been working for a while on GraphQLSP which leverages this package internally. Feel free to delete this if it's not the appropriate place to post this comment.

The language-service toolkit is great, during development we faced a few issues that made us fork a few functions.

• We needed to remove fragment-definitions when they were already used in the document here
• We have faced some issues when auto-completing for arguments/variables here
• I know this might be a long-shot but having information about directives/... on the client-side would be great

If you are looking for folks to help out here, I am more than open to talking more about these subjects. I have wanted to see some relay-like DevTools for general GraphQL development.