Summary
When a project's schema is a local file (localSchemaFile) and the apollo.config file lives in a subfolder, go-to-definition (Cmd/Ctrl+Click) on a schema field opens a non-existent file in the workspace root instead of the real schema file next to the config. Using a URL / introspection schema instead works fine.
This came up in #302, but it's a distinct bug from that feature request, so I'm splitting it out.
Reproduction
Config in a subfolder with a relative localSchemaFile:
myproject/ # workspace folder
└── graphql/
├── apollo.config.json # { client: { service: { localSchemaFile: "./schema.graphql" } } }
├── schema.graphql
└── query.graphql
Open query.graphql, Cmd/Ctrl+Click a field.
- Expected: jumps to
graphql/schema.graphql.
- Actual: opens a non-existent
schema.graphql in the workspace root.
Root cause
In src/language-server/providers/schema/file.ts, the schema file is read relative to the config directory (readFileSync resolves against configDir), so loading succeeds. But the Source URI attached to the schema AST — the one used for go-to-definition — is built with resolve(path), which resolves relative to process.cwd(). In the extension process.cwd() is the first workspace folder, not the folder the apollo.config lives in, so the definition location points at <cwd>/schema.graphql.
The same process.cwd() assumption is also in getRelativeLocalSchemaFilePaths (project/internal.ts), used to exclude the schema file from the scanned documents.
Fix
Resolve both the read path and the URI (and the exclude glob) relative to the config file's directory, so read and go-to-definition always agree.
I have a branch with the fix, a regression test, and a sampleWorkspace/multiProjectSubfolders sample reproducing the exact multi-config layout: unrevised6419#1
(Opening a PR against this repo is currently locked for me, so it's on my fork for now — happy to open it here once unblocked, or the commit can be cherry-picked.)
Summary
When a project's schema is a local file (
localSchemaFile) and theapollo.configfile lives in a subfolder, go-to-definition (Cmd/Ctrl+Click) on a schema field opens a non-existent file in the workspace root instead of the real schema file next to the config. Using a URL / introspection schema instead works fine.This came up in #302, but it's a distinct bug from that feature request, so I'm splitting it out.
Reproduction
Config in a subfolder with a relative
localSchemaFile:Open
query.graphql, Cmd/Ctrl+Click a field.graphql/schema.graphql.schema.graphqlin the workspace root.Root cause
In
src/language-server/providers/schema/file.ts, the schema file is read relative to the config directory (readFileSyncresolves againstconfigDir), so loading succeeds. But theSourceURI attached to the schema AST — the one used for go-to-definition — is built withresolve(path), which resolves relative toprocess.cwd(). In the extensionprocess.cwd()is the first workspace folder, not the folder theapollo.configlives in, so the definition location points at<cwd>/schema.graphql.The same
process.cwd()assumption is also ingetRelativeLocalSchemaFilePaths(project/internal.ts), used to exclude the schema file from the scanned documents.Fix
Resolve both the read path and the URI (and the exclude glob) relative to the config file's directory, so read and go-to-definition always agree.
I have a branch with the fix, a regression test, and a
sampleWorkspace/multiProjectSubfolderssample reproducing the exact multi-config layout: unrevised6419#1(Opening a PR against this repo is currently locked for me, so it's on my fork for now — happy to open it here once unblocked, or the commit can be cherry-picked.)