Override system variables
Closed this issue · 8 comments
Hello,
the override system is now available is dotenv (https://github.com/motdotla/dotenv/blob/master/CHANGELOG.md#1410-2022-01-17)
It would be nice to get it in dotenv-cli
Have a nice day!
What kind of flags would you like dotenv-cli to have? How should it behave?
Incidentally, I stumbled upon this issue when trying to support override for my personal use case. Thank you for creating this issue, @mobula9.
@entropitor, I have added an example in my PR that adds support for the override config.
My use case is to support overriding environment variables using secret files. For a high level example: we develop the application locally using local API_TOKEN for a microservice that is running locally. It would be safe to store this non-secret API_TOKEN in .env file tracked by git. However, sometimes we want to hit this said microservice running in the production environment from my service running in local environment. In that case, we add the production API_TOKEN (and other environment variables such as production API_ENDPOINT) in .env.override.production which would be ignored by .gitignore to avoid tracking the secrets in git.
In the end, the usage becomes:
Default behavior: Hit local dependencies:
$ dotenv -- make serve-localOverridden behavior: Hit production dependencies:
$ dotenv --override -e .env -e .env.override.prodction -- make serve-localI hope this example makes sense and you find the PR a good addition to this library.
@raxityo that's already possible by using the right order of -e flags, have you tried switching the order? See also https://github.com/entropitor/dotenv-cli#cascading-env-variables for an alternative to this
This issue is about having a API_TOKEN as a env variable in your shell and ignoring that and only listening to the ones in the .env file (by default the ones in your shell take precedence)
Aha thanks, the order of -e is what I was misinterpreting in my example case.
However, my example illustrates a basic scenario where env variables are exclusively provided through dotenv.
In a more real-world scenario, some environment variables (such as: LOG_LEVEL, NODE_ENV, etc.) are set at the time of creating the docker image and we'd like to change their values (eg: LOG_LEVEL=info instead of warn, NODE_ENV to test instead of production) when running a particular command on that container.
I am having the same exact use case as @raxityo where I'd like to have a base config, good for development, which gets overwritten with secret values at CI/CD build/compilation.
I guess one workaround would be to create on-the-fly a .net.secret file and then pass it by
./set-secrets.sh #this dumps at runtime the secrets into .env.secrets
dotenv -e .env -e .env.secrets 'your command'
@aterreno Or you can use the -c development flag and have a .env useful for all environments and .env.development for local development and then in CI you don't use -c development and then you can just set the env variables.
Also, I think this is the reverse use-case. This issue is about when you WANT to override the env variables already set. In CI, you can just set the env variables already and then doing dotenv -e .env will not override the ones from the CI.
I have a monorepo with a global .env file that provides values for all applications. These are loaded by another utility (direnv) and are useful not just for node programs, but several project scripts I run on the command line. So these are available on the shell.
I have per-app scripts for unit/e2e testing where I want to override certain values when invoking them. For example NODE_ENV, or database connection strings. The use-case has already been discussed enough on the dotenv project and since they now support the override feature, I believe this project should too.
This fork is an example of how to implement a flag for it: https://github.com/t1m0thyj/dotenv-override-cli
I welcome a PR that actually works without reversing the order of the paths in which we load things. Otherwise, I suggest a fork is used indeed 👍