Multiple generated files

[TmLev]

Is your feature request related to a problem? Please describe.
I'd like to generate independent files for different schemas/operations so that all the generated code won't end up in a single file.

Describe the solution you'd like
Let the user specify multiple paths in the generated section.

Describe alternatives you've considered
Multiple genqlient.yaml configs?..

Additional context
Not needed.

[benjaminjkraft]

Thanks for the suggestion! Can you give a little more information about the lines along which we'd split the generated file, and what benefits you're looking for from that split? I can think of a few different things you might be looking for, which could look very different:

• One file per schema, if the schemas are completely disjoint (i.e. you're talking to several services). In this case I think right now multiple genqlient configs are your best bet but since this also came up in Remap remote schemas with duplicate type names #177 it might be worth exploring a bit more how to make that smoother.
• One file per operation. This is actually more complex than it sounds, in that some types are shared between operations (namely input, enum, and scalar types as well as those corresponding to shared fragments). Of course those could go in a separate file if needed, but the point is the files would need to stay in one package, at which point I'd be interested in hearing more about what benefit you see.
• Is the issue really that you have a bunch of operations (and/or schemas) in several different directories, and you want to generate Go files in the corresponding packages? The best way to handle that might be to have genqlient treat this internally as several separate configs (one per package) but not make you write them all out separately, although that could get confusing in its own way.
• Do you want to be able to customize all the filenames, like generated_<schema-or-operation-name>.go? I think that could get a bit hairy, although it's surely possible. Or do you just want to say "put them all in this directory, name them what you want", which is a bit simpler?

Thanks in advance for any thoughts you (or other folks interested in this) can fill in; I hope with a better understanding of your use cases we can find a way to help!

[prakashsanker]

I have a need for this (if you don't mind me jumping in). The reason is I want to have my types exist in a separate package and use those types everywhere.

My use case - I am leveraging Hasura, pulling the schema and then running the code gen. I have one "backend" and multiple "frontends" (cli/sdk/ui) and I want the "frontends" and "backends" to rely on the same types in order to force them to agree when the frontend calls the backend.

[benjaminjkraft]

Thanks for the additional information! What do you mean by "have my types in a separate package" -- separate from what? Just from the query-helpers? If you have a query MyQuery { field1 { field2 } } the idea is func MyQuery goes in one package and type MyQueryField1 goes in the other? Where does func MyQueryResponse go?

Or, would it be possible to just have all the queries be shared, or have genqlient generate queries into several places? It seems to me that with genqlient you wouldn't need to share the types to ensure they're the same; as long as they're generated from the same schema they'll all match for the most part, but maybe I don't fully understand your use case.

[TmLev]

@benjaminjkraft, hi! Sorry for the delay.

• One file per schema, if the schemas are completely disjoint (i.e. you're talking to several services). In this case I think right now multiple genqlient configs are your best bet but since this also came up in Remap remote schemas with duplicate type names #177 it might be worth exploring a bit more how to make that smoother.

Yes, I have multiple disjoint schemas for which I'd like to split generated code into multiple packages.
Right now I'm doing this via multiple genqlient configs.

I think that genqlient config can describe multiple schemas by just repeating existing .yaml structure multiple times.
And CLI tool will probably need a new argument to specify directory with config.