-
-
Notifications
You must be signed in to change notification settings - Fork 818
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
PR: merge graphql-tools-fork #1206
Conversation
yaacovCR
commented
Sep 22, 2019
- If this PR is a new feature, reference an issue where a consensus about the design was reached (not necessary for small changes)
- Make sure all of the significant new logic is covered by tests
- Rebase your changes on master so that they can be merged easily
- Make sure all tests and linter rules pass
- Update CHANGELOG.md with your change. Include a description of your change, link to PR (always) and issue (if applicable). Add your CHANGELOG entry under vNEXT. Do not create a new version number for your change yourself.
Features Adds graphql-upload compatible scalar and link for proxying remote file uploads #671 Bug Fixes Filter unused variables from map when proxying requests |
8883286
to
98b0986
Compare
9bdc352
to
80918f1
Compare
I really need #1200 please. My code is using wrapper types to handle values validation. And because of that, I cannot get my API correctly stitched. |
In the meantime you can use graphql-tools-fork. https://www.npmjs.com/package/graphql-tools-fork If you don't want to change your imports everywhere, an alias package can be used. https://www.npmjs.com/package/module-alias Hopefully this will be merged soon. |
any updates? |
It looks like graphql-tools maintainers (apollo) don't want to accept any changes due to the deprecation of schema stitching. Their focus right now on Apollo Federation. |
I hope not, because for my use case Apollo Federation is not an option. The services I am using can't support Apollo Federation specs right now. |
f8a88f5
to
56e8861
Compare
I don't understand how they can deprecate schema stitching when federation hasn't even reached a version 1. Currently error handling with schema stitching is just completely broken for me, but there's no plan to fix this? Maybe we should make an official long term fork of graphql-tools? |
ba4ceb3
to
49d8fcd
Compare
Streamline mapper selection for types and directives. Lays groundwork for additional SchemaMapper object formats, i.e. the resolver map format with specification of individual types/directives by name.
v12 does not support extensionASTNodes v13 supports extensionASTNodes for query, mutation, and interface types
MapSchema actually can be used to rename scalars -- even to rename specified types -- because rewiring does not modify the original types (as opposed to healing).
Use interfaces over tpes whenever possible as per official TypeScript recommendation, so as to support declaration merging. Separate delegation methods from stitching. Rename folders to verbs when possible for consistency. Rename transforms folder => wrap. Move makeRemoteExecutableSchema to wrap folder, as it wraps a remote schema.
Use files property within package json to white-list files in straightforward fashion. Do not publish extra markdown/images.
using mapSchema rather than visitSchema changes print(schema) order
now that fieldToFieldConfig has been removed, closes #44
for backwards compatibility See ardatan/graphql-toolkit@46ce356#commitcomment-37987581
move wrapping transforms into separate subfolder
move wrapping resolvers to wrap folder, was placed in old stitching folder because makeRemoteExecutableSchema was in stitching, but makeRemoteExecutableSchema now belongs in the wrap folder, an older method besides wrapSchema/transformSchema of wrapping a schema, specifically for remote schema.
and run prettier
- adds TransformCompositeFields as generic transform that can function on fields belonging to objects and interfaces - refactoring TransformObjectFields to use TransformCompositeFIelds - adds TransformInterfaceFields along similar lines - adds RenameInterfaceFields and FilterInterfaceFields in parallel to RenameObjectFields and FilterObjectFields - make supporting types more generic and export them - add test for RenameInterfaceFields
already contained within transforms folder
BREAKING CHANGE: Allow specification of args even with root field transformations. Includes changes to createRequestFromInfo and createRequest signatures and related interfaces, streamlining them to only use the targetOperation and targetFieldName, returning to the original upstream graphql-tools behavior of adding args later as a transform. args passed to delegateToSchema, however, are still optional. All args passed to delegateToSchema are serialized using the targetSchema serialization, if available.