feat: go-to-definition for source files rather than from generated config schema result
See original GitHub issueActual Behavior
When using “Go to definition” in one of the .graphql files, it always opens auto-generated generated-schema.graphql file, instead of the source code.
Expected Behavior
Correctly navigate to the source file.
Steps to Reproduce the Problem Or Description
.graphqlrc.yml file:
overwrite: true
schema:
- "./src/typeDefs/*.graphql"
generates:
./src/schema.generated.ts:
plugins:
- "typescript"
- "typescript-resolvers"
config:
noSchemaStitching: true
optionalInfoArgument: true
contextType: ./context#Context
./types/generated.ts:
plugins:
- "typescript"
config:
noSchemaStitching: true
This is in apollo server project. All schema files are located in the same folder: ./src/typeDefs/*.graphql
. I have a number of .graphql files that have type definitions for the server. This is happening to all types, as far as I can tell.
Specifications
- GraphQL for VSCode Extension Version: v0.3.1
- VSCode Version: 1.47.3
- OS Name: OSX Mojave
- OS Version: 10.14.6
Logs Of TS Server || GraphQL Language Service
Logs
8/31/2020, 12:43:37 PM [4] (pid: 90841) graphql-language-service-usage-logs: {"type":"usage","messageType":"initialize"}
undefined
8/31/2020, 12:43:37 PM [4] (pid: 90841) graphql-language-service-usage-logs: {"type":"usage","messageType":"textDocument/didOpen","projectName":"default","fileName":"file:///Users/ivolodin/Code/orchestration/src/typeDefs/comments.graphql"}
undefined
[Error - 12:43:42 PM] Request textDocument/definition failed.
Message: Request textDocument/definition failed with message: Definition not found for GraphQL type CommentEdge
Code: -32603
8/31/2020, 12:43:43 PM [4] (pid: 90841) graphql-language-service-usage-logs: {"type":"usage","messageType":"textDocument/definition","projectName":"default","fileName":"file:///Users/ivolodin/Code/orchestration/src/typeDefs/comments.graphql"}
undefined
8/31/2020, 12:43:43 PM [4] (pid: 90841) graphql-language-service-usage-logs: {"type":"usage","messageType":"textDocument/didClose","projectName":"default","fileName":"file:///var/folders/lq/qs7z73kn4fb7b2csz2j323943khnrg/T/graphql-language-service/orchestration/projects/default/generated-schema.graphql"}
undefined
8/31/2020, 12:43:43 PM [4] (pid: 90841) graphql-language-service-usage-logs: {"type":"usage","messageType":"textDocument/didOpen","projectName":"default","fileName":"file:///var/folders/lq/qs7z73kn4fb7b2csz2j323943khnrg/T/graphql-language-service/orchestration/projects/default/generated-schema.graphql"}
undefined
8/31/2020, 12:43:45 PM [4] (pid: 90841) graphql-language-service-usage-logs: {"type":"usage","messageType":"textDocument/definition","projectName":"default","fileName":"file:///Users/ivolodin/Code/orchestration/src/typeDefs/comments.graphql"}
undefined
8/31/2020, 12:43:45 PM [4] (pid: 90841) graphql-language-service-usage-logs: {"type":"usage","messageType":"textDocument/didClose","projectName":"default","fileName":"file:///var/folders/lq/qs7z73kn4fb7b2csz2j323943khnrg/T/graphql-language-service/orchestration/projects/default/generated-schema.graphql"}
undefined
8/31/2020, 12:43:46 PM [4] (pid: 90841) graphql-language-service-usage-logs: {"type":"usage","messageType":"textDocument/didOpen","projectName":"default","fileName":"file:///var/folders/lq/qs7z73kn4fb7b2csz2j323943khnrg/T/graphql-language-service/orchestration/projects/default/generated-schema.graphql"}
undefined
8/31/2020, 12:43:46 PM [4] (pid: 90841) graphql-language-service-usage-logs: {"type":"usage","messageType":"textDocument/definition","projectName":"default","fileName":"file:///Users/ivolodin/Code/orchestration/src/typeDefs/comments.graphql"}
undefined
8/31/2020, 12:43:46 PM [4] (pid: 90841) graphql-language-service-usage-logs: {"type":"usage","messageType":"textDocument/didOpen","projectName":"default","fileName":"file:///var/folders/lq/qs7z73kn4fb7b2csz2j323943khnrg/T/graphql-language-service/orchestration/projects/default/generated-schema.graphql"}
undefined
Issue Analytics
- State:
- Created 3 years ago
- Reactions:2
- Comments:19 (14 by maintainers)
Top Results From Across the Web
File "glob" patterns don't work for schema config pointers #239
The fix involves using something like fast-glob to detect graphql config glob paths and parse and cache the files in our custom implementation....
Read more >Go to the TypeScript source file instead of the type definition ...
The way it is currently, I have to browse by myself to the /src folder of the library, under /node_modules , if I...
Read more >May 2022 (version 1.68) - Visual Studio Code
This setting works alongside files.exclude to hide unwanted files from the ... Several bugs were fixed to make the resulting foreground color more...
Read more >Contributing code in LoopBack 4
This is useful to test or debug your applications or extensions with project dependencies on LoopBack 4 against a local git repo and...
Read more >Cumulative Changes from Mainframe Express to Micro Focus ...
How to create an application created with Mainframe Express to ... The .csv source files used in data-driven tests can now reference ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@ilyavolodin thanks for reporting - this is a known issue. we will expose the config option in the next patch release, which you’ll be able to configure from vscode settings to default to source files (the setting is there, just doesn’t work yet). by community demand, we went with a schema-first approach by default!
this should be fixed now, please let me know if i should re-open