fix(OverlappingFieldsCanMergeRule): require same variable definitions

[yaacovCR]

The initial v17 release included validation of fragment arguments using an earlier, rejected version of the field selection merging rules. This PR updates fragment arguments validation to the current spec proposal.

The current spec proposal intentionally requires variables in otherwise identical arguments to refer to the same variable definition. Following argument values through fragment spreads could allow more documents, but it makes the logic for determining whether arguments are the same significantly more complex. The current fragment arguments proposal takes the conservative approach of rejecting these cases.

For example, these fields appear to use the same operation variable:

query Example($size: Int!) {
  user {
    image(size: $size)
    ...Image(size: $size)
  }
}

fragment Image($size: Int!) on User {
  image(size: $size)
}

The first field uses the operation variable, while the field in Image uses the fragment variable. Treating them as equal requires resolving the spread argument before comparing the fields.

A literal may also match a fragment variable default:

query Example {
  user {
    image(size: 10)
    ...Image
  }
}

fragment Image($size: Int = 10) on User {
  image(size: $size)
}

Treating these fields as equal requires applying the omitted fragment argument default during field selection merging.

Bindings may also pass through several fragments:

query Example($size: Int!) {
  user {
    image(size: $size)
    ...Outer(size: $size)
  }
}

fragment Outer($size: Int!) on User {
  ...Image(size: $size)
}

fragment Image($size: Int!) on User {
  image(size: $size)
}

Treating these fields as equal requires following the operation variable through both fragment variable definitions.

Allowing these cases means a fragment cannot be checked on its own. The validator must carry variable bindings into each spread, apply defaults, follow bindings through nested fragments, cache the same fragment separately for different bindings, and handle cycles while doing so. Whether two arguments are the same then depends on the full path to the fragment.

Requiring the same variable definition keeps the check local. Variables are compared by their definition rather than by tracing the values passed to them. The stricter rule can also be relaxed later without invalidating documents that are already valid, but v17 incorrectly released the more lenient rule despite the currently stricter stance within the specification.

References:

• Current fragment arguments proposal: Fragment arguments - needs champion graphql-spec#1224
• Earlier (now-closed) fragment arguments proposal: Fragment arguments/variables (syntax/validation/execution) graphql-spec#1081
• Benjie's rationale for the conservative validation rule: Fragment arguments/variables (syntax/validation/execution) graphql-spec#1081 (comment)
• Benjie's follow-up PR updating the proposal: Fragment arguments editorial JoviDeCroock/graphql-spec#2
• Proposal commit requiring references to the same variable definition: graphql/graphql-spec@6659416
• Initial GraphQL.js fragment arguments implementation: feat: add experimental support for parsing fragment arguments #4015

[vercel]

@yaacovCR is attempting to deploy a commit to the The GraphQL Foundation Team on Vercel.

A member of the Team first needs to authorize it.