Description
I'd like to have multiple .env files with support to load them in order of precedence. For example, assume a project defines
If local exists, that file should be used. If not, it should load .env instead. This way, any CI/CD pipelines can use the .env file (included in source control) with templated values at build time, where as locally, I can simply redefine the file with the .local extension (excluded from source control) with the desired values.
Example
In dotenv, you can pass an array to path for such functionality (see: manage multiple environments) like so:
require('dotenv').config({ path: ['.env.local', '.env'] })
It would be great if dotenv-webpack could support this syntax for path similarly, like so:
plugins: [
new Dotenv({
path: [path.resolve(__dirname, `../.env.local`), path.resolve(__dirname, `../.env`)],
}),
],
Alternatives
I've looked into the suggestion on #434, but I'm not sure this is suitable to my situation as I can't rely on the NODE_ENV variable to determine whether we're doing a local build or serve versus a pipeline build as I have multiple environments being marked as development which are technically doing production builds but with different config, and so would like to avoid pipeline changes where possible.
Would the defaults feature of dotenv-webpack be suitable for this? For example, define .env.defaults as the tokenised values, and .env as containing the locally desired values (and therefore exclude .env from source control and include .env.defaults in source control?). Even if so, support for this dotenv feature would be great if possible.
Description
I'd like to have multiple
.envfiles with support to load them in order of precedence. For example, assume a project defines.env.env.localIf local exists, that file should be used. If not, it should load
.envinstead. This way, any CI/CD pipelines can use the.envfile (included in source control) with templated values at build time, where as locally, I can simply redefine the file with the.localextension (excluded from source control) with the desired values.Example
In
dotenv, you can pass anarraytopathfor such functionality (see: manage multiple environments) like so:It would be great if
dotenv-webpackcould support this syntax forpathsimilarly, like so:Alternatives
I've looked into the suggestion on #434, but I'm not sure this is suitable to my situation as I can't rely on the
NODE_ENVvariable to determine whether we're doing a localbuildorserveversus a pipeline build as I have multiple environments being marked asdevelopmentwhich are technically doing production builds but with different config, and so would like to avoid pipeline changes where possible.Would the
defaultsfeature ofdotenv-webpackbe suitable for this? For example, define.env.defaultsas the tokenised values, and.envas containing the locally desired values (and therefore exclude.envfrom source control and include.env.defaultsin source control?). Even if so, support for thisdotenvfeature would be great if possible.