-
Notifications
You must be signed in to change notification settings - Fork 95
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
[v2] Unknown fragment spread "..." #218
Comments
Hi Junaid. Can you confirm that you're only seeing this issue in scratch files, and not with files picked up as part of the regular project source files? |
Yes Jim, Only in a scratch file. |
Now facing another issue here:
The schema file is placed with it: Now if I remove
to
I get a load of following warnings: Error: The input value type 'QueryFilterEnum' is not present when resolving type 'FilterQueryInput' [@3:1] input FilterQueryInput {
query: String!
column: String
rule: QueryFilterEnum
} Error: 'Query' type [@46:1] tried to redefine existing 'Query' type [@40:1] type Query {
me: Me! @auth @cost(complexity: {min: 2})
myLoginHistory: MyloginHistory! @auth @cost(complexity: {min: 2})
} Maybe due to split schema into multiple files? I am using graphql-import |
I figured it out. The reason is: both Both contain identical contents, so that's why! |
Fragment definitions will be picked up in scratch files as well for the upcoming beta-1 release. Best regards, |
Thank you, Jim, for your great efforts! |
Hello everyone, I have an issue that prints a similar message. Versions:
Use case: A bunch of The GraphQL tab in the IDE, under "Schema errors", shows errors such as:
Here's my
Any way to fix this? Thanks! |
@dandrei By merging you're essentially redeclaring the Query and Mutation types in your project. You need to configure schema discovery such that the two logical schemas don't "step on each others toes". You can do this by placing the generated schema in a separate folder with its own .graphqlconfig, and then excluding it from your current .graphqlconfig using the More info on schema discovery is available at https://jimkyndemeyer.github.io/js-graphql-intellij-plugin/docs/developer-guide#project-structure-and-schema-discovery |
@dandrei Yeah that's the valid issue. When you split your schema into multiple files. This error always popup. @jimkyndemeyer I am facing the same issue. Do you plan to fix this issue? P.S. I am using the following library to split my schema into chunks (later combined on runtime): |
@blacksmoke26 To your question "Do you plan to fix this issue?". I'm not sure what kind of "fix" you are expecting here? There's countless ways to implement a GraphQL endpoint, and this plugin supports two spec-compliant ways of discovering your schema: introspection and GraphQL SDL controlled by graphql-config includes/excludes. To my knowledge this allows you to split up your GraphQL files however you want, and combine them with your choice of runtime, given that you use graphql-config to produce valid schemas/type registries such that types are not redefined. |
Thanks, @jimkyndemeyer for your reply. I am excepting at least disable the warning or Inspection?
|
@blacksmoke26 It's more complicated than a simple inspection. A lot of the features in the plugin depend on types being uniquely defined within the scope of a schema. Without that assumption features such as go to definition, completion, error highlighting, and find usages don't work or make sense. All these features require that your type is defined once in a source code scope, and that a valid type registry can be built for validation and completion. Similar restrictions and assumptions underly the language tooling for other typed languages on the IntelliJ platform, so it's not unique to this plugin. From what I know of graphql-config and the use of includes/excludes you should be able to properly scope your "authoring/split" schema graphql files and the resulting "merged" schema such that they are separate scopes and valid. |
@jimkyndemeyer the issue is that # src/graphql/users/schema.graphql
type User {
id: ID!
name: String!
}
type Query {
users: [User!]!
user(id: ID!): User!
} # src/graphql/messages/schema.graphql
type Message {
id: ID!
from: User!
to: User!
date: String!
text: String!
}
type Query {
messages: [Message!]!
messagesFrom(userId: ID!): [Message!]!
messagesTo(userId: ID!): [Message!]!
}
type Mutation {
sendMessage(to: ID!, text: String!): Message
} Basically it allows me to not only split the definitions of the types into separate files kept alongside the appropriate resolvers and other code related to a specific group of endpoints, it also allows me to keep the definitions of the operations for any given group of endpoints alongside the types. This does wonders for code organisation and refactoring. I know I could still keep the |
@jahudka Have you tried the following: # operations.graphql
type Query
type Mutation # other-schema-files.graphql
extend type Query {
operationName: OperationType
}
extend type Mutation {
operationName: OperationType
} This validates according to the GraphQL spec, and should be supported by the plugin. The same |
@jimkyndemeyer unfortunately, I have tried it: ardatan/graphql-import#42 |
Hi Jim,
I am getting a warning while try to use fragment in a query (which executes without any error):
But no error return after fetch data:
Details:
P.S. Please let me know if you need more details.
Thanks!
The text was updated successfully, but these errors were encountered: