-
Notifications
You must be signed in to change notification settings - Fork 1.7k
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
[lsp-server] Feature Request: Support for offline schema transforms #3760
Comments
@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!) |
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 |
I wonder if we can't solve this issue with |
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:
Our custom
@inherits
directive looks up theUserBase
type, get the fields and merges them onto the typeUser
that it is decorating - with the resulting type (once the API is running) looking like this: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.
The text was updated successfully, but these errors were encountered: