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

Feature request: Support the DGS Framework #442

Closed paulbakker closed 1 year ago

paulbakker commented 3 years ago

Netflix open sourced their DGS Framework earlier this year (I'm one of the maintainers). Because the js-graphql-intellij-plugin is pretty much the de-facto standard GraphQL for Intellij, it would be really great if we can support the DGS Framework in the plugin.

Features I have in mind:

If you're open to the idea of this sort of integration, we would be happy to contribute as well.

vepanimas commented 3 years ago

Oh, I missed this ticket, just at this time I was on a long vacation 😞. Looks like you've already addressed the first item in the list. We also could fix the second one, it's a matter of implementation several reference contributors (https://plugins.jetbrains.com/docs/intellij/reference-contributor.html#define-a-reference-contributor). Also, we now have a page that shows all the existing open-source implementations of the platform extension points. This link shows all known referenceContributor implementations https://plugins.jetbrains.com/intellij-platform-explorer?extensions=com.intellij.psi.referenceContributor.

I'm not very familiar with the Java plugin codebase, but there may already be some extensions that simplify the creation of annotation references, it looks like a frequently encountered task.

paulbakker commented 3 years ago

I'll have a look at the mechanism you linked to, that looks good.

What are your general thoughts about features that are DGS specific and don't need to be in this plugin, because it's not about schemas? A simple example: An editor hint to add @DgsComponent to a Java class when other DGS annotations are used within the class. We're debating if we should add such features in a standalone plugin - or try add it to this plugin.

There are obvious pros and cons to both approaches, so I'm very interested in hearing your thoughts about it.

vepanimas commented 3 years ago

That's an interesting question. At first, I thought about suggesting adding it to this repo, but it could possibly impose some constraints on you. For example, you want to add a custom index for some reason, in that case all the clients of this plugin will use it even if they don't need it at all. Indexes shouldn't depend on the project, so you can't simply check a project setting and skip it. Also in the case of a separate plugin, you won't depend on our release cycle, which is quite unpredictable to be honest 😄.

But you obviously still will need to make the changes in the existing codebase to provide additional extension points in different places. I'm also interested in that to be able to support some graphql frameworks in the near future and don't hardcode them into the core. For example, we now have a custom extension to the GraphQL language (called GraphQL Endpoints Language) in the same repo, and I'm going to separate it completely using the same approach by adding the new extension points. Its extensions are already moved to a separate plugin.xml. Also we have some extension points which are implemented in the framework specific code in the com.intellij.lang.jsgraphql.frameworks package: https://github.com/jimkyndemeyer/js-graphql-intellij-plugin/blob/master/resources/META-INF/plugin.xml#L38-L43

So, I think it would be better to implement most of the framework-specific features in a separate plugin while adding new extension points into that plugin.