ESLint parser, plugin and set rules for GraphQL (for schema and operations). Easily customizable with custom rules. Integrates with IDEs and modern GraphQL tools.
[x] 1. The issue provides a reproduction available on GitHub, Stackblitz or CodeSandbox
[x] 2. A failing test has been provided
[x] 3. A local solution has been provided
[x] 4. A pull request is pending review
Describe the bug
require-selections handles only InlineFragment spreads with GraphQLUnionTypes, despite named FragmentSpreads being valid GraphQL that should receive the same treatment.
The failing test in the linked PR provides the best example for the bug (see commit that adds that test), but a simplified schema is reproduced below:
type User {
id: ID
name: String
posts: [Post]
}
type Post {
id: ID
title: String
author: [User!]!
}
type Query {
user: User
userOrPost: UserOrPost
}
union UserOrPost = User | Post
fragment UnionFragment on UserOrPost {
...UserFields
}
fragment UserFields on User {
name
}
query {
userOrPost {
# no error is reported here, even though `...UnionFragment` does not select `id`
...UnionFragment
}
}
Expected behavior
An error should be reported for FragmentSpread just like it is for InlineFragments within GraphQLUnionTypes.
Issue workflow progress
Progress of the issue based on the Contributor Workflow
Describe the bug
require-selections
handles onlyInlineFragment
spreads withGraphQLUnionType
s, despite namedFragmentSpread
s being valid GraphQL that should receive the same treatment.https://github.com/dimaMachina/graphql-eslint/blob/58467e65f0283f5ad7a7ca8a3f0301b7669b4416/packages/plugin/src/rules/require-selections.ts#L172-L182
To Reproduce
Steps to reproduce the behavior:
The failing test in the linked PR provides the best example for the bug (see commit that adds that test), but a simplified schema is reproduced below:
Expected behavior
An error should be reported for
FragmentSpread
just like it is forInlineFragment
s withinGraphQLUnionType
s.Environment:
@graphql-eslint/eslint-plugin
: 4.0.0