Schema files from the classpath

[markwimpory]

Runtime and code gen time allow schema files to be loaded from the classpath including jars. Can the plugin do this as well so that we can still get completion etc.

[FyiurAmron]

@markwimpory TBH, it's possible to work around this (I'm using this ATM in my repos), but it's tricky:

• create a Gradle task that will extract the schemas from the artifacts you need (I use custom Configuration for that), into some reasonable location (build dir subdir e.g.)

• use graphql.config.yaml or equivalent to provide path to that location with additional schema(s) to the plugin

  First-class support would be obviously a lot better here, since adding custom build jobs just to satisfy plugin requirements is somewhat unappealing. (in my case, it's to help front-end devs as well, so I'm kinda OK with it, but I wouldn't do that otherwise probably)

[vepanimas]

@markwimpory @FyiurAmron hi! I'm working on that now. Could you provide examples of how these libraries are structured in your project? If they are available in Maven, it would be even better if you could provide their IDs for testing purposes.

[FyiurAmron]

@vepanimas the structure needed to replicate this is the most bare-bones one ever:

1. create a project (Gradle/Maven, whatever works for you) with an example graphqls in its resources. Nothing more, just build a JAR out of it, e.g. (example courtesy of https://graphql.org/learn/schema/#interfaces ):

   interface Character {
   id: ID!
   }

2. create a project which consumes the above JAR, e.g. via Gradle implementation(files()) or any other mechanism, and has a second, extending graphqls, e.g.

   type Human implements Character {
   id: ID!
   name: String!
   }

   ; observe that it breaks the plugin's parsing due to not scanning the classpath for the dependency graphqls providing the base definitions. Basically, those two projects with those two files by themselves would be enough to replicate the core of the issue IMVHO.

BTW, AFAIK, there should be a way for IntelliJ plugins to scan the extracted classpath for stuff, since (again, AFAIK, I'm no IntelliJ plugin expert) IDE does that to inspect the lib code etc. If that's impossible for any reason, a hand-provided classpath path param passed to plugin or something similar would be an acceptable workaround, I guess?

[vepanimas]

Fixed, should be available in the next 2024.1 EAP. Please feel free to reach out if you have any questions or feedback.

[markwimpory]

Sounds good - sorry missed above comments. Will give it a go.