Option to inline enums and input + variable types in operations (+urql?)

[AndrewIngram]

Is your feature request related to a problem? Please describe.

We have a pretty huge schema, and TypeScript LSP performance is a major pain point for us. I'm looking into using near-operation-file-preset to split up the generated types in order to speed things up, but I've hit a wall because as soon as a generated colocated file imports anything from the giant schema types file, we lose the benefits of splitting things up.

Describe the solution you'd like

When I was using Relay in previous projects, any schema types were also included in the co-located files, i.e there was never a single massive file that contained types representing the entire schema (operations-only or otherwise). I'm happy to take the hit on duplicate enum and input+variable definitions if it means I can avoid importing these enormous modules.

Describe alternatives you've considered

I've looked at whether it's possible to achieve this with an additional plugin, or wrapping an existing one, but no luck so far.

Any additional important details?

No response

[eddeee888]

Hi @AndrewIngram ,

For context, we are recommending Client Preset over near-operation-file-preset and is focusing our effort to make it better.

We are planning to remove the schema types that are never used to reduce the impact of large schemas. For now, you could try to use onlyEnums: true and onlyOperationTypes: true in your config to see if it helps (Note: it may or may not work, depending on your codegen config. If you see issues, please post here and I'll try to help)

However, if you have a huge number of operations, Client Preset still put them in one file - so it could still be an issue for you. Could you give me an estimate of how many operations in your repo?

[AndrewIngram]

@eddeee888 does the client preset do per-operation files like near-operation-file-preset does? Our primary goal here is splitting up enormous codegen files into smaller per-operation ones, as our operations file is currently ~100k lines and the schema file is ~30k lines (we already use onlyOperationTypes)

[AndrewIngram]

I just tried setting up the client preset, but the generated file with all the documents is substantially bigger than what we have today. We only have ~600 queries, but they each have pretty large documents. And given how different the output of the client preset is compared to what we have right now, if we're contemplating a migration effort, we might as well just switch to Relay and solve a big chunk of our problems in one go.

[eddeee888]

Hi @AndrewIngram , we have plans for Client Preset to split up the index file into smaller chunks.

Since you've checked out Client Preset, the split structure'd roughly look something like this:

gql/
  fragment-masking.ts
  gql.ts
  graphql.ts # currently has all the types and documents, but potentially goes away if everything is split into files below
  QueryA.ts
  FragmentB.ts

Could you please share your Codegen config? This will give me an idea of your current output and how different it is to Client Preset.

[eddeee888]

Hi @AndrewIngram .

We are making improvements to typescript-operations, which may solve your issues: https://github.com/dotansimha/graphql-code-generator/issues/10479

Please let me know if the proposal would solve your issue or is there something we missed 🙂