Support for GraphQL Config v3

[RIP21]

Hi there Jim, a legend :D Thanks a lot for your work on this plugin, you're amazing. Here is some changes coming up to GraphQL Config, I think it will be nice to be aware of that and implement that once it's finalized. I already told to author about this particular project, so hopefully they'll be able to help :) https://medium.com/the-guild/graphql-config-708dd0e5d15f

Thanks a lot :)

[kamilkisiela]

Hi :) yes, exactly, we want to hear your opinion on the new GraphQL Config and help you migrate. We think about introducing a version field within config file so tools like yours could support both, old and new syntax, if necessary.

[jimkyndemeyer]

Hi,

Thanks for reaching out :)

I'll try to carve out some time to take a look and provide feedback.

Best regards, Jim.

[jimkyndemeyer]

First of all, it's great that GraphQL config has found a new home and will be further developed.

Having read the medium article there's a lot of nice additions, but I also see a lot of added complexity. There's a number of things in the updated config that don't fit well with this plugin, given that it's written in Java for the IntelliJ Platform.

• My immediate reaction is that the new version is still heavily slanted towards the NPM ecosystem, including looking in package.json files for configuration. A lot of the users of this plugin use GraphQL for other types of languages and ecosystems -- as was intended when GraphQL was designed. I would also advice against having that many different allowed file names. As a developer I'd want to have a standardized file name to find the config in, especially when looking at other projects than my own. I think the current version which uses a single file name but allows .json and .yaml/yml extensions is flexible enough.
• The plugin doesn't ship with a JavaScript engine that will be able to execute the new support for .js and .ts schemas. A result the plugin likely can't fully support the new format, and this could be a potential cause of confusion.
• On loaders, this plugin won't be able to leverage these unless a Java implementation exists, so the advantages listed in the article only apply for the NPM ecosystem.

Overall, it feels like there's a challenge here between keeping graphql-config easy to use across programming environments and the power/flexibility/scope it provides. In the case of an IDE plugin such as this, the schema discovery needs to be fully integrated into the IDE APIs to enable performant language tooling. This can't easily be handed off to a Javascript based loader. Would it make sense to keep the config including the semantics separate from tooling such as loaders?

[RIP21]

@kamilkisiela take a look at the answer. I think it has a very valuable point of view here.

[jimkyndemeyer]

For people looking for graphql-config docs that match this plugin see https://github.com/kamilkisiela/graphql-config/tree/b3e5b75bfb7624bc1eb7a2bfb62704ab2bb6392f

I looks like https://graphql-config.com/ and https://github.com/kamilkisiela/graphql-config makes no mention that breaking changes have been made in the format.

I suggest these updated pages should link to the "old" docs to help developers who are looking for that information.

[0xdevalias]

For people looking for graphql-config docs that match this plugin see https://github.com/kamilkisiela/graphql-config/tree/b3e5b75bfb7624bc1eb7a2bfb62704ab2bb6392f

@jimkyndemeyer This would be good to surface somewhere more visible, like this project's README. I wasted a while trying to figure why it wasn't working until I eventually stumbled upon this issue.

[kamilkisiela]

@0xdevalias there's a banner on top of graphql-config.com

[0xdevalias]

@kamilkisiela That is useful I suppose.. but maybe at least pointing out in a more obvious way that this project requires the legacy config.. as right now the only thing mentioned is:

Schema discovery is configured using graphql-config files, including support for multi-schema projects

Which to me implies I can use the latest version/docs.

[rrrix]

For anyone coming here to figure out how to get JS GraphQL plugin to support multiple schema files ("projects"), it's here: https://github.com/kamilkisiela/graphql-config/blob/legacy/specification.md#use-cases

Example in that file (in case the link dies):

For multiple apps with isolated directories, there are mainly two ways to set up the configuration. Each app can either use the projects property to specify each application's configuration, or have a separate .graphqlconfig file for each project root.

{
  "projects": {
    "appA": {
      "schemaPath": "./appA/appASchema.graphql"
    },
    "appB": {
      "schemaPath": "./appB/resources/appBSchema.graphql"
    }
  }
}

Or each app can have a separate .graphqlconfig file per each application and/or directories:

