Skip to content
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

Support code files (js, ts) as schema files #1425

Open
addiebarron opened this issue Apr 19, 2024 · 1 comment
Open

Support code files (js, ts) as schema files #1425

addiebarron opened this issue Apr 19, 2024 · 1 comment

Comments

@addiebarron
Copy link

addiebarron commented Apr 19, 2024

Is your feature request related to a problem? Please describe.

I work on a project that defines its GraphQL schema in gql tags across a number of .ts files in the server directory. We generate a schema.graphql file from those code files in the pre-commit step using graphql-codegen, but during development the most up-to-date information about the schema is in those gql tags, not in the schema.graphql file.

Furthermore, in my IDE, clicking through any client-side definitions (e.g. a query name in a query operation) sends me to the generated schema rather than the typescript source, which is what we'd consider the "source of truth". (I recognize this could also be implemented as an IDE feature. I'll make a ticket there as well).

Describe the solution you'd like

Graphql config files should support js/ts files in the schema field. Consumers can parse the graphql from those files as they choose.

Describe alternatives you've considered

The only working alternative now is to search the codebase for the definitions as they appear in Typescript.

Additional context

Some kind of "source map" concept could potentially solve this as well. I wish I could integrate directly with graphql-codegen!

@addiebarron
Copy link
Author

addiebarron commented Apr 21, 2024

I noticed this is technically possible, as certain tools do integrate with documents this way (vscode's graphql lsp-server supports this albeit in a limited/buggy capacity). It would be great to have the behavior formalized and added to the docs! I'd be willing to make that docs PR but I don't know enough about the library's behavior to describe it accurately.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant