search

JetBrains / js-graphql-intellij-plugin

GraphQL language support for WebStorm, IntelliJ IDEA and other IDEs based on the IntelliJ Platform.
https://jimkyndemeyer.github.io/js-graphql-intellij-plugin/
MIT License
880 stars 97 forks source link

Support for GraphQL Config v3 #296

Closed RIP21 closed 1 year ago

RIP21 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

Hi,

Thanks for reaching out :)

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

Best regards, Jim.

jimkyndemeyer commented 5 years ago

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.

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 commented 5 years ago

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

jimkyndemeyer commented 5 years ago

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 commented 4 years ago

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 commented 4 years ago

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

0xdevalias commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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:

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

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:

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:

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.

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:

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 commented 3 years ago

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

jimkyndemeyer commented 3 years ago

@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 commented 3 years ago

@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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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