You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Related to changes added to implement #1814, the json-modern has a few minor bugs and pain points not related to the actual generation of type information I'd like to see addressed:
outputFileURL being passed as an option no longer causes operationID to get generated.
Probably related since it's what's used to generate operationID, the sourceWithFragments property present in previous JSON integrations is no longer there. This provided the source with full content of the fragments appended.
It looks like mergeInFieldsFromFragmentSpreads is not being respected - output is identical if I pass true or false for this.
The selectionSet's selections are using a lot of overlapping properties - if something's a field it has a bunch of properties, if it's a Fragment Spread it has other properties, if it's a conditional it has even different properties. In previous versions these were totally different types. How horrendous would it be to go back to using different types, or is this something I should try to do on the parsing side instead
Related to changes added to implement #1814, the
json-modernhas a few minor bugs and pain points not related to the actual generation of type information I'd like to see addressed:outputFileURLbeing passed as an option no longer causesoperationIDto get generated.operationID, thesourceWithFragmentsproperty present in previous JSON integrations is no longer there. This provided the source with full content of the fragments appended.mergeInFieldsFromFragmentSpreadsis not being respected - output is identical if I passtrueorfalsefor this.selectionSet'sselections are using a lot of overlapping properties - if something's a field it has a bunch of properties, if it's a Fragment Spread it has other properties, if it's a conditional it has even different properties. In previous versions these were totally different types. How horrendous would it be to go back to using different types, or is this something I should try to do on the parsing side instead