apollo-tooling: VSCode: ENGINE_API_KEY not found in in Vue CLI project

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 here

https://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 the engine.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?