feat: new operations-document plugin to generate a GraphQL Document with operations from schema

[ardatan]

No description provided.

[changeset-bot]

🦋 Changeset detected

Latest commit: 320eecb

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@graphql-codegen/operations-document	Major

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/theguild/graphql-code-generator/HRqNze9Akk4B67RwksY3njzYwwz9
✅ Preview: Failed

[Deployment for 320eecb failed]

[theguild-bot]

The latest changes of this PR are available as alpha in npm (based on the declared changesets):

@graphql-codegen/operations-document@1.0.0-alpha-17cc8e1de.0

[charlypoly]

@ardatan

what would be the use-case of this plugin?

I feel it's kind of breaking the design goal of GraphQL by adding all available fields to all operations.
Operations should be built depending on the use-case, otherwise, we're back to good old REST "fetch everything" scenario.

Any thoughts?

[taffit]

Not being @ardatan , but having exactly this requirement.
For some use cases you need to query all the fields, e. g. when displaying an object relying on the complete data of a type. Having the query/mutation generated saves a lot of work, as you can import it if needed.
If you only need some attributes (which is one of the advantages of GraphQL compared to REST), you can and will define this yourself. For when you need most of the attributes of a type, copying/pasting and then deleting (or importing and adjusting) is a lot easier and safer and quicker than having to write all the query/mutation yourself.

[n1ru4l]

I agree with @charlypoly, we should not support this.

Aside from this, I see many weird issues e.g. How would the plugin choose the value of a mandatory field argument?

@taffit your overhead could be reduced by using fragments.

[homoky]

It is perfectly fine in my opinion. We have app, where we don't care any data from mutation (we request id only all the time) so this would be great.

[taffit]

@taffit your overhead could be reduced by using fragments.

... that you have to write yourself. And maintain and adjust, if something changes. This is what I'm doing currently.
An automatic generation including any changes to the schema would be more helpful in my case. But I can live with either solution.

[davidstellini]

any chance we can get this to generate a file per query / mutation?

[ardatan]

Feel free to create a PR based on this branch, I'd love to merge them into this one.

[Urigo]

should we maybe just recommend people to use https://github.com/timqian/gql-generator ?
maybe add a recipe to the docs

[MDrooker]

@Urigo The only issue with recommending people to use https://github.com/timqian/gql-generator

Is this "feature" that creates invalid output schema-
timqian/gql-generator#51

That one plagued me for a few hours while I tried to figure out why the documents were not correct

[NexZhu]

Hope this get merged. This is definitely useful for testing at least.

[jigz]

this would be nice to have in addition to our custom queries/mutations, wouldn't want to be required to write each one for every use-case

[ariel-upstream]

Is it going to be merged?