apollo-tooling
apollo-tooling copied to clipboard
localSchemaFile doesn't work if env var is present
Intended outcome:
If a localSchemaFile
is defined, it will take precedent and load schema from the file, regardless of whether or not an engine schema is found.
Actual outcome:
the language server tries to load the schema from engine since it found an ENGINE_API_KEY. Even if it fails to load the schema, the localSchemaFile won't be taken into account
How to reproduce the issue:
- Configure a client project to load a schema from a local schema file
- Verify the schema loads from the local schema file
- Add a .env file with an ENGINE_API_KEY (valid or not)
- Try to use CLI features
Versions
VSCode 1.5.2
I'm experiencing this as well, I thought i was going mad as I kept trying unsuccessfully to alternate between loading my schema from production and localhost during development.
Although the url may be set to something like http://localhost:3000
in the apollo.config.js
, it still tries to load from Apollo Engine if an API key is present in the .env
file. This means to alternate you currently have to continually add and remove the API key from the .env
file.
My apollo.config.js file for reference
module.exports = {
client: {
service: {
name: "myDataGraph",
url: "http://localhost:3000"
},
includes: ['source/**/*.js'],
}
}
Yeah I think the precedence of these things should be flipped. For schema loading, the config file should overwrite the service referenced by the env variable. I'd have to see if there are any gotchas for that though.
👀
This is still an issue, primarily with codegen
This behavior still happens today and also manifests itself in the VSCode Apollo GraphQL extension. when you have both a local schema file and an engine API key. I think there are a number of issues, but folks probably need to be able to configure rather than have just one default behavior.
For me, I would like:
-
The IDE to respect my local schema file when I'm writing queries against a new part of the graph that is in development locally, because I might be testing out a new part of my schema locally that I have not yet published. Otherwise I need to publish my work in progress graph for the IDE to respect a query I am writing.
-
I want the IDE to use the remote schema, if possible, for latency information for queries.
Since #1 is more important to us, I've actually just removed the API key from my .env file and now load it separately when starting my apollo server, so we lose all latency information in the IDE.
This issue is critical in our case. We set APOLLO_KEY
in our CI, and generate our types before publishing the new schema to production. Hence the types generation usually fails since the remote schema is not up-to-date.
Is it possible to merge the related PR, since everything looks alright?
For those struggling on this issue, you can solve it by adding --key=null
in the CLI options of apollo:codegen
:)
Is there anything I can do to help move the PR along?
For our use case, it would be ideal to get the behavior as @dannycochran described;
- Use the local schema file primarily for the schema shape
- Overlay the local schema with performance metrics from our production graph from Apollo Studio wherever the production and local schemas overlap.
this makes developing with vscode a pain, if you want to use apollo studio together with the vscode extension