graphiql
graphiql copied to clipboard
Language features not working with multi projects
Actual Behavior
Will only correctly validate first project
Expected Behavior
Validation should work for all projects
Steps to Reproduce the Problem Or Description
.graphqlrc.yml
projects:
A:
schema: ./src/schemas/A.json
documents: ./src/graphql/A/**/*.gql
B:
schema: ./src/schemas/B.json
documents: ./src/graphql/B/**/*.gql
Specifications
- GraphQL for VSCode Extension Version: 0.3.1
- VSCode Version: 1.48.2
- OS Name: macOS
- OS Version: 10.15.6
Logs Of TS Server || GraphQL Language Service
Log shows it always validate file with project A
8/28/2020, 11:33:41 AM [4] (pid: 49707) graphql-language-service-usage-logs: {"type":"usage","messageType":"initialize"}
undefined
[Error - 11:33:51 AM] Request textDocument/documentSymbol failed.
Message: Request textDocument/documentSymbol failed with message: A cached document cannot be found.
Code: -32603
8/28/2020, 11:33:51 AM [4] (pid: 49707) graphql-language-service-usage-logs: {"type":"usage","messageType":"textDocument/didOpen","projectName":"A","fileName":"file:///.../A/query.gql"}
undefined
8/28/2020, 11:33:57 AM [4] (pid: 49707) graphql-language-service-usage-logs: {"type":"usage","messageType":"textDocument/didClose","projectName":"A","fileName":"file:///.../A/query.gql"}
undefined
[Error - 11:33:58 AM] Request textDocument/documentSymbol failed.
Message: Request textDocument/documentSymbol failed with message: A cached document cannot be found.
Code: -32603
8/28/2020, 11:33:58 AM [4] (pid: 49707) graphql-language-service-usage-logs: {"type":"usage","messageType":"textDocument/didOpen","projectName":"A","fileName":"file:///.../B/query.gql"}
undefined
8/28/2020, 11:37:17 AM [4] (pid: 49707) graphql-language-service-usage-logs: {"type":"usage","messageType":"textDocument/didClose","projectName":"A","fileName":"file:///.../B/query.gql"}
undefined
I'm experiencing the same problem.
.graphqlrc.json
{
"projects": {
"github": {
"schema": "src/generated/github-schema.graphql",
"documents": ["src/**/*.github.gql"]
},
"hasura": {
"schema": "src/generated/hasura-schema.graphql",
"documents": ["src/**/*.hasura.gql"]
}
}
}
in my case, both queries get validated using the first schema
thanks for reporting! must be an issue with how we upgraded graphql-config@3
tracking the fix here: https://github.com/graphql/graphiql/issues/1655
@maslianok fixed now in latest release! there was a regression with the major version upgrade of graphql-config. tested it manually and extensively so. let me know if you have any other issues.
I have absolutely the same issue in the version v0.3.10. Only I do not know, if this bugfix is contained in the version v0.3.10
Something news here? I have still this problem.
might be graphql config issues? my company changed priorities so it could be a while before i can help. i will publish my example repo with the working multi-project config soon!
here is my config file .graphqlrc.yml
content:
projects:
project1:
schema: ./packages/project1/graphql-api/schema.graphql
documents: ./packages/project1/gqls/*.ts
project2:
schema: ./packages/project2/graphql/schema.gql
documents: ./packages/project2/**/*.graphql
exclude: ./packages/project2/**/*.test.(tsx|ts)
project1 is work correctly but project2 ignoring itself configuration. When I change positions of projects, project2 start working like project1 before, and project1 have same issue like project2 before
I'm having the same issue using the graphql.config.yml
instead of legacy .graohqlrc.yml
.
Looks like only the first schema will be used by GraphQL Language Server.
It still functions correctly only for the first project in the list, but incorrectly validates the remaining projects using the schema of the first project
@avele correct, i found a fix to this and several other issues this weekend!
I even got it to re-validate all watched files on change!
@acao could you manage to commit the fix?
Can we contribute? Could you please provide the solution in your mind?
any news?? @acao
hey sorry, I will pivot back to this soon. The branch had a ton of other bugs and I then went on to try to build an e2e suite for the extension to detect whether they were regressions and hit a bunch of roadblocks. I think a suite of solid high level integration tests should allow me to establish the known or unknown bugs, and then I can guarantee we can fix this in a way that works without introducing regressions across a wide range of project configs, across schema configs and pertinent configurations like persisting schema from network, etc.
The only issue with this over proper vscode extension e2e suite is that by mocking the IDE extension client messages, we don't always get the full spectrum of realistic client behavior. I would like to solve this before introducing multi-root workspace support, because that compounds the multi-project complexity, though I vaugely recall the contributed PR for multi-root effort may have solved this issue as well.
I should also probably separate out the part where I re-validate the entire project file tree on change (thus the issues dissapear and the red files, as with the typescript service in the last few years), or make it a config option, but the more ideal solution would be an approach that only re-validates files that contain related graphql operations or schema. I manage to debounce on change, but validating the entire document tree on change is a lot of work!