Related: #945 (comment)
It would be great to be able to source multiple dotenv files in a "cascading" manner, similar to https://github.com/bkeepers/dotenv#what-other-env-files-can-i-use. This allows per-environment overrides, and a .env to provide defaults to fall back on (meaning .env.test, .env.qa, .env.prod don't need to repeat the same common env vars that can be defined once in .env).
I think there may be some related work that would need to be done to be able to interpolate filenames in dotenv-files, though.
ENV := "prod"
set dotenv-files := [".env.{{ENV}}", ".env"]
And call with just ENV=prod to load env vars from .env.prod, and then .env (assuming dotenv files don't overwrite existing environment variables).
As far as behavior goes, it probably makes sense to fail silently (or log it) if a file in the array isn't found since they can just be "candidates" for dotenv files to load. For example, .env.local may not always be present in an environment, but we'll try to load it if it does happen to exist.
Related: #945 (comment)
It would be great to be able to source multiple dotenv files in a "cascading" manner, similar to https://github.com/bkeepers/dotenv#what-other-env-files-can-i-use. This allows per-environment overrides, and a
.envto provide defaults to fall back on (meaning.env.test,.env.qa,.env.proddon't need to repeat the same common env vars that can be defined once in.env).I think there may be some related work that would need to be done to be able to interpolate filenames in
dotenv-files, though.And call with
just ENV=prodto load env vars from.env.prod, and then.env(assuming dotenv files don't overwrite existing environment variables).As far as behavior goes, it probably makes sense to fail silently (or log it) if a file in the array isn't found since they can just be "candidates" for dotenv files to load. For example,
.env.localmay not always be present in an environment, but we'll try to load it if it does happen to exist.