Js-graphql-intellij-plugin: Add or prepare for support of new 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 :)