-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cover empty field-selections #4228
Conversation
✅ Deploy Preview for compassionate-pike-271cb3 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Hi @JoviDeCroock, I'm @github-actions bot happy to help you with this PR 👋 Supported commandsPlease post this commands in separate comments and only one per comment:
|
abdb9ac
to
9a204e3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense to match the spec as written, although in theory it would be a good discussion for the WG why the ScalarLeafsRule covers empty selection sets, presumably the empty selection set implies a leaf and that's invalid, but it's a bit of a stretch. I think for now it is the right thing to match the specification with little downside.
9a204e3
to
ef94e2a
Compare
Closes #3790
This follows the spec closer to the letter as we consider empty selection-sets invalid as well. This however does not cover empty operation-definitions, which should also be considered invalid.
The parser itself considers empty-selections invalid as it requires you to specify a name before a closing curly, hence why testing happens a bit more manual here. Despite our parser not considering this valid, I think this is good to validate when folks use a separate parser or construct documents manually as this is valid in our type-system.