fix: Add loc
getter on fragment documents for graphql-tag
inter-compatibility
#396
+167
−3
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.
Summary
Unfortunately
graphql-tag
has several quirks, including concatenating all interpolations' source bodies and parsing them all as a whole. While it does so, it blindly usesdocument.loc
without checking whether this property isundefined
, despite it being optional.This leads to an incompatibility since it's purposefully left out in
graphql.web
. However, during a gradual migration it's conceivable thatgql.tada
'sgraphql()
fragments will be interpolated intographql-tag
's tag functions.While this isn't recommended, since it's also possible to "blanket-migrate" from
graphql-tag
'sgql
function tographql()
functions fromgql.tada
, this would likely require codemods, so a partial migration isn't unlikely.To solve this, we now add a
loc
getter, which creates a document, similar to howgraphql-tag
would expect it recursively. It also deduplicates documents to avoidgraphql-tag
receiving invalid input when a fragment is used multiple times.Set of changes
concatLocSources
utilityloc
getter on documents for fragment outputs