Override system variables about dotenv-cli HOT 8 CLOSED

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.

from dotenv-cli.

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

from dotenv-cli.

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

from dotenv-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 👍

from dotenv-cli.

What kind of flags would you like dotenv-cli to have? How should it behave?

from dotenv-cli.

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-local

Overridden behavior: Hit production dependencies:

$ dotenv --override -e .env -e .env.override.prodction -- make serve-local

I hope this example makes sense and you find the PR a good addition to this library.

from dotenv-cli.

@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)

from dotenv-cli.

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'

from dotenv-cli.