[Strawberry Shake] Fix @rename directive on input type fields#9476
Open
waldemarsson wants to merge 1 commit intoChilliCream:mainfrom
Open
[Strawberry Shake] Fix @rename directive on input type fields#9476waldemarsson wants to merge 1 commit intoChilliCream:mainfrom
waldemarsson wants to merge 1 commit intoChilliCream:mainfrom
Conversation
|
GitHub Copilot seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
Two bugs in SchemaHelper.Load() prevented @rename from working on input type fields, causing silent code generation failures when a field name (e.g. `equals`) would PascalCase to a reserved C# identifier like `Equals`. FIX-01: InputObjectTypeExtensionNode was not handled in the extension document branch, so `extend input` blocks in schema.extensions.graphql were silently discarded. FIX-02: RenameDirectiveType was never registered with the SchemaBuilder, so DirectiveType.RuntimeType stayed typeof(object) and the FirstOrDefault<RenameDirective>() lookup in DocumentAnalyzer always returned null. Also filter @rename DirectiveDefinitionNode from non-extension SDL documents before AddDocument() to prevent duplicate registration conflicts when the directive is declared in both the schema SDL and registered programmatically. Tests added: - SchemaHelperTests: unit tests covering FIX-01, FIX-02, and no duplicate-directive error when @rename appears in both SDL and AddDirectiveType - InputGeneratorTests: snapshot test for input field renamed via extension (C# property name changed, JSON wire key preserved) - SchemaGeneratorTests: snapshot test for enum value with @rename
5f153ab to
a2815ea
Compare
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes Strawberry Shake’s schema-loading path so the @rename directive is honored on input type fields (especially when applied via extend input ...), preventing generated C# member-name collisions like Equals.
Changes:
- Forward
InputObjectTypeExtensionNodedefinitions from extension documents into the schema builder so extended input fields aren’t dropped. - Register
RenameDirectiveTypeinSchemaHelper.Load()and filter user-declareddirective @rename(...)from SDL documents to avoid duplicate directive-type errors while ensuring correct CLR binding. - Add unit and snapshot coverage for input-field rename via extension and enum-value rename.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| src/StrawberryShake/CodeGeneration/src/CodeGeneration/Utilities/SchemaHelper.cs | Forwards input extensions, registers RenameDirectiveType, and filters SDL @rename directive declarations to prevent duplicates. |
| src/StrawberryShake/CodeGeneration/test/CodeGeneration.Tests/Utilities/SchemaHelperTests.cs | Adds unit tests covering input-extension forwarding, typed @rename resolution, and duplicate directive declaration handling. |
| src/StrawberryShake/CodeGeneration/test/CodeGeneration.CSharp.Tests/InputGeneratorTests.cs | Adds snapshot test asserting input field rename via extension impacts generated C# property name while preserving wire key. |
| src/StrawberryShake/CodeGeneration/test/CodeGeneration.CSharp.Tests/SchemaGeneratorTests.cs | Adds snapshot test for enum value rename producing renamed C# member names while preserving original wire values. |
| src/StrawberryShake/CodeGeneration/test/CodeGeneration.CSharp.Tests/snapshots/InputGeneratorTests.Input_Field_Renamed_Via_Extension_Has_CSharp_Property_Name_With_Original_Wire_Key.snap | New snapshot baseline for the renamed input-field generation output. |
| src/StrawberryShake/CodeGeneration/test/CodeGeneration.CSharp.Tests/snapshots/SchemaGeneratorTests.Enum_Value_With_Rename_Has_Renamed_CSharp_Member_And_Original_Wire_Value.snap | New snapshot baseline for enum-value rename generation output. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
First time contributor trying to fix an issue that's affecting me and some others.
Fixes #8934
@rename on input type fields was silently ignored by the code generator, so fields like equals would generate public string Equals { get; } — a member that shadows object.Equals — causing a CS0102 compiler error with no way to work
around it.
Two bugs in SchemaHelper.Load() were responsible:
InputObjectTypeExtensionNode was silently discarded When a schema extensions file contains a SchemaExtensionNode, the file takes the "extension document" branch. That branch handled ScalarTypeExtensionNode, EnumTypeExtensionNode,
ObjectTypeExtensionNode, etc. — but not InputObjectTypeExtensionNode. Any extend input block (where @rename typically lives) was dropped without error.
RenameDirectiveType was never registered with the schema builder DocumentAnalyzer looks up @rename via field.Directives.FirstOrDefault(), which matches on DirectiveType.RuntimeType == typeof(RenameDirective). Because
RenameDirectiveType was never registered, all @rename directives had RuntimeType = typeof(object) and the lookup always returned null.
A third related fix prevents a SchemaException when the user's schema SDL also declares directive @rename(...) — those declarations are now filtered from non-extension documents before AddDocument() since we always register
RenameDirectiveType programmatically.
Tests added: