Graphiql: Support for schema IDL language

[asiandrummer]

Language service features for schema IDL language would be amazing to have - there has already been some work done to begin the effort. After talking with some folks and researching on some ongoing efforts, I think I'm ready to propose a plan:

• Changes to graphql-js
• [ ] Modify the code to throw validation errors to include a source location
• [ ] Write a schema validator

// For example,
// in graphql-js/src/validation/rules/SchemaValidator.js
export function SchemaValidator(context: ValidationContext): any {
  return {
    // This will consist of all sanity/invariant checks in buildASTSchema/extendSchema
    // For example,
    TypeExtensionDefinition(node) {
      if (!context.getSchema().getType(node.definition.type.value) {
        context.reportError(new GraphQLError(
          `Cannot extend type "${extendedTypeName}" because it does not ` +
          'exist in the existing schema.',
          [ def.definition ],
        ));
      }
    },
  };
}

• Diagnostics
• [x] Add another step to extract/validate using buildASTSchema/schema validator
• Autocompletion
• [x] Add support for IDL language
• GraphQL language server
• [x] MessageProcessor should be able to grab the edited content, run the above schema validator, and extend the schema
• [x] MessageProcessor should also be able to remove type definitions from the schema on the fly
• [x] MessageProcessor, when the file is saved, should be able to rebuild the schema

cc @RomanGotsiy

[RomanHotsiy]

Hey @asiandrummer,

any progress on that so far?
I'd be happy to help out.

There is one important question worth to discuss. Should language-services has two modes for IDL and query? What is your vision on that?

[asiandrummer]

@RomanGotsiy unfortunately I've been working on other things and wasn't able to spend time on this project at all. I'd love to move this forward, but it's been really difficult to carve out times to work on this.

For your question - I agree that two different modes (if you meant the online parser and rules) will be necessary to reduce the complication of running the parser. Similar to how there are different parsers for GraphQL queries and variables (which is just a JSON syntax).

[stephen]

re: graphql-js changes, we'll also need to ignore the executable definitions check that seems included by default.

[schickling]

Let's make this happen! 🎉

[divyenduz]

@asiandrummer : I can pick up some of this stuff, let me know if you have some feature priority in your plan for this?

[Neitsch]

@divyenduz - feel free to pick this up. I think the first thing should be to throw out our custom LSP implementation and rely on the lsp package on npm (I think it's called vscode-lsp or so).

[divyenduz]

I don't get the "rely on lsp package on npm" part though? We would need a GraphQL language service right? In my understanding we have a custom LSP server and we want to use the LSP client/server from VSCode team and build the GraphQL language service on top of it? So essentially, we get rid of this package?

Is my understanding correct?

[acao]

we already use vscode-languageserver in our server implementation, not sure how extensively, and also vscode-jsonrpc of course, but there are a number of other official language service packages we could be using across service, interface etc to make things easier potentially. vscode-typescript-service is a good point of reference, json-service as well as it relies on an remote schema like ours. apollo's language services are built on top of ours and aim to be more like the former. I still have a lot to learn in this arena, mostly am just focused on the graphiql monaco POC at the moment. Overall I think there are opportunities to leverage the vscode lsp packages more extensively to keep from having to maintain a lot of redundant code. If you have access to the GraohiQL Maintainers team, the first discussion post that Lee made has some comments from @martijnwalraven about these topics

[acao]

@divyenduz so, coming back now with a much better understanding of the vscode lsp ecosystem.

This package uses vscode-languageserver actually, albeit a version that's a few major increments behind.

So @Neitsch are you sure you mean to throw out our custom LSP server implementation, if its already depending on vscode- packages?

[Neitsch]

@acao, let me double check and get back to you. It has been a while since I looked at that code.

[Neitsch]

Hey, I have to apologise. I must have been looking at an outdated version. I'm glad we already tackled using the VSCode package. Yeah, then let's move forward with this :)

[acao]

Most schema IDL features have been introduced to the LSP already.

I'm going to close this issue for now, and any additional features that are missing we can capture in seperate issues