New nullable mode, disallow null for input field but allow undefined

[MatthiasKunnen]

Is your feature request related to a problem? Please describe.
I'm trying to create a Mutation that allows partially patching an entity which has required fields. Example entity:

export class Entity {
    name: string
    description?: string | null
}

My current input type for this entity is

@InputType()
export class EntityUpdateInput {

    @Field(() => String, {nullable: true})
    name?: string | null

    @Field(() => String, {nullable: true})
    description?: string | null
}

Taking the description field as an example, mutations can either

1. Pass a string -> it gets updated
2. Pass null -> the field gets cleared
3. Do no include the field in the argument -> the field is left alone

Now this all works marvelously for an optional field. However, for the name field it should not be allowed to pass null as the field is not allowed to be cleared.

Describe the solution you'd like
I would like the nullable property of the @Field decorator to feature an option optionalOnly which would result either a) an error being thrown on null or b) null properties being deleted. This would result in the following input type:

@InputType()
export class EntityUpdateInput {

    @Field(() => String, {nullable: 'optionalOnly'})
    name?: string

    @Field(() => String, {nullable: true})
    description?: string | null
}

I understand GraphQL cannot distinguish between nullability (null) and optionality (undefined) in its generated spec/documentation and that this has the potential of confusing the consumers of an API that differentiates between the two. However, I believe that this use case is a valid one.

Describe alternatives you've considered
I've looked into the possibility of using custom validators and class-validator to accomplish this but have not found a way so far as I'm not really trying to validate a value but rather, change it.

I had a look at the code of type-graphql but have not been able to estimate the time required or impact on the code base of this feature.

Additional context
Potentially related to #340 (transforming input fields).

[MichalLytek]

I understand GraphQL cannot distinguish between nullability (null) and optionality (undefined) in its generated spec/documentation and that this has the potential of confusing the consumers of an API that differentiates between the two.

Exactly. Without a proper layer for transforming input fields, all we can achieve is a false sense of type correctness. In runtime it will work the same.

[MatthiasKunnen]

This feature request does indeed require the ability to transform input fields for option b or the ability to validate (throw errors) for option a.