Apollo-tooling: localSchemaFile doesn't work if env var is present

Created on 19 Mar 2019  路  5Comments  路  Source: apollographql/apollo-tooling

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

cli 馃悶 bug

Most helpful comment

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'],
    }
}

All 5 comments

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:

  1. 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.

  2. 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.

Was this page helpful?
0 / 5 - 0 ratings