Rework transformed query output to include separate fragments #1631
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.
I made a mistake thinking
sourceWithFragments
was the__typename
-ified version of the document, whilesource
wasn't.source
actually does have the__typename
s added.Including the fragments in the transformed queries actually opens up potential problems for the workflow I described in #1597 (and likely the workflow in #1607), because APIs that required persisted operations but don't support APQ generally still follow the
queries/
+mutations/
+fragments/
pattern, and expect fragments to still be separated as they are in the developer-facing source.This changes TransformedQueryOutput to save the transformed operations and transformed fragments separately, as they exist in the source. Fragments that are defined in operations (e.g.
query MyQuery { ...MyFragment } fragment MyFragment { }
are appended to the operation's file, resulting in no changes other than the addition of__typename
s.Also, no longer using
packageNameProvider
to get the destinations for these files, since those are more intended for Java/Kotlin source.