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

Feature: framework specific .env file support #1303

Open
erezrokah opened this issue Sep 30, 2020 · 6 comments
Open

Feature: framework specific .env file support #1303

erezrokah opened this issue Sep 30, 2020 · 6 comments
Labels
area: command: dev status: discussion type: feature code contributing to the implementation of a feature and/or user facing functionality

Comments

@erezrokah
Copy link
Contributor

Is your feature request related to a problem? Please describe.

#924 Attempted to align our .env support with create-react-app.
After doing some thinking on how the CLI is built, we might want to handle .env files as a part of the framework detection mechanism, as some frameworks might handle those files differently.

If we find out that all/most frameworks use same the logic we can close this issue

Describe the solution you'd like

Have Netlify CLI mimic the detected framework .env file support and inherit the variables.

Describe alternatives you've considered

Using the same logic for all frameworks

Can you submit a pull request?

Yes

@erezrokah erezrokah added type: feature code contributing to the implementation of a feature and/or user facing functionality status: discussion area: command: dev labels Sep 30, 2020
@erezrokah erezrokah changed the title Featture: framework specific .env file support Feature: framework specific .env file support Sep 30, 2020
@ercgrat
Copy link

ercgrat commented Oct 13, 2020

The handling of environment variables in Next.js and netlify dev doesn't seem to be compatible. When running netlify dev my local .env variables are overridden by the Netlify variables pulled from my production settings (Site settings > Build & deploy > Environment > Environment variables).

This is at least true for the variables that I need to be accessible in the browser with the NEXT_PUBLIC_ prefix (blog post).

For anyone who runs into this, my workaround is to define a separate environment variable only in my local .env file, and add conditionals to code (womp!).

.env

NEXT_PUBLIC_PAYPAL_ENV=sandbox
NEXT_PUBLIC_PAYPAL_ENV_DEV=sandbox

In my production settings, NEXT_PUBLIC_PAYPAL_ENV=production. The browser value of process.env.NEXT_PUBLIC_PAYPAL_ENV ends up being production when running netlify dev.

workaround:

let env = process.env.NEXT_PUBLIC_PAYPAL_ENV_DEV;
if (!env) {
    env = process.env.NEXT_PUBLIC_PAYPAL_ENV;
}

@erezrokah
Copy link
Contributor Author

When running netlify dev my local .env variables are overridden by the Netlify variables pulled from my production settings

This is actually a bug. Do you mind opening a new issue for that?

@ercgrat
Copy link

ercgrat commented Oct 13, 2020

Sure thing, created it here: #1386

@Soviut
Copy link

Soviut commented Feb 16, 2022

@erezrokah rather than doing any detection, I think it would be more useful to be able to use netlify.toml to explicitly configure which env files are loaded.

Perhaps some kind of list that specified the priority to load the env files in. For example:

env_priority = [ ".env", ".env.local" ]

The above would work with Vite priorities and also be extended to support development, production and even custom (eg: staging) modes as well as their respective .local overrides.

env_priority = [ ".env", ".env.local", ".env.development", ".env.development.local" ]

This would also mean you could also configure to not inject any .env files at all with an empty list.

env_priority = []

EDIT: it might also be useful to have this as a cli flag so it could be easily overridden in npm scripts or CI/CD systems.

netlify dev --env .env .env.local

@erezrokah
Copy link
Contributor Author

Hi @Soviut, that's a good idea and we should probably do both to have:

  1. Good defaults
  2. Configurability

Are you open to submitting a PR for it? This configuration should go under the [dev] block and only apply for the CLI, correct?

@Soviut
Copy link

Soviut commented Feb 16, 2022

@erezrokah I noticed that someone else took the assignment here? #4272 (comment)

I'd be happy to collaborate. I don't know the cli code base very well so anyone more aware than me is going to be able to focus more quickly on the areas of the code that affect this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: command: dev status: discussion type: feature code contributing to the implementation of a feature and/or user facing functionality
Projects
None yet
Development

No branches or pull requests

3 participants