feat(codegen): use Maybe for nullable input fields

[patrick91]

Summary

• schema-codegen now generates nullable input fields with strawberry.Maybe[T | None] instead of just T | None
• This allows generated input types to be instantiated without providing nullable fields

Fixes #4177

Before

@strawberry.input
class HealthResultInput:
    some_number: int | None  # Required - causes TypeError with {}

After

@strawberry.input
class HealthResultInput:
    some_number: strawberry.Maybe[int | None]  # Optional - works with {}

Why Maybe over UNSET?

Per the Maybe documentation, Maybe is the recommended approach because:

• Better type safety (proper generic type vs Any)
• Explicit nullability semantics (Maybe[T] vs Maybe[T | None])
• Clearer distinction between absent and null values

Test plan

• Added tests for nullable input field generation
• Verified generated code can be instantiated without nullable fields
• Verified Some(value) and Some(None) work correctly
• All existing codegen tests pass

Summary by Sourcery

Generate nullable GraphQL input fields using strawberry.Maybe to allow omitting them when instantiating generated input types.

New Features:

• Generate nullable input object fields as strawberry.Maybe[...] instead of plain optional types in schema-codegen output.

Tests:

• Add schema-codegen tests verifying Maybe usage for nullable input fields, mixed required/nullable inputs, and correct handling of Some(value) and Some(None).

[sourcery-ai]

Reviewer's Guide

Update schema code generator so nullable GraphQL input fields are emitted as strawberry.Maybe[...] rather than plain T | None, and add tests to verify generation, instantiation, and Maybe semantics for nullable input fields.

File-Level Changes

Change	Details	Files
Adjust type generation to wrap nullable input fields in strawberry.Maybe[...] while preserving existing behavior for non-null and output types.	Introduce _is_nullable helper to detect NonNullTypeNode-wrapped types Extend _get_field_type to accept a wrap_in_maybe flag, propagate through NonNullTypeNode recursion, and build a NullableExpr of T	None When wrap_in_maybe is True, wrap the nullable type expression in strawberry.Maybe[...] using a cst.Subscript around the T
Expand schema-codegen tests to assert Maybe usage for nullable input fields and to validate runtime behavior of generated inputs.	Update existing expected input type code to use strawberry.Maybe[...] for nullable list fields instead of plain list[...]	None Add test to assert nullable input fields in generated code use strawberry.Maybe[int

Assessment against linked issues

Issue	Objective	Addressed	Explanation
#4177	Make nullable fields in generated @strawberry.input classes truly optional at runtime (constructible from {} without raising missing required keyword-only argument errors).	✅
#4177	Propagate SDL default values for nullable input fields into the generated Python @strawberry.input definitions as Python defaults.	❌	The PR only changes the type annotation for nullable input fields to use strawberry.Maybe[...] and adds related tests. It does not modify how default values are derived or emitted for fields, nor does it add logic to map SDL default values into Python defaults on the generated input classes.

Possibly linked issues

• schema-codegen generates nullable @strawberry.input fields as required (missing Python default), causing __init__() missing required keyword-only argument for {} inputs #4177: PR makes nullable input fields use strawberry.Maybe so inputs can omit them, resolving the reported construction error.
• schema-codegen generates nullable @strawberry.input fields as required (missing Python default), causing __init__() missing required keyword-only argument for {} inputs #4177: The PR implements the issue’s Maybe/Option idea for nullable input fields generated by schema-codegen.

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[codspeed-hq]

CodSpeed Performance Report

Merging this PR will not alter performance

_{Comparing patrick91/verify-4177-union-alias (13065d3) with main (358a308)}

Summary

✅ 31 untouched benchmarks