Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multi-path precedence support #508

Open
abxhub opened this issue Sep 5, 2024 · 1 comment
Open

Multi-path precedence support #508

abxhub opened this issue Sep 5, 2024 · 1 comment

Comments

@abxhub
Copy link

abxhub commented Sep 5, 2024

Description

I'd like to have multiple .env files with support to load them in order of precedence. For example, assume a project defines

  • .env
  • .env.local

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.

@mrsteele
Copy link
Owner

mrsteele commented Oct 4, 2024

The defaults absolutely be suitable. In fact, I would suggest you checkout the other npm module dotenv-defaults.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants