graphql / graphiql

GraphiQL & the GraphQL LSP Reference Ecosystem for building browser & IDE tools.
MIT License
16.12k stars 1.73k forks source link

[lsp-server] Feature Request: Support for offline schema transforms #3760

Open Borvik opened 2 months ago

Borvik commented 2 months ago

The API I've been working on has created some custom directives to make development easier, and usage of these relies on the mapSchema from @graphql-tools/utils to transform the schema.

I do realize that the extension can be configured to connect to the remote (localhost) api service to introspect the schema - however, that doesn't allow for proper Go-To Definition to work either - since the schema is split among a number of different files and introspection treats it as a single temporary large schema file.

I know this extension can be configured for glob pattern schema files schema: '**/*.gql' - and that works good for the Go-To definition, but errors due to the directives injecting extra fields onto the types.

Offline schema is also preferred since the developer doesn't actually have to spin up the api for it to start working.

A very small sample of what we are doing:

interface UserBase {
  user_id: ID!
  username: String!
  first_name: String
  middle_name: String
  last_name: String
}

type User implements UserBase @inherits(field: "UserBase") {
  created_at: DateTime
}

Our custom @inherits directive looks up the UserBase type, get the fields and merges them onto the type User that it is decorating - with the resulting type (once the API is running) looking like this:

"""@inherits from UserBase """
type User implements UserBase {
  created_at: DateTime
  """@inherits from UserBase .user_id"""
  user_id: ID!
  """@inherits from UserBase .username"""
  username: String!
  """@inherits from UserBase .first_name"""
  first_name: String
  """@inherits from UserBase .middle_name"""
  middle_name: String
  """@inherits from UserBase .last_name"""
  last_name: String
}

It would be awesome if there was some way to configure the extension (and therefore the language-server) by providing an extra script or function to introduce our own schema mapping so we can help the language server understand our custom directives.

If something like this were possible, an extra enhancement would be to allow the extensions customization to indicate the original file/line that the Go-To definition would take when encountering these injected fields.

acao commented 2 months ago

@Borvik there is a new interface for customizing jump to definition that I just added that would facilitate this! I can't remember what I named it, will check when Im home, but it can be configured from your graphql config file. it was designed to match a similar capability in relay LSP (which I might add, does not require relay and is a nice alternative to our LSP!)

Borvik commented 2 months ago

I'd be very interested to know what that would be - though the request isn't purely about the jump to definition, it's mostly about the ability to handle schema transforms that aren't available to be parsed from the source *.gql files

acao commented 2 months ago

I wonder if we can't solve this issue with graphql-config itself, as it allows very dynamic appraches for loading schema. I will circle back to this soon as I clear up some other things

Borvik commented 2 months ago

If we could tap into and register an extension on the config, that might be possible