Skip to content
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

Closed
yaacovCR opened this issue Jul 8, 2020 · 4 comments
Closed

astNodes are not transformed when transforming schemas #1747

yaacovCR opened this issue Jul 8, 2020 · 4 comments
Labels

Comments

@yaacovCR
Copy link
Collaborator

yaacovCR commented Jul 8, 2020

  1. This would make it difficult to find directives on fields that have been renamed.
  2. This also breaks type merging breaks with WrapType transforms for multiple subschemas.

See #1708 (comment)

The error occurs here:

(acc, astNode) => mergeType(astNode, acc as ObjectTypeDefinitionNode) as ObjectTypeDefinitionNode,

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.

@yaacovCR
Copy link
Collaborator Author

yaacovCR commented Jul 8, 2020

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

@yaacovCR yaacovCR changed the title type merging breaks with WrapType transforms for multiple subschemas astNodes are not transformed when transforming schemas Jul 8, 2020
@yaacovCR
Copy link
Collaborator Author

yaacovCR commented Jul 8, 2020

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.

@yaacovCR yaacovCR added the bug label Jul 12, 2020
yaacovCR added a commit that referenced this issue Jul 13, 2020
yaacovCR added a commit that referenced this issue Jul 13, 2020
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
@yaacovCR
Copy link
Collaborator Author

The latest changes of #1762 are available as alpha in npm: 6.0.13-alpha-8a532b31.0

Quickly update your package.json by running:

npx match-version @graphql-tools 6.0.13-alpha-8a532b31.0

@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!

@yaacovCR yaacovCR added waiting-for-release Fixed/resolved, and waiting for the next stable release and removed waiting-for-release Fixed/resolved, and waiting for the next stable release labels Jul 13, 2020
@tommy5dollar
Copy link
Contributor

It all seems to be working now. I'll do some more testing and report back on any issues I find.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants