Modernize apollo-utilities graphql transformation functionality
#4233
Conversation
This will help avoid typescript errors when using `graphql` 14.x.
Required by `graphql` 14.x, unless of course we want to parse the incoming read only array, and convert it into a `GraphQLError` array. If keeping things aligned with `graphql` (by using a read only error array) proves to be problematic, especially with regards to backwards compatibility, we might have to change this.
We're using a few es7 level functions, like `Array.prototype.includes`.
`graphql` 14.x has made most parts of the AST readonly, which means we can't upgrade Apollo Client to use `graphql` 14.x, until the `apollo-utilities` transformation helpers are modified to stop writing back into the original AST. This commit replaces all cloning / re-writing with a node visitor approach, provided by `graphql`'s `visit` function.
hwillson
changed the title
apollo-utilities graphql transformation functionalityapollo-utilities graphql transformation functionality
|
|
||
| let modifiedDoc = visit(doc, { | ||
| Variable: { | ||
| enter(node, _, parent) { |
There was a problem hiding this comment.
Let's provide types for these parameters whenever possible, since otherwise they'll just be any.
There was a problem hiding this comment.
I left types out of the visitor function declarations, as Typescript appears to be able to infer them properly from @types/graphql. If I stored the visitor function object outside of the visit call, then it wouldn't be able to, but since it's part of the visit call it seems okay. Happy to change if desired though!
| fragmentSpreadsToRemove = fragmentSpreadsToRemove.concat( | ||
| fragSpreads.map(frag => ({ | ||
| name: frag.name.value, | ||
| })), |
There was a problem hiding this comment.
Same comment as above:
getAllFragmentSpreadsFromSelectionSet(
node.selectionSet,
).forEach(frag => {
fragmentSpreadsToRemove.push(frag.name.value);
});There was a problem hiding this comment.
Also, for both fragmentSpreadsToRemove and variablesToRemove, it seems like it's really a set of fragments/variables that might be able to be removed, since they might still be used elsewhere (which is something we check later). Not sure if a renaming is warranted, but thought I would mention.
There was a problem hiding this comment.
Right, I couldn't think of better naming; the reason being that fragmentSpreadsToRemove and variablesToRemove are eventually passed into removeFragmentSpreadFromDocument / removeArgumentsFromDocument as a param, and in that case they really do represent xToRemove.
Let's avoid adding in a polyfill.
benjamn
force-pushed
the
hwillson/graphql-updates
branch
from
27bea6b
to
60a2ddf
Compare
The graphql AST transformation capabilities provided by
apollo-utilitiesare no longer in synch withgraphql14.x, as they rely on being able to directly modify a graphql based AST.graphql14.x has made the internal document structure read only, so we'll need to updateapollo-utilitiesto use a different approach (likely usinggraphql's visitor functionality). We've know about this for a while (Renovate keeps reminding us - e.g. #3875), but we should definitely address this sooner than later.As a start, this PR updates the
@types/graphqlandgraphqldev deps to the latest 14.x based versions, which will break CI. This PR will serve as a placeholder until this is addressed.