apollographql
support .`env` files like `apollo` CLI
Description
Would be great to support .env files like the apollo CLI does:
https://www.apollographql.com/docs/devtools/cli/#provide-an-api-key
This support was introduced hastily to the apollo CLI and there was at least some consensus that this was problematic behavior to enable by default. Not the least of which is that .env is a somewhat magic mechanism that is best enabled explicitly and involves secrets which often need various flexibilities that are application-specific (e.g., .env.staging, etc.). It also conflicts with patterns and tooling that already exists and is mature on its own, like the popular direnv project and puts the expectations of projects like Node.js' dotenv package on Rover.
In considering this, we should take time to identify other commonly adopted use-cases of this in the wild besides apollo. I also think we should alternative proposals which may very well include a more principled mechanism for using these with the currently-existing profiles feature that lives within Rover.
Agree - .env files are an environment thing that varies between languages and introducing support for it introduces yet another source of confusion for authentication.
Folks should use whatever auth setup works best for them, and Rover already has quite a bit of flexibility in this regard with the combination of profiles and environment variables.
docker and docker-compose are a good language independent references to checkout:
dockersupports a--env-fileflag.docker-compose.ymlsupports anenv_fileoption as welldocker-composesupports https://docs.docker.com/compose/environment-variables/
In local dev/test it's not uncommon to already have a docker-compose env_file, so not having to repeat yourself with redundant configs/scripts would be nice.
Would be worth exploring how we might safely enable use of an env_file even if we don't support a default .env file like the apollo CLI. In addition to supporting a --env-file flag, the supergraph.yaml in https://github.com/apollographql/rover/issues/698 could support something like docker-compose.yml does:
env_file:
- graph-dev.env
