Support @semanticNonNull

[Quramy]

Is your feature request related to a problem? Please describe.

Relay v18.0.0 introduces a new feature "Semantic Non Null", https://relay.dev/docs/guides/semantic-nullability/

The proposal works by allowing the schema to specify a new type of nullability of "null only on error". If a client sees this type, and the client has some strategy for handling field errors out-of-band, it may treat the field that is exposed to user code as non-nullable.

The full spec change will likely require adding additional syntax to GraphQL's schema definition language, but in the meantime, various GraphQL servers and clients have collaborated on a temporary directive @semanticNonNull that can be used to experiment with this idea.

The @semanticNonNull schema directive means "this field is not null unless error" .
So, field resolver annotated this directive must not return null and I want types generated by typescript-resolver to check this constraint.

For example:

type User {
  name: String @semanticNonNull
}

import type { UserResolvers } from "./_gql_gen_generated_/"

export const User = {
  name:  () => {
    // @ts-expect-error
    return null;
  }
} satisfies UserResolvers

Describe the solution you'd like

I want a new typescript-resolver plugin option to enable @semanticNonNull .

 import type { CodegenConfig } from '@graphql-codegen/cli';
 
 const config: CodegenConfig = {
   // ...
   generates: {
     'path/to/file.ts': {
       plugins: ['typescript', 'typescript-resolvers'],
       config: {
         allowSemanticNonNullType: true // default false
       },
     },
   },
 };
 export default config;

If allowSemanticNonNullType set true, codegen generates resolver types like the above UserResolvers .

Describe alternatives you've considered

No response

Any additional important details?

No response

[erikwrede]

+1 on this.
Generally, I see two areas of support on this: Server and client.

The server part is already well-described by @Quramy. For the client part, I have the following comments:
Ideally, the typed-document-ast would also support @catch directives / @throwOnFieldError fragments to infer the correct nullability condition.

See here for a quick overview on the topic:

• How Apollo Kotlin implements it: https://www.apollographql.com/docs/kotlin/advanced/nullability#semanticnonnull
• Great overview of the concept & @throwOnFieldError https://graphql.org/conf/2024/schedule/8daaf10ac70360a7fade149a54538bf9/
• Nullability Discussion: Semantic Nullability Schema graphql/nullability-wg#58