-
-
Notifications
You must be signed in to change notification settings - Fork 796
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
astNodes are not transformed when transforming schemas #1747
Comments
Thanks to @tommy5dollar for finding this issue, exposes a gap in the entire schema transformation process which would be a large source of frustrating bugs for application of directives with transformed schemas |
I think the correct behavior would be to assume that the astNodes/extensionASTnodes may be incomplete, but that they are not incorrect, and to hope for the best. All transformSchema functions should therefore modify astNodes/extensionASTnodes if they exist. |
Each transform should also modify the underlying astnode and extensionASTNodes, if they exist. This PR also changes mapSchema to automatically update a type's astNode list of field definitions to match the actual field definitions includes within the type's new config map after mapping. There is likely space for making sure to update additional astNodes within types to match the enclosed graphql type system objects, for example, enum types with the enclosed enum values. That may be included in a separate PR at this time. Addresses #1747
The latest changes of #1762 are available as alpha in npm: Quickly update your package.json by running:
@tommy5dollar , if you get a chance, let me know if this helps. And if you appreciate the effort, please also feel free also to support my open source development by visiting https://github.com/sponsors/yaacovCR! |
It all seems to be working now. I'll do some more testing and report back on any issues I find. |
See #1708 (comment)
The error occurs here:
graphql-tools/packages/stitch/src/mergeCandidates.ts
Line 82 in 9e9c0bd
Because WrapType, HoistField -- and every other transform -- only modifies the type itself, not the prior AST.
A recent commit merges the ast nodes to allow for merging directives. The utility functions from elsewhere within graphql-tools do not default to overriding fields when they conflict, but rather throw an error.
This raises the question of whether schema transforms should modify the original ast nodes, or the logic should be changed to no longer error when the original ast nodes conflict.
The more robust solution seems to be the former, as right now the directives are lost when wrapping. The directives may be gone to begin with, they would be lost anyway if a remote schema is derived solely from introspection, but they may be available, and the true fix would seem to be to preserve them. The problem is that there is no real guarantee that the original astNode matches the current type, so not clear whether it makes sense to transform the astNode in the same way as the type.
Wrapping and Hoisting might be a special case where it makes sense to modify the ast node, as the problem here is not from lack of modification, but rather from the fact that the astNodes are not wrapped, are in the wrong place, and conflict. They don't have to be modified per se, they just have to be moved so they don't conflict.
The text was updated successfully, but these errors were encountered: