This repository has been archived by the owner on Sep 3, 2021. It is now read-only.
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.
Before I start working on fixing tests I thought I'd share this for comment.
The underlying issue is that the library uses a name keyed map of type definitions when beginning its augmentation step. As a type and extensions to it share the same name, the extension definition overwrites the type, and when the schema is finally parsed when being converted into an executable schema the type definition is missing.
The ideal fix would be to refactor the library to not iterate through a data structure keyed by name. The fix in this PR takes the step of merging fields, directives and interfaces defined in extensions with the original list from the definition. I'm guessing this is functionally equivalent to having the extension (
extend
is more of an authoring utility as far as I can see, rather than offering api capabilities above and beyond using a type definition alone), though am happy to be corrected. Even if it is functionally equivalent, this manipulation of the types does feel a bit dirty.Let me know what you think @johnymontana
Addresses #208