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
fix(typeMerging): fix interface merging #1917
Conversation
Note that |
The latest changes of this PR are available as alpha in npm: Quickly update your package.json by running:
|
Dang, while I don't have any specific use for this kind of interface merging, I sure am glad I can! I'll write up another section in the type merging guide on combined interface strategies. This is a woefully under-discussed concern across GraphQL projects for something that really isn't an obscure edge case. |
thanks go to @gmac for finding this bug and contributing test code see: #1911 (comment)
e9724ae
to
f08be95
Compare
Huh, my quick survey of how this works in federation is that interfaces seem to be required to be identical across subschemas. I did not realize that. A few links: |
Just a separate note relating back to graphql-tools/packages/stitch/tests/extendedInterface.test.ts Lines 34 to 36 in b8551da
Gateway type definition, if Not sure yet which one I would prefer based on style, I think I would prefer |
Thanks again @gmac for the huge amount of work you are putting in to type merging!!! |
All praise goes to you, friend. It’s an honor to provide backup on such a great project. The links you post pretty well summarize the state of cross-service interfaces in my research... inconclusive and full of fairly bad options. |
fix in #1917 includes regression
thanks go to @gmac for finding this bug and contributing test code
see: #1911 (comment)