Add semantic non null support

[gitBlameMyself]

Summary

This adds support for the @semanticNonNull directive, which is part of the semantic nullability proposal being explored by the GraphQL Working Group.

The directive indicates that a field is semantically non-null - it will only be null in error scenarios. When applied to a field, @semanticNonNull causes gql.tada to infer a non-nullable TypeScript type, similar to @required.

Example

query {
  todos {
    complete @semanticNonNull
    author @semanticNonNull {
      id
      name
    }
  }
}

Before (without @semanticNonNull):

{
  todos: Array<{
    complete: boolean | null;
    author: {
      id: string;
      name: string;
    } | null;
  } | null> | null;
}

After (with @semanticNonNull):

{
  todos: Array<{
    complete: boolean; // no longer nullable
    author: { // no longer nullable
      id: string;
      name: string;
    };
  } | null> | null;
}

Set of changes

Modified getTypeDirective in src/selection.ts to recognize @semanticNonNull alongside @required and @_required
Added test case in src/tests/selection.test-d.ts

This is a non-breaking, additive change.

[changeset-bot]

🦋 Changeset detected

Latest commit: 91bda67

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[JoviDeCroock]

Thank you for the PR, having been a bit involved with the semanticNullability proposals and implementing them, I don't think we should merge or pursue this until there is clarity. Notice that the proposal is set at RFC0 and there are a lot of competing proposals.

[kitten]

Closing, sorry. There's no clear or single spec proposal here, and no clarity on a path forward or reference implementation that's up to date.

For context, for example when we implemented @defer/@stream`'s incremental delivery payload format, the format kept changing, being unspecified, and different implementors had different formats in practice, which meant we could only test and match what we saw, check reference PRs, etc. This was extremely painful. (And is still an ongoing problem)

The semantic nullability proposals have gone through this but worse. @semanticNonNull isn't even mentioned, as a directive, in the PR you linked. I'm also aware that there's competing approaches that sometimes only influence the queries, and sometimes only the schema. As far as I'm aware @semanticNonNull was only meant for schemas — and not queries (?)

It's confusing. There's no specification to follow. And there's no unified reference implementation or specification. So, closing, since I don't think it even makes sense to keep a PR going that's basically "out of spec" (since there isn't a spec for a proposal, i.e. the proposal has been modified and knocked back so many times, it's basically even pre-Stage-0)

[gitBlameMyself]

Okay. I thought that it being supported for example in projects such as

• Relay
• HotChocolate

It would be nice to have this addition. Since it is opt-in I don't really see the drawback?