./appA/.graphqlconfig
./appB/.graphqlconfig

[remidebette]

Hi,

It appears that the graphql-config v2 cannot support using the GET HTTP verb on the endpoint but some method keyword was introduced on v3.

The plugin currently cannot be used on GraphQL endpoint such as prismic.io for this reason.

Is v3 going to be adapted to this plugin or should we request features such as this independently?

[jimkyndemeyer]

@remidebette The plugin uses POST because that is expected to be supported by a GraphQL endpoint: https://graphql.org/learn/serving-over-http/#post-request

As for V3, adoption is unlikely in this plugin due to the shift towards the JavaScript ecosystem, which this plugin is not a part of (it's written in Java and the functionality is used for many different programming languages and project types). See my comment above: https://github.com/jimkyndemeyer/js-graphql-intellij-plugin/issues/296#issuecomment-551102394

[bdombro]

I hope you change your mind on supporting V3 or someone forks, because there are no alternatives and V2 support is limited for newer Javascript projects :-(. Even if just a subset of V3

[0xdevalias]

While my understanding is that at this stage it's unlikely to be officially supported, for my own interest (or for anyone who may be interested in exploring a fork that does support it) I decided to do a little googling to see what the state of JavaScript in JVM is these days.

Rhino is the original JavaScript engine for JVM that I remember hearing about, but it seems it is still maintained, with a stable release in January 2020

Between Java 8 and 11, Nashorn was the JavaScript engine shipped with the JDK, but it is deprecated since Java 11, with GraalVM as the suggested replacement.

GraalVM supports many different programming languages on top of the JVM, of which JavaScript is one of them:

• GraalVM JavaScript: ECMAScript 2019 compliant JavaScript runtime, with support for Node.js

In the JavaScript & Node.js section of the docs on the main GraalVM website it claims even more updated compatibility:

• GraalVM is ECMAScript 2020 compliant and fully compatible with a diverse range of active Node.js (npm) modules. More than 100,000 npm packages are regularly tested and are compatible with GraalVM, including modules like express, react, async, request, browserify, grunt, mocha, and underscore. The latest release of GraalVM is based on Node.js version 12.15.0.

The main docs page talks about the various methods of being able to use GrallVM features, of which the most relevant here is as a library (jar files) rather than as a runtime:

• Libraries (jar files)

  • GraalVM Compiler – a dynamic just-in-time (JIT) compiler that improves efficiency and speed of applications through unique approaches to code analysis and optimization.

  • JavaScript interpreter – an ECMAScript compliant JavaScript engine.

While you can apparently get a GrallVM-based replacement of the standard Java JDK, it's also possible to use it as a jar dependency on the standard JDK:

• https://medium.com/graalvm/graalvms-javascript-engine-on-jdk11-with-high-performance-3e79f968a819

  • GraalVM’s JavaScript engine is a Java application that works on any Java 8+ implementation. The JavaScript execution is built around an abstract syntax tree (AST) interpreter that can be executed like any other Java application. Every Java virtual machine will optimize it to some extent, but the JavaScript execution will remain interpreted, thus slow.

The GraalVM GraalJS repo is on GitHub, and they also have documentation on how to use it with a standard (non-GraalVM) JDK as part of a maven project, or just by referencing the jar files.

• https://github.com/graalvm/graaljs
  • https://github.com/graalvm/graaljs/blob/master/docs/user/RunOnJDK.md

---

There are also various methods for 'calling out' to the hosting system's node, if a non-fully-native-JVM solution is considered acceptable; eg:

• https://github.com/eclipsesource/J2V8

  • J2V8 is a set of Java bindings for V8. J2V8 focuses on performance and tight integration with V8.

Another potential method could be to run node to parse the JS config files, and then export a more Java friendly 'intermediary' config file, that this lib could then read from.

[artemtam]

Hey @jimkyndemeyer! Any progress on it? Do you maybe need some help?

[jimkyndemeyer]

@artemtam Due to other commitments I'm not actively working on new features in this project right now. But I've been in contact with to the WebStorm team who offered to contribute to ongoing maintenance and further development.

Right now they're working on v3 of the plugin itself, but there is mention of the new config format potentially being on their roadmap in https://github.com/jimkyndemeyer/js-graphql-intellij-plugin/issues/396#issuecomment-697022079

Best regards, Jim

[RIP21]

@jimkyndemeyer great news. Finally it happened (I mean that they've noticed plugin and are helping with it). Either way, thanks a lot for all the time and effort you put into this plugin it's really a lifesaver for JB IDE users :)

[ristomatti]

@vepanimas Has there been any progress? I spent too many hours last autumn trying to get things working for both VSCode and WebStorm devs on our team. Until now WebStorm support has been sufficient, but it is not the case anymore.

At this point I'd be grateful for just a workaround (even duplicating the config) if someone has already figured this out! I have a faint memory either of the plugins failed to work due to detecting a secondary, unsupported config file :thinking:. AFAIK we don't even need v3 config file features.

[RIP21]

I double that. Having basic setup without complex loaders and whatnot will be very nice to have. Whatever requires node scripts to run shall be ignored and that is it.

Or maybe it's a good idea to have ultimate and basic edition so for ultimate it works only for paid IDEs and supports all the stuff and basic one that only highlights stuff for community edition. Dunno.

Either way, I'm good with what I'm getting right now, but if it will get better so there will be no need for a JSON config that I have specifically for JetBrains users only, it will be nice.

[ristomatti]

As for the workaround, I just got the idea of excluding the second config file from the other editor but somehow I doubt this would work. Unless someone comes up with a known workaround, I'll likely be giving it a shot sooner or later.

@RIP21 In my case, I'm now the only remaining JetBrains IDE user within the team so I'll need to prepare to take one for the team and live with a git update-index --assume-unchanged hack. Going back to plain text GraphQL queries is not something I'm going to accept. :persevere:

[andrei9669]

Whatever requires node scripts to run shall be ignored and that is it.

I think that this is a really good stepping stone until we have proper support.

[acao]

Hey there! Maintainer of the official GraphQL LSP graphql-language-service-server used by vscode-graphql here. Legacy compatibility is readily available.

About two years ago we upgraded to graphql-config@3 and now use graphql-config@4, as you can see from the graphql-language-service-server changelog. Luckily in 2020 I added the ability to override graphql-config loadConfig() options via your LSP client config.

If you want vscode-graphql or any LSP implementation to support legacy 1.0 mode of graphql-config proposed spec that IntelliJ uses, just provide this setting documented in the readme.

"graphql-config.load.legacy": true,

Seeing this isn't in vscode-graphql though, will add that when I get a chance. (update: added!)

[employee451]

If you want vscode-graphql or any LSP implementation to support legacy 1.0 mode of graphql-config proposed spec that IntelliJ uses, just provide this setting documented in the readme.

"graphql-config.load.legacy": true,

@acao I'm not too familiar with VSCode – where do you add this setting? In the .graphqlconfig directly or is there settings for vscode-graphql in some file? I'm trying to get .graphqlconfig working for my team, which uses both WebStorm and VSCode.

[acao]

@employee451 you would specify this in user or project .vscode/settings.json. We can’t define this in graphql-config because the load parameters are used when loading the config file itself! In this case, the legacy flag is required to find the legacy filename, which is not sought by default in modern graphql config

We could enable this option by default, but it seems the graphql-config maintainers who created this config format are hoping to drop support for this deprecated legacy option in 5.0.0, so we need other implementations like this one which are still using the 1.0.0 format to catch up if they want to maintain interoperability with other tooling.

I have been advocating for them to not drop it for the sake of this intelliji plugin, but we will see, and the upgrade will be needed by users across vim, emacs, sublime and vscode clients as other frontend tooling requires newer versions of graphql config! Just adding this word of caution for now. I don't want intellij users to end up falling behind, as other IDEs are using the modern format of the spec

[acao]

update: I have made it so that vscode-graphql automatically uses graphql-config in "legacy" mode for the rest of graphql-config@4, so that vscode, vim, etc users can have interoperability with the spec. we had the same issue with users where vim, emacs and intellij were being used on the same repo, so this is more than just an issue with vscode, since other editor plugins that use our LSP server, and alternative graphql LSP servers to ours expect the newer format