graphql v15 will break graphql-tools #1272
Comments
abernix
added a commit
that referenced
this issue
Feb 17, 2020
.@IvanGoncharov originally brought this to my attention when he pointed me to yaacovCR#32 (comment) and suggested stripping extension nodes prior to invoking `buildASTSchema` as a cross-version (v14 <=> v15) approach for interim compatibility on the v4 series of `graphql-tools`. The most urgent and pertinent need here from my perspective is to allow user-exploration of the new `graphql@15` release candidate within Apollo Server which currently re-exports the entirety of `graphql-tools` (even though it only relies on small portions of it). Upon further investigation of the above-referenced issue, it appears that @yaacovCR had already crafted the solution that @IvanGoncharov had suggested to me, which I found in 2280eef within the well-organized #1206 (which I am thankful for the continued updates on!). My commit here merely grabs a sub-set of that commit that seemed most pertinent; I certainly don't claim that this solution is nearly as comprehensive as the original 2280eef. My hope is that by using the same code/implementation here, it will marginally lessen future merge conflicts. Since this is basically a re-working of @yaacovCR's commit, I've attributed co-authorship of this commit accordingly. (Thank you, again!) Ref: #1272 Co-authored-by: yaacovCR <yaacovCR@gmail.com>
abernix
added a commit
that referenced
this issue
Feb 19, 2020
…1284) * Inline `PrintSchemaOptions` type, whose parent module has been moved. This option will likely be deprecated in `graphql@16`. For now, we'll inline this type into this module to continue emitting it into the declaration file for `makeRemoteExecutableSchema`. This is necessary since the TypeScript compiler can no longer resolve its previous location as `graphql` has moved the location of the `schemaPrinter` module to `printSchema` in graphql/graphql-js#2426. cc @IvanGoncharov * Fix incompatibility between `iterall` and newer TypeScript types. This wouldn't be necessary if this project had a `package-lock.json`, but... * compat: filter extensions prior to passing to `buildASTSchema`. .@IvanGoncharov originally brought this to my attention when he pointed me to yaacovCR#32 (comment) and suggested stripping extension nodes prior to invoking `buildASTSchema` as a cross-version (v14 <=> v15) approach for interim compatibility on the v4 series of `graphql-tools`. The most urgent and pertinent need here from my perspective is to allow user-exploration of the new `graphql@15` release candidate within Apollo Server which currently re-exports the entirety of `graphql-tools` (even though it only relies on small portions of it). Upon further investigation of the above-referenced issue, it appears that @yaacovCR had already crafted the solution that @IvanGoncharov had suggested to me, which I found in 2280eef within the well-organized #1206 (which I am thankful for the continued updates on!). My commit here merely grabs a sub-set of that commit that seemed most pertinent; I certainly don't claim that this solution is nearly as comprehensive as the original 2280eef. My hope is that by using the same code/implementation here, it will marginally lessen future merge conflicts. Since this is basically a re-working of @yaacovCR's commit, I've attributed co-authorship of this commit accordingly. (Thank you, again!) Ref: #1272 Co-authored-by: yaacovCR <yaacovCR@gmail.com> * Add CHANGELOG for #1284. Co-authored-by: Yaacov Rydzinski <yaacovCR@gmail.com>
|
See #1284 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
See discussion in: yaacovCR#32.
PR #1206 will be updated to include v15 support when v15 is finalized.
The text was updated successfully, but these errors were encountered: