Look into leveraging `graphql-config`

[JoviDeCroock]

It would be easier if all of the GraphQL tools leveraged a centralised config for i.e. retrieving the schema, ... building out support in the LSP would be great for that.

https://the-guild.dev/graphql/config/docs/user/schema

[palmamartin]

This would then also enable to use something like an environment variable if authentication is needed to retrieve the schema?

See: https://github.com/0no-co/gql.tada/discussions/54

[kitten]

@palmamartin I'm not sure what your use-case here is, so it might be useful for you to open a discussion with more details 🤔

Basically, a CLI can of course support environment variables, however, the LSP is loaded by the tsserver, so potentially and most definitely without any variables set, as it's an isolated process (e.g. launched by the editor, which in VSCode's case is even not in a PTY at all)

If we mean dotenv files, sure, those could be loaded, but there'd still be no acceptable way of mapping variables from a .env file to the config itself.

The CLI, planned in gql.tada is really the bridge here, because, my assumption is that if introspection is disabled and you plan on using the LSP to retrieve the schema from a URL (i.e. a case that's impossible for you to safely do), then a CLI to download the schema separately would be more suitable, unless you have another destination to read an SDL file from

[palmamartin]

@kitten Sorry If I wasn't clear. What I really want to achieve is to solve the problem from this discussion and thought maybe using something like graphql-config could solve that problem.

What I find cool about gql.tada (besides the typesafety it brings) is that I do not need any CLI step involved. Currently we are using a codegen.ts file to retrieve schema (and generate types) and every time I change something on the CMS (GraphQL backend), I need to remember to run the CLI to update the schema on my front end application.

[paolostyle]

Is the tada's CLI the answer for now? I would 100% prefer to use graphql.config.* file as that's what I've been using for now and both VSCode and WebStorm support that, the fact that I don't need to care about downloading the schema and it's just automatically introspected from my staging environment is amazing.

my assumption is that if introspection is disabled and you plan on using the LSP to retrieve the schema from a URL (i.e. a case that's impossible for you to safely do), then a CLI to download the schema separately would be more suitable, unless you have another destination to read an SDL file from

I think it's safe to say that in production the introspection should be disabled, but in my case, like I mentioned, I'm using a staging backend that has introspection enabled for this very reason and I don't see anything wrong with that. In cases like that, the ability to automatically introspect and fetch the schema is very convenient. I'd also argue that if you know you can't introspect the schema and you need another way to do that is a different problem.

I'm not even sure if supporting graphql-config is an option at all considering LSP development is likely quite different from regular library development but for what it's worth, here's my graphql.config.cjs file and what I would like GraphQLSP to support:

require('dotenv/config');

module.exports = {
  schema: [
    {
      [process.env.VITE_GRAPHQL_API_URL]: {
        headers: {
          'X-API-Key': process.env.VITE_GRAPHQL_API_KEY,
        },
      },
    },
  ],
  documents: ['src/**/*.{graphql,ts,tsx}'],
};

[kitten]

@paolostyle: Just to point this out, since I've just seen this by chance. We explicitly don't recommend mixing non-GraphQLSP diagnostic/editor tooling with GraphQLSP. I know this is specifically an issue with WebStorm, and I haven't heard back about this. See this issue for more info: https://github.com/0no-co/gql.tada/issues/80

Having another editor plugin (e.g. what's built into Webstorm/Jetbrains, or the VSCode GraphiQL plugin) provide another layer of diagnostics kind of defeats the point of GraphQLSP and also falls over for projects that wish to use the upcoming Multi-Schema tooling.

It's technically still possible to use gql.tada + GraphQLSP when your editor doesn't support TypeScript plugins (and I still unfortunately don't know if Webstorm has a workaround/trick/hidden config for this), but it's best to then rely on the gql.tada CLI, as that'll consistently catch usage issues and give you accurate diagnostics, i.e with gql.tada check.

So, just to point this out, gql.tada's CLI + gql.tada (the lib) + GraphQLSP is kind of aiming to be a "one stop shop for this", so while this issue is still potentially relevant when GraphQLSP is used without gql.tada, this doesn't apply for WebStorm anyway, since it will never run GraphQLSP afaik.

tl;dr: for gql.tada we wouldn't be able to iterate on more advanced features (e.g. persisted documents, multi-schema, better diagnostics) if we were to lean on graphql-config.