As the GraphQL spec evolves, breaking changes are introduced. This includes:
To work properly across spec versions, the plugin and associated language service need to ship with a number of supported spec versions, and allow the developer to pick the one that their endpoint supports.
@asiandrummer, @leebyron: I'm mentioning you guys here to get your thoughts on any established solutions for this.
I'm currently considering bundling a version of graphql-js for each published version of the GraphQL spec. Based on a configuration, the language service will then require the appropriate version for compatibility with the endpoint in use.
@jimkyndemeyer Have you condered doing it like the tslint plugin? They have a config option to select the location of the tslint js files which they load
any news on that @jimkyndemeyer ?
@waterfoul configuration is only a small part of this issue. Breaking changes can affect core functionalities such as the lexer, parser, completion, validation, introspection etc.
I'm currently experimenting with an approach that is similar to how the JavaScript tooling in IntelliJ works, namely by supporting multiple dialects (they have ES5, ES2015 etc.). This would also remove the need for a Node.js process handler and the reliance on the reference graphql-js implementation.
I'll update as things progress, but note that the time spent on this is carved out of my spare time.
Thanks for the update @jimkyndemeyer
Closing this in favor of #164.
v2 of the plugin will take the samme approach of the JavaScript tooling in IntelliJ, with the parser and lexer supporting the latest specs, and validation etc. built on top of that.
See the alpha release for current status: https://github.com/jimkyndemeyer/js-graphql-intellij-plugin/releases/tag/2.0.0-alpha-2
Most helpful comment
@asiandrummer, @leebyron: I'm mentioning you guys here to get your thoughts on any established solutions for this.
I'm currently considering bundling a version of graphql-js for each published version of the GraphQL spec. Based on a configuration, the language service will then require the appropriate version for compatibility with the endpoint in use.