-
-
Notifications
You must be signed in to change notification settings - Fork 43
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
GraphiQL VSCode warning: Undefined Fragment when spreading is used for an complex type #194
Comments
Hey, With these sorts of issues we require you to create a reproduction, I also think your code fragments are either incorrect or out of date as you seem to allude to an issue being present with your description that that one works correctly 😅
Then in the snippet We can't really look at this and predict what your issue is as there isn't even remotely enough information nor does your description make sense. Do note that there are also issues with JetBrains/Webstorm as they implement a custom TS LSP which doesn't have all the features. #80 Also note that doing |
OK, sorry, I'll try to prepare a real example. |
We ran into a similar problem in VSCode. Code executes as expected, but the IDE would complain about undefined fragments (when the fragment is defined in another variable and passed in as array in the second argument to Turns out we not only had the Syntax Highlighting extension enabled, but also the official LSP extension. Once we disabled the LSP extension, typing for separately defined fragments works as expected. - Perhaps there is an incompatibility with the official GraphQL LSP extension that's worth calling out in the docs? Long shot, but maybe OP is facing a similar issue in their IDE. |
@echocrow: It's likely not an incompatibility, but rather, the LSP extension is issuing its own warnings that look very similar to ours, given that there's an overlap with the GraphiQL diagnostics that both output. There's not really much we can do about that. We can check whether a Do you have a sample of your |
@kitten cheers for the response! (this may be getting a bit off-topic from OP's post - unless OP was facing that exact issue too?) Well, by "incompatibility" I meant that, as you described, the LSP extension would run its own checks and validation in the IDE. For most basic queries and mutations, that does not pose any issues. However, false errors do arise when using more "advanced" features, particularly around fragments. Those errors get flagged not by gql.tada or TS, but by the separate GraphQL LSP from the official extension. I assume these arise because that LSP does not recognize gql.tada's In an ideal world, maybe there's a way to either extend the extension LSP, helping it recognize gql.tada's extra features, or some way of instructing the GraphQL LSP to ignore gql.tada's queries function? I have no clue if either is possible though, as I know little to nothing about how that LSP works under the hood. Short of a solution to have the two co-exist, that's why I suggested perhaps a note in the docs about this caveat (akin to the note about requiring VSCode to use the workspace TS version).
Our exact setup is a little overly complex (monorepo and all). However, we're noticing this issue even with a relatively barebone graphql config file: // .graphqlrc.ts
export default {
projects: {
foo: {
schema: './packages/foo/schema.graphql',
documents: './packages/foo/src/components/**/*.graphql',
},
},
} For some reason, even this config has the GraphQL LSP validate e.g. |
I just took a look, and this doesn't seem to be reproducible if the output is limited to: On a side-note, if your There's obviously still the question of whether it's possible to avoid the conflict entirely, and this is likely something I'd like to add to our |
There doesn't seem to be a better option here than to issue a warning to check that your |
@kitten I'm pretty confident we ran into this issue even when documents was scoped to just |
That'd be very helpful! 🙌 but potentially something that should also be reported to the Even if it turns out that, for some reason, There's also not a good setting in |
@kitten repro available here: As per your comment, I suspect that this is a bug in the GraphQL LSP, validating gql.tada's GraphQL code, even when JS/TS files are not part of the configured documents. Issue opened here: Until (if?) this is addressed, I'd still recommend calling out this caveat in the gql.tada docs. The only workaround we've found so far was to outright disable the VSCode extension. |
@echocrow: we don't have editor-specific docs yet and I have a feeling that's something we'd want to avoid for as long as possible for instead leaning into TS LSP+plugin support. The problem is, as you can see in the WebStorm issue, it's often external problems and it's unclear how people arrive at solutions. We may even be talking about very personal setups here. While VSCode is the most common, there's also issues with the extension marketplace (for instance the official extensions aren't even the first that pop up in the search) So, for now, the warnings have been added to the |
except you kinda do 😅 (there is a VSCode specific note RE using the workspace version of TypeScript; but I understand the aversion, and arguably that note is more crucial and less niche.) I was picturing a similar note (even if buried on the Fragment Colocation page) that other GraphQL LSPs should be configured to not check these ts(x) files, as they will incorrectly flag gql.tada's features as errors, and compete with gql.tada's auto-completion. (the latter is less of an issue, but we were also confused why ever field was suggested twice, thinking we spotted a minor gql.tada bug. now we know that both gql.tada and GraphQL LSP were echoing suggestions at the same time.) just thought this could be a useful note to other newcomers who may already be using an LSP in the same repo. in any case, won't press the matter further! 🫡 thanks for the time and support! we have the LSP disabled for now, and hope the extraneous file checking gets fixed sometime (or we migrate fully to gql.tada before!) (and sorry again @ OP for completely hijacking this issue 🙃) |
Describe the bug
Hello. I faced problem with types when using fragment spreading.
For example:
If you have this query and want to use in another query your IDE won't discover as a type
IDE WebStorm error:
But if you use directly the object with its props without the fragment, everything works
Reproduction
No response
gql.tada version
gql.tada: 1.4.3
Validations
The text was updated successfully, but these errors were encountered: