Js-graphql-intellij-plugin: Monorepo/multi-project support

Created on 26 Sep 2016  路  5Comments  路  Source: jimkyndemeyer/js-graphql-intellij-plugin

Thank you for adding graphene support @jimkyndemeyer. There would be one more step needed so we could use the plugin. And again, not sure if this repo is the right one to raise the issue, but it is the entry point.

Anyway, we are having a mono-repo structure (following babel's naming scheme: https://github.com/babel/babel/blob/master/doc/design/monorepo.md), i.e. we are having multiple projects in the same repo that all are independent and have their own graphql endpoints. It would be great if within an IntelliJ project we can have mutliple graphql.config.json files. So we could have e.g. project1/frontend/graphql.config.json, project2/frontend/graphql.config.json, etc. and all js files their respective frontend folder would pick up the right config (which in our case would point to a file-path).

I know the other way we could do that is by just having one config in the root directory and then setting up an introspection endpoint for each server, but that would be quite a bit more complicated given our infrastructure and security measures, so unfortunately probably not a realistic option.

Not sure of course how difficult this is, but I would really love us being able to use these plugins.

enhancement help wanted

All 5 comments

The short answer is that this is quite complicated. See my reply in #27

This extra level of config affects all features. Error highlighting, completion, find usages, file watches etc. and the coordination between the plugin and the language service.

At some point I might have some time to look into that myself. Is https://github.com/graphcool/graphql-config then the starting point or would it be https://github.com/jimkyndemeyer/js-graphql-language-service? (My guess would be that this should just touch the language service and this plugin, but I could be wrong of course)

I referenced graphql-config because they're working on standardising configs, and multi-project support would be another facet that they would need to document -- if this plugin was to integrate with the spec. So no code changes are needed there initially for this issue.

Several tasks come to mind:

Configuration

  • Decide on a design for how to configure the location of multiple graphql.config.json files. Scanning the file system could be expensive. Maybe have a root graphql.config.json which can include others?

Langugage Service:

  • setProjectDir has to get the info about the config locations some how, or read the "included" configs
  • File watches on multiple configs
  • Other commands: Need the file path of the buffer being completed/error annotated etc. in order tu use the correct schema. Potentially a performance hit.

Plugin:

  • JSGraphQLConfigurationProvider: Potentially massive changes. Also relevant is the editor notifications that tell the dev to configure graphql for the first time
  • Find usages should be scoped to project
  • "GraphQL Schema" in the project tree view should also reflect multiple configs. Maybe move to the relevant module?
  • Query from .graphql files: Available endpoint URLs

Probably forgot something.

/Jim.

Another idea just came to mind.

I assume that you don't need to work with GraphQL in multiple modules at the same time.

In that case, this issue becomes: "How to easily switch the "file" property in graphql.config.json and save it.

Then we need the following with just a single graphql.config.json:

  • A list of schema.json files, e.g. "files": ["module1/schema.json", "module2/schema.json"]
  • An editor tab listener which picks the relevant schema file based on the current file path and saves graphql.config.json
  • The language service picks up on this using the file watches that are already implemented

If this is a viable approach, I'd drastically reduce the scope of this issue. Only downside is that only a single schema.json is active at a time.

Please see https://github.com/graphcool/graphql-config/issues/16 for the continuation of this.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

MaxmaxmaximusAWS picture MaxmaxmaximusAWS  路  4Comments

vjpr picture vjpr  路  4Comments

BerndWessels picture BerndWessels  路  5Comments

Mischi picture Mischi  路  6Comments

MichaelDeBoey picture MichaelDeBoey  路  4Comments