fix(documents): do not order mutations

[martyganz]

🚨 IMPORTANT: Please do not create a Pull Request without creating an issue first.

Any change needs to be discussed before proceeding. Failure to do so may result in the rejection of
the pull request.

Description

printExecutableGraphQLDocument sorts mutations by name whereas from the GraphQL spec the order of mutation matters, they do not run in parallel like queries, but in series. See: graphql.org/learn/queries/#multiple-fields-in-mutations.

This PR makes sure that mutations are not sorted and thus if you have a mutation where order matters they will run as
you expect them to.

Related #6195

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)

I was in doubt if it is a breaking change, but I think that anyone using the package currently without it breaking their workflow should be fine with this bugfix.

Screenshots/Sandbox (if appropriate/relevant):

N/A

How Has This Been Tested?

• Added a unit tests which describes the behavior I'd like to see

Linked locally to our project and tested if the fix worked.

Test Environment:

OS: MacOS
"@graphql-tools/documents@^1.0.0"::
NodeJS: LTS Iron (v20) - Now using node v20.12.2 (npm v10.5.0)

Checklist:

• I have followed the
  CONTRIBUTING doc and the
  style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests and linter rules pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

Further comments

Linked issue in graphql-code-generator: dotansimha/graphql-code-generator#9925
PR I made to graphql-code-generator to provide an alternative: dotansimha/graphql-code-generator#9926 - here I was asked to create a PR here ;)

Open to any comments, remarks as I'm very well aware I did not discuss the solution before proceeding to create a PR. Let me know :)

[changeset-bot]

🦋 Changeset detected

Latest commit: 7031026

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

This PR includes changesets to release 1 package

Name	Type
@graphql-tools/documents	Patch

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

[n1ru4l]

@martyganz can you please add a changeset?

[martyganz]

@n1ru4l done!

[n1ru4l]

@martyganz I think it is still safe to sort the selection set on a mutation fields selection set, so we should still do that and only retain the order of the fields on the root mutation type.

[n1ru4l]

Can you please apply the feedback from #6196 (comment) ?

[EmrysMyrddin]

@n1ru4l I'm not sure it's safe to sort sub fields in mutations. Not sure we can make the assumption that mutations actually happens only at root level. Some APIs are using namespaces to organize mutations in logical groups.

[n1ru4l]

@EmrysMyrddin GraphQL implementations should only run mutation root field resolvers in sequence. All other fields are run in parallel. See https://spec.graphql.org/October2021/#sec-Mutation

[ardatan]

I have the same concern with @n1ru4l . Sorting should be applied in the nested selection sets. By the way, I know it's an edge case but we still need to consider root fragment spreads for Mutation;

fragment SomeMutationFragment on Mutation { # Should not be sorted as well
  a
  b
}
mutation {
  fooMutation {
     ...SomeMutationFragment
  }
}

We don't have to cover it now though. Just saying haha :D

[martyganz]

@n1ru4l @ardatan Can you guys give me some pointers on how I would go about only sorting the non-root selection sets/fields?

Skipping the whole node was easy with the visit function (and docs), but I cannot get skipping only a part working yet. Would be appreciated.

Very new to all of this API.