feature request: support for environment settings specific to [dev]

[fool]

Request:

folks would like to be able to set dev-specific environment variables via toml file. These should take precedence over the ones set in our Build & Deploy settings admin UI. TBD as to whether they should override locally-set-in-the-shell env vars, I leave that detail up to the implementor. I could see either way making sense!

Requestors:

Netlify's Support team is tracking customers who have requested it. So far just one request in slack (only visible to Netlify employees: https://netlify.slack.com/archives/CC07WN1GC/p1554911472067300)

[swyxio]

for the record im not taking action on this yet until we all agree on a spec (and document it!)

[dmiyamasu]

Crossroads (Enterprise plan customer) would like to see this feature added.

[swyxio]

we've had progress on what we want out of this. .env files will be included as well. i think... https://netlify.slack.com/archives/CGW2Y6XPH/p1555104966005100 cc @philhawksworth

related: https://github.com/netlify/netlify-dev-plugin/issues/60

going to be a mess if we have a bunch of different places to include .env files - may need to just recommend a tool like Kent uses

[DavidChouinard]

Just wanted to chime in in support of this. Netlify Dev injecting production keys into development environments is a real liability — we're currently counting on devs to locally override env variables in their .bash_profile but it's not a great solution and one of these days we're scared someone might do something destructive because a production key slipped in :(

I'm sure there's a ton on the roadmap but this would mean a lot to us — thanks for the great work.

[bsgreenb]

Hey there, want to second that I'm afraid to use netlify dev until it can have its own environmental variables.

Also, feel like we should be allowed to build netlify sites with dotenv entirely, hope that's coming soon as well!

[sami616]

Would be great to override env variables specifically when running netlify dev. My use case is connecting to my development database inside a lambda.

Having the option of using a .env file or specific context inside the .toml feels like s nice solution

[fjeddy]

So the only real alternative here is to have duplicate env variables, one for production and one for dev, and then write redundant code to switch between the two depending on what env you're on? :S

It seems odd that this wasn't accounted for when it was made in the first place; I assume very few people use the same variables when developing as live.

[peterjohansson92]

I agree with @fjeddy

I think that all the env-variables that you add should be treated as a secret. Even though you can add different env-variables to the netlify.toml, it still needs to be located in the repository.

You should be able to add different env-setups in the UI (like you can do in the netlify.toml) or somehow be able to inject it from a 3:rd party through a pre-script.

https://daniel-krzyczkowski.github.io/Access-Azure-Key-Vault-secrets-in-the-Azure-DevOps-Release-Pipelines/

https://daniel-krzyczkowski.github.io/How-to-inject-Azure-Key-Vault-secrets-in-the-Azure-DevOps-CICD-pipelines/

[trevorblades]

@sami616 I posted a comment in a different issue about my solution for this problem. In short, I set _DEV and _PROD environment variables in the Netlify interface, and then conditionally use one over the other based on process.env.NETLIFY_DEV, which is true when you're running netlify dev and false when deploying for production/staging.

setClientSecret(
  process.env.NETLIFY_DEV
    ? process.env.CLIENT_SECRET_DEV
    : process.env.CLIENT_SECRET_PROD
);

Hope this helps! 😄

[fjeddy]

@trevorblades This has already been mentioned, and it doesn't. It's just a workaround, a workaround that shouldn't have to be there.