feat(@nestjs/graphql): Allow InputType Deprecation (code first)

[riley-pikus]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/nestjs/nest/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Other... Please describe:

What is the current behavior?

As called out in these 2 previous issues below, InputType Fields currently do not pass their deprecationReason to the generated schema.

• @InputType field can not be deprecated #2354
• Cannot deprecate GraphQL field in auto generated schema (code first) nest#13060

Issue Number: N/A

What is the new behavior?

Properly passes the deprecationReason defined on any InputType Fields along to the generated schema. This was officially supported June 3, 2022 as seen with this PR - graphql/graphql-spec#805

Does this PR introduce a breaking change?

• Yes
• No

Other information

Running the test suite locally for me required a downgrade to jest 29.x dependencies from jest 30.x. Just a callout

[piercy]

@kamilmysliwiec @riley-pikus Just to highlight while I understand this issue probably wasn't seen as a breaking change. its had a knock on effect where anything downstream of the schema, is now acting on the new deprecated messages that were not there before.

To give an example, graphql mesh removes deprecated fields from the schema automatically. When we updated nestjs/graphql it updated the generated schema and as such, graphql mesh removed the deprecated fields and then things broke because fields disappeared.

I realise this is nuanced and may or may not constitute as a breaking change, but i wanted to make you both aware in case it comes up more.

[riley-pikus]

@piercy This change simply adds the @deprecated directive to your schema. That is not a breaking change, at least from the POV of the NestJS ecosystem (I'm not affiliated to NestJS, simply wanted this feature in place so made a PR). How other packages you've installed will interact with this change is outside the scope of this change. For example I don't use that package, so this change has 0 negative effect, as expected

[piercy]

@piercy This change simply adds the @deprecated directive to your schema. That is not a breaking change, at least from the POV of the NestJS ecosystem (I'm not affiliated to NestJS, simply wanted this feature in place so made a PR). How other packages you've installed will interact with this change is outside the scope of this change. For example I don't use that package, so this change has 0 negative effect, as expected

Potentially, I dont disagree with that logic.. However, a changing schema can have significant impact. So it may have been wise to see this as a breaking change.

FWIW, i don't expect im the only one who is going to be having issues with this change. I would expect many more people to upgrade and realise they now have a problem to track down.