apollo-tooling: VSCode: ENGINE_API_KEY not found in in Vue CLI project
Apollo GraphQL Visual Studio Code plugin loads schema from Apollo Engine.
The plugin fails to find my ENGINE_API_KEY
In a Vue CLI project, the .env
file is a committed file, where common variables should be stored. .env.local
is a git ignored file where private variables should be defined. Since the Apollo GraphQL VSCode plugin looks in the .env
file only, it can’t find the ENGINE_API_KEY
as defined in my .env.local
file.
I’m proposing that the code (included below) that loads the env file needs to change to make it compatible with Vue CLI projects. Depending on how you want to change it to make it flexible, it might look something like checking all files that start with .env
, although I can see potential issues there.
For inspiration, here’s how Vue CLI does it:
Apollo GraphQL Visual Studio Code 1.5.2
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 9
- Comments: 15 (14 by maintainers)
If
.env.local
is what Vue projects already tend to have, I’d say we should support that - especially if using the.env
file is a non-starter, which is what it sounds like..env.apollo
isn’t a bad option, but it’s one more config file that doesn’t need to be there.@gwardwell I believe you’re right, that this doesn’t add much in the way of complexity. We have two places where this file is loaded - the extension, and the language server. This may not be a bad time to unify the approach if it’s reasonable to.
Sidenote: something along these lines should do the trick -
require("dotenv").config({ path: "../.env.local" });
I agree with @trevor-scheer. I think adding an Apollo specific environment file is overkill. I like the idea of adding support for
.env.local
@JakeDawkins I get the complexity concern, but I think it’s an important request to get Apollo’s VSCode plugin working with Vue CLI applications and the
.env
anti-pattern they created.Looking at the code that handles loading the
.env
file, I think modifying it to also look for.env.apollo
would be extremely simple and would ultimately add very little real complexity.@JakeDawkins I like the
.env.apollo
idea. That gets my vote.Thanks for the workaround. I’m going to give that a try and see if it gets the plugin working for out project.
So sorry, I haven’t had the time to check it out quite yet. Been working on some pretty high priority perf and usability bugs 😬
@gwardwell I think that sounds right to me. The
.env
loading happens herehttps://github.com/apollographql/apollo-tooling/blob/master/packages/apollo-language-server/src/config/loadConfig.ts#L114
The extension watches for
.env
updates here:https://github.com/apollographql/apollo-tooling/blob/master/packages/vscode-apollo/src/languageServerClient.ts#L56
And here’s a test you can use as a model to modify and test the
loadConfig
changes:https://github.com/apollographql/apollo-tooling/blob/master/packages/apollo-language-server/src/config/__tests__/loadConfig.ts#L274
I may be missing something, but I think that’s a good starting point
@gwardwell - @JakeDawkins will know best as far as priority goes, but I don’t believe this is on our radar at the moment. A PR would be welcomed, though!
One option (which I don’t think would be great tbh, just wanted to voice it) could be to have a setting in vscode. I don’t think it’s a great option, since that’d be the only setting there, and would require a few extra things to work properly.
Maybe we could support a
.env.apollo
file that takes precedence? I don’t think that’d cause many issues.A workaround that’s possible right now is that you could have an apollo config that’s only used locally like
apollo.config.js
. The local config could hold the api key under theengine.apiKey
key in the config object.There could be a separate config to be committed and used on the ci like
apollo.ci.js
and just choose that config with a cli flag--config=apollo.ci.js
. Would that be sufficient?