Deprecation of input fields

[dylanahsmith]

It is possible to deprecate fields and enum values, but not input values or arguments. I think it should be possible to deprecate optional arguments and input fields.

A natural way of evolving the schema in this case would be to make an input field optional if it is required, deprecate it, then remove it once clients stop explicitly setting the value. We can add support for that into the server to detect when the input field is still used, but we would like deprecation warnings on the client so we can easily remove usage of these deprecated input fields.

One possible workaround is to create a new field with different input, but that is a more disruptive way of evolving the schema.

Note that if __InputValue was just given isDeprecated and deprecationReason fields, then that would mean that an input object type could be deprecated, would that be undesirable? Right now an __Type (object, interface or union) also can't be deprecated, so would we want that to be consistent with an input object type?

Also, should the spec disallow an argument to be deprecated if it is non-null (i.e. required)? Otherwise, that effectively makes the field it is on deprecated.

[cjoudrey]

@leebyron any thoughts on this?

[leebyron]

Yeah I think this is probably an interesting idea, though we haven't put a lot of thought into it yet.

I'm less sure about making types themselves deprecated - rather the references to those types should be deprecated. Perhaps that means also being able to mark arguments as deprecated. If input obj fields can be transitioned from required to optional to deprecated, then arguments should be the same.

The next steps for an idea like this would be to draft an RFC, probably in the form of a PR against the spec along with a good description of how deprecation best practice should work and any potential caveats.

[brndnblck]

Perhaps that means also being able to mark arguments as deprecated. If input obj fields can be transitioned from required to optional to deprecated, then arguments should be the same.

I'd be very supportive and a huge fan of this change. 👍 We've already run into a few scenarios in our implementation where this would be valuable and I can foresee it becoming even more important in the future.

I'd be happy to collaborate with anyone who wants to begin working on this.

[sibelius]

few places that are useful

• args of connections/fields
• args of mutations

[gjtorikian]

The next steps for an idea like this would be to draft an RFC, probably in the form of a PR against the spec along with a good description of how deprecation best practice should work and any potential caveats.

Short of digging through old PRs, what is the process for proposing an RFC, @leebyron? I'm looking for something akin to Rust's RFC process, but outside of Subscriptions there don't seem to be many guidelines on writing these.

[wincent]

@gjtorikian: a rough outline of the contribution process can be found here: https://github.com/facebook/graphql/blob/master/CONTRIBUTING.md

[vergenzt]

Yeah it was actually news to me that this was not supported. (I would've sworn we've already put deprecationReaons on arguments in our codebase without realizing that it wasn't actually sending deprecation notices!)

Anyone working on a PR for this?

[legopin]

Is there any update on this? Are there new ways of accomplishing this now?

[nodkz]

@IvanGoncharov how it can be moved? Firstly should be improved spec or changed the code in graphql-js. Or firstly discussed on WG meetengs?

https://twitter.com/nodkz/status/1045668188430749697?s=19

[IvanGoncharov]

@nodkz ATM workflow should be following:

1. PR to a spec
2. discuss it on a WG

For bonus points, you can prepare graphql-js PR before WG.
Do you want to be the champion for this proposal?

Just prepare the early draft of spec changes and submit it as a PR.
I will review changes and help out if you need assistance.
Good starting points:
http://facebook.github.io/graphql/June2018/#InputValueDefinition
http://facebook.github.io/graphql/June2018/#sec-Deprecation
http://facebook.github.io/graphql/June2018/#sec-The-__InputValue-Type
http://facebook.github.io/graphql/June2018/#sec--deprecated

[leebyron]

@nodkz see: https://github.com/facebook/graphql/blob/master/CONTRIBUTING.md

[nodkz]

@leebyron brilliant! 👍

@IvanGoncharov Sorry I cannot to do it in the near future - my wife kill me 🔪😅
Lately, I've paid too little attention to her and the baby 😔

[IvanGoncharov]

@smitt04 Thanks for volunteering 👍
This RFC is moved to #525

[TomaszKot11]

Is it possible?

[AzkaNoreen6]

Is it possible?

Yes, Make use of deprecated directive on types and make a custom schema transformer that apply depreciation on schema.