-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
yarn graphql-codegen
returns Error: Query root type must be provided.
when query root is named other than Query
.
#5758
Comments
A cursory googling of the |
Add schema {
query: query_root
} You're using the plugin |
So what you're seeing above is my attempt at a minimal repro. My actual use case has this schema definition, so this isn't the problem. I'll try to find the time to produce a minimal repro that includes the above annotation. Perhaps I'm hitting the same issue as #5756, who knows. As an aside, I put a lot of effort into researching this issue and I never found the simple fix you mention. To me this looks like a documentation bug and/or an opportunity to clarify the error message. I don't have more time to put into this right now, maybe in a couple weeks I can submit a PR. |
@LilRed I think you're hitting a very similar issue to ours. Your issue here was very helpful, our repositories now work again when reverting back and freezing the cli to I suspect, like you did too, that somewhere after This shouldn't have happened and has caused many people a lot of wasted time, it's a breaking change and should have been defined as a breaking change in someone's package according to the widely used semantic versioning. |
@ItsWendell when I add the |
Changed it to |
i am running into this as well, also with a Hasura-generated schema, downgrading to 1.15.0 worked for me, 1.21.2 did not looking at the difference between 1.15.0 and 1.15.1 i dont see anything related to schemadefinition, cant tell what might have changed in the code (could have been a package/dependency) |
@madmaxlax at a glance hasura/graphql-engine#4460 seems to be a different issue entirely. |
It seems hasura has this issue of using the query_root for fields that have some sort of permission on them, which is what that Hasura issue is more about |
Banged my head against the wall with this issue as well for a few hours 🙁 Downgrading |
We're also using Hasura and downgrading to |
darn, now graphql-codegen/cli |
Hi everyone and thank you for the reports Sorry but I'm not adding a lot here but just labeling it according to our new Contribution Guide and issue flow. It seems already got into Now in order to advance to Thank you and sorry that this comment is not a complete solution (yet). |
The issue here seems to be with schemas like the following: schema {
query: query_root
}
type Query {
one: String
}
type query_root {
two: String
}
Hasura is also what I've been using, and only once I started adding a Remote Schema did it actually break. If you control the schema of the remote schema you are adding, you can modify it not to use type query_root {
file_user(user_id: Int!, file_id: String!): String
file_group(group_id: Int!, file_id: String!): String
}
schema {
query: query_root
} such that it won't be eaten by This of course is a non-preferable workaround sadly. |
Ah interesting |
@jackharrhy great finding, do we know which version of graphql-tool start to have this issue? Maybe we can pin our dependency to a version that doesn't have that issue? |
@jackharrhy my repro only has one top-level query type, doesn't that contradict your hypothesis? |
graphql-codegen does some post processing on the schemas it's handed so it's best to see what the schema that's failing to validate actually is vs. the schema you are handing to graphql-codegen I did this by using printSchema from the graphql-js package just before the validation error was thrown and I saw the invalid schema that didn't match the schema that was passed in |
It seems working with the latest versions. Maybe I am missing something; |
Try changing the schema you have there to: schema {
query: query_root
}
type Query {
not_user: Int!
}
type query_root {
user(id: ID!): User!
}
type User {
id: ID!
username: String!
email: String!
} |
Hmm weird it happens on CodeSandbox while it doesn't happen on the repo |
I spent about an hour dealing with this, and fixed it by updating graphql from 14 to 15. not sure what else could have been involved but here are my other packages after I got it working:
I assume it's possible one of these packages had an incompatibility with graphql@14, but in my case it was just easier to start from a clean slate with |
I'm having the same problem here. I've tried various different permutations of my dependencies, with no joy. Even going back to the version I had originally hasn't worked (presumably due to not pinning some internal dependency). Does anyone have any insight into where the actual problem is, or what internal dependency I should try and pin? |
@commandodev Could you create a reproduction or failing test? So we can help you better. |
Same issue here. Doesn't matter the version of various dependencies it seems. The latest version I could get to work was also v1.15.0 (and not v1.15.4 for example) I'm guessing that v1.15.0 working has something to do with:
That dependency being warned about works, and whatever the new dependency is ( I'm guessing |
@ardatan I create a very small repo with the error described in this ticket: As @jackharrhy precised, the issues happens when
For the error to happen, the reference must be called in one of the document. E.g:
This would have no problem to generate. But defining a document that reference codegen_bug/src/graphql.d.ts:
I'll try to do a PR for failing test, but that will not be coming until end of next week at best. |
For anyone using Hasura with remote schema, the comment for @jackharrhy does work well. (#5758 (comment)) The goal is to remove the Since hasura merge the remote schema and its own, defining the remote server schema with same type name as hasura fixes the issue. In NestJs, this is a bit hard to do, as the type are hardcoded.
This must executed before any Then modify the schema with the
This is a temporary hack of course. It may break when updating nestJs. |
Seems like most of the use-cases here are around Hasura, and the solution suggested by @jackharrhy . @ardatan is there anything we can do in |
Take a look at this comment: #5758 (comment) , the flow there does makes sense, no? |
@dotansimha I am not able to reproduce it on GraphQL Tools. GraphQL Tools respects schema definition as usual. |
@ardatan Is it not reproduced in this project? |
@msimon I mean I am not able to create a failing test on GraphQL Tools repo. |
@ardatan The problem is not around generating the codegen for the schema itself. (e.g the graphql.d.ts) In the small project I created, if you remove this folder https://github.com/msimon/codegen_hasura_remote_schema_bug/tree/master/src/graphql, everything works as expected. Let me know if I can help in any way. |
@msimon I see what the issue is and I am trying to debug the issue and it seems like GraphQL Tools doesn't overwrite schema definition like said above. |
@AradAral Thanks! |
As @ferm10n suggested, upgrading to |
41e9358 @ardatan It seems the schema returned by
Validation fails when the schema is passed to graphql.validate in validateGraphQlDocuments.
"@graphql-codegen/cli": "1.15.0" - https://codesandbox.io/s/competent-lichterman-9y4tv |
@dimbslmh I see but I am not able to reproduce it on GraphQL Tools. Could you help me with that? Otherwise I cannot fix it. |
@ardatan I'll try and take a look. |
@ardatan These are the actual versions installed from "@graphql-codegen/cli": "1.15.0" ONLY - https://codesandbox.io/s/nifty-agnesi-f85q7
"@graphql-codegen/cli": "1.15.1" ONLY - https://codesandbox.io/s/heuristic-hodgkin-pflf4
Based on this, I was able to reproduce it.
As you can see the |
@ardatan I have found out that Adding a resolution to the package.json in "@graphql-codegen/cli": "1.15.1"- https://codesandbox.io/s/festive-platform-g4xm1
Hopefully this is enough for you to get it fixed. |
I am already seeing this issue on codegen side but reproduction with codegen doesn't help so I need a failing test on GraphQL Tools repo :) That's what I cannot reproduce and I need help there |
@ardatan I have here: #5758 (comment) I have added the validation. There is a working and reproduced version. |
@dimbslmh I need a failing test like I said multiple times above :) |
@ardatan there must be something causing the test to pass in the monorepo, where we actually expect it to fail. See following codesandbox. This is basically a replicate of https://github.com/ardatan/graphql-tools/blob/c5b0719c70d89c6a672705b6be98772097c8e9ab/packages/load/tests/loaders/schema/schema-from-typedefs.spec.ts Run yarn test to see it fail. Note: I disabled the mockGraphQLServer in testing/utils.ts, because I couldn't get it to pass the linting. |
I see but we still need it in the repo to move on :) |
The issue is |
Fixed in #6622 ! |
@ardatan glad it's fixed now. Thank you! |
Thank you so much! |
Describe the bug
yarn graphql-codegen
returnsError: Query root type must be provided.
when query root is named other thanQuery
, for examplequery_root
as in Hasura.To Reproduce
Steps to reproduce the behavior: run this CodeSandbox, or clone this repo and
yarn install && yarn graphql-codegen
.The operation succeeds if
query_root
is renamedQuery
, or if@graphql-codegen/cli
is downgraded to1.15.0
or below.The operation fails if
@graphql-codegen/cli
version is set to1.15.1
or any superior version. (Tested1.15.1
,1.15.4
,1.17.10
,1.21.3
).codegen.yml
config file:Expected behavior: this should succeed I think?
Environment:
@graphql-codegen/...
: anything >= 1.15.1The text was updated successfully, but these errors were encountered: