Support for schema IDL language

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
• Add another step to extract/validate using buildASTSchema/schema validator
• Autocompletion
• Add support for IDL language
• GraphQL language server
• MessageProcessor should be able to grab the edited content, run the above schema validator, and extend the schema
• MessageProcessor should also be able to remove type definitions from the schema on the fly
• MessageProcessor, when the file is saved, should be able to rebuild the schema

cc @RomanGotsiy

[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

[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 😃