Breaks with preset: near-operation-file
Loving the library. Thank you!
One thing that I've noticed is that it doesn't work with the preset: near-operation-file. This is a preset that allows you to create a bunch of smaller generated files instead of one giant one, near where the original .graphql file lives. I can take a look, and compare to other codegens and see what's different.
What is the problem? Files are not generated at all, or the queries fail when you use them? It should be working with that preset too, you should not use a relative path when importing the apollo-client however.
Sorry about the lack of detail. Basically it fails silently. ie the generator doesn't error out, no files are generated.
As far as the relative path goes, we're using this within Svelte kit, and passed the client via an aliased path. ie $lib/graphql/generated.ts but I totally understand what you mean about the relative path being a problem there.
I should mention that this becomes an issue with a large API. We see our generated file getting all the way up to 500kb because it's one giant generated file rather than many split-able files.
Sorry Scott, I had no time to look into your issue. Could you share your codegen.yml?
We can argue that having all generated code into one file is actually handy, no circular dependencies, every queries generated are found into one single file, the file size however big it is, should not be an issue, just exclude it from type checking to keep your editor fast. But I get your point, it would be nice to also be able to split them, and have them close to your .gql files. It is much harder to generate them however if we want to avoid repeated code block across files.
Could you run the command in debug mode, like this:
export DEBUG=1 && npx graphql-code-generator
And send me the output?
I don't have experience using Svelte but I wonder if using the new near-operation-file-preset introduced in Codegen V2 might be a better fit instead of near-operation-file?
Would love to hear your feedback as Svelte users, we this about making that the recommended way for Codegen frontend usage in the future...
Yeah, I will definitely check this version 2 next weekend, if someone want to check this out, feel free to contribute!