[Question] [language server] implied fragments and support for imports

In my GraphQL build system that I set up (built on top of graphql-code-generator and @graphql-tools/import) I require explicit fragment imports:

# import SomeFragment from "./some-path.graphql"

query MyQuery {
    someField { ...SomeFragment }
}

I do this in order to minimize the potential for fragment name conflicts and make it easier to share fragments across packages.

However, this language server seems to assume that all fragments are globally available which is not always the case. Is there a way to configure this? If not, would you accept a contribution to make this configurable?

I’m also curious to learn how others deal with sharing fragments across packages. Is using explicit imports good practice? Or is it better to make all fragments globally available and then be careful to make all fragment names unique across the codebase?

[patrickszmucer]

@dotansimha I can believe that it’s hard to implement, and from what I’ve seen so far all the tooling support for imports is pretty variable (which is understandable given that this is not something that’s standarised).

However, I find it hard to imagine a world where we don’t support imports. Implied fragments work fine for small codebases, but for large monorepos where fragments are shared between many packages I feel like it’s going to be really hard to ensure that all fragments are unique.

[acao]

All excellent questions!

There is no agreed on/specified way to handle fragment imports, so we opted for the easier implied path for now

It would great to support graphql import style syntax as an opt-in feature