Add validation for @deprecated on required arguments #917
Conversation
The `@deprecated` directive must not appear on required (non-null without a default) arguments or input object field definitions. Deprecated arguments and fields are excluded by default in introspection, and deprecating required arguments or input fields could create confusion for clients.
|
|
In a previous working group meeting, it was discussed that deprecating required inputs could be problematic. There was debate about whether this should be worded in the spec as SHOULD or MUST. In this PR I've added it to the spec as MUST. The reasons are two-fold:
|
|
@fotoetienne can you double check your CLA status? - merging anyway since this is PR on PR |
It's fixed now. Thanks! |
|
I'm not sure I understand this validation. I mean, I understand the basic idea that But isn't the section this is added to a section describing how to validate a particular operation against a schema, and the condition we're concerned about here is about whether a schema is valid itself? It seems like implementing this change would mean not checking for this condition when assembling a schema but instead checking for it as part of every incoming operation that uses the field in question, which seems like an odd place to do this check. |
|
Specifically, it seems like this check should go in http://spec.graphql.org/draft/#sec-Objects.Type-Validation (etc) rather than the validation section. |
The `@deprecated` directive must not appear on required (non-null without a default) arguments or input object field definitions. Deprecated arguments and fields are excluded by default in introspection, and deprecating required arguments or input fields could create confusion for clients.
The
@deprecateddirective must not appear on required (non-null without a default)arguments or input object field definitions. Deprecated arguments and fields are
excluded by default in introspection, and deprecating required arguments or
input fields could create confusion for clients.