feat: Load .env.*.local envs

[danilofuchs]

Closes #54 (allows local env files)
Addresses #29 (allows config.path to be an array)

My approach automatically resolves env files in the following order (forked from create-react-app):

• .env: Default.
• .env.local: Local overrides. This file is loaded for all environments except test.
• .env.development, .env.test, .env.production: Environment-specific settings.
• .env.development.local, .env.test.local, .env.production.local: Local overrides of environment-specific settings.

Users are advised to commit .env* to their repos, except for .env.*.local.

This, however, introduces a breaking change, since .env file will always be loaded in any environment.

I can enable this feature behind a flag, if you think it's a safer option.

[kbsanders]

This would be super useful to have for local development with serverless-offline as that plugin no longer automatically sets an IS_OFFLINE=true env variable (That feature was removed, for whatever reason).

dherault/serverless-offline#959
dherault/serverless-offline#768

So being able to set it manually in a .env.local file that doesn't get committed to the repo would be perfect.

[colynb]

hi @danilofuchs. I’m not that familiar with the CRA recommendations and it seems counter intuitive to me though I looked into it. I’m not wrapping my head around the benefits but it seems most of the purported benefits have to do with client side app bundling. For serverless apps I’m not seeing where there would be similar benefits but rather see that as highly insecure. I apologize for not understanding but can you clear this up more for me? Thanks.

[danilofuchs]

User Story

As a developer working on a project with my team of 5 developers, I share common development envs, such as endpoint URLs, non-sensitive configuration data for a third party integration and default feature toggles in an .env.development file, which is automatically loaded on my dev environment. I want to be able to override this values to test code behaviour locally, such as using a different port on my dev server or enabling a feature toggle without risking commiting these specific configs and changing the behaviour for all my peers.

---

My own use case

I need to set some shared (commited) env vars in a .env or .env.development file, such as endpoint URLs, IS_OFFLINE, TZ, etc.

In this file, I do not commit any credentials. However, when working locally some things must be overwritten. For instance, I need to change the port of a local server endpoint as it conflicts with other projects only I use on my machine.

I store all production credentials on SSM. But, they are not available on a local environment. It is possible to default the credentials to a env value, but it is unwise to commit these credentials to .env.development, as every one would have access to it on the repo.

The current alternative is to not commit and .env file at all, but then I loose the ability to share common configurations which everyone will need.

---

it seems most of the purported benefits have to do with client side app bundling

This approach was actually first proposed and addopted in Rails, a monolithic server-side framework.

but rather see that as highly insecure

My use case states that credentials are not commited to the repo. This is exactly why .local files are interesting, as they allow users to commit .env.* files without fear, as all credentials are solely stored on their .env.*.local files

---

I agree this may not be the usual way of handling envs, and as such I think it is fair to put this feature behind a flag or enable it via the paths parameter. We can discuss how to better conciliate this behaviour.

I hope I made myself clear!

[colynb]

I think I'm starting to get it knowing that I often struggle with the same thing. Project variables are split between secrets and general configuration, especially for local development. The standard convention has been to put both inside a single env file that does not get committed. There needs to be a way to commit env files for config/non-secret variables and exclude env files for secrets only. Basically, you need to parse two env files instead of one. The dotenv library does not really have a way to parse multiple env files but your code change maps over the available files then use dotenv to parse each of them one at a time. Would you mind setting up an example app in the PR under the examples folder that demonstrates what files will get committed and which ones will not?

[colynb]

I think the thing that is tripping me up is the naming convention of the files. The .local is confusing to me. I always think of "local" as in local development server or localhost. At any rate, I'm thinking there is a way to not need a feature flag. It seems like the "resolveEnvFileNames" handles either a single env file or multiple files. I'm not sure how this could be a breaking change.

[danilofuchs]

I believe this could be a breaking change since it always loads the .env file, regardless of stage. But this may be not of huge concern, since as it currently only loads the .env.STAGE file, users probably do not have a .env file anyway

[danilofuchs]

I think the thing that is tripping me up is the naming convention of the files. The .local is confusing to me. I always think of "local" as in local development server or localhost.

I totally get what you mean.

I think that, as this is the standard approach on other widely used libs, I would rather keep it consistent.

What do you propose as an alternative?

[danilofuchs]

Apparently, Symfony and Vue CLI also adopt the same approach

https://symfony.com/doc/current/configuration/dot-env-changes.html

https://cli.vuejs.org/guide/mode-and-env.html

[colynb]

What do you propose as an alternative?

I wasn't suggesting an alternative. I definitely prefer to stick to community conventions.

[dekked]

It looks like next.js has recently adopted the same convention, too.

[danilofuchs]

@colynb can we move along with this PR? You mentioned I could create an example app, but honestly I don't know the best way to show the user which files must be commited if I need to commit the example to this repo.

I could write a Readme inside the example folder and commit the .local files with comments stating these files should be in gitignore...

[danilofuchs]

Note: This will conflict with the changes in #48

[colynb]

@colynb can we move along with this PR? You mentioned I could create an example app, but honestly I don't know the best way to show the user which files must be commited if I need to commit the example to this repo.

I could write a Readme inside the example folder and commit the .local files with comments stating these files should be in gitignore...

That's ok. I can take care of this release but probably not until this weekend. I do think it's an important release so know that I will not drop it. Also, I think it is more important than the changes in #48 which I will do after this one. Thanks for your patience.

[flybayer]

Ah yes, this will be super helpful!

[randytarampi]

Respectfully bumping this again

I'm going live with something next week and would love to get off @danilofuchs's branch and back onto the mainline before that happens – is there anything the community can help with? 🙏

[colynb]

@danilofuchs would you have some time today to pair program with me to get this released? I could really use a 2nd pair of eyes.

https://calendly.com/infrontlabs/openhours

[danilofuchs]

@danilofuchs would you have some time today to pair program with me to get this released? I could really use a 2nd pair of eyes.

Sure thing!

[colynb]

@danilofuchs THANK YOU for your help, I'm really glad we did the call!

[danilofuchs]

@danilofuchs THANK YOU for your help, I'm really glad we did the call!

Really happy to be able to contribute! Keep up with the great work, the open source community grows a lot when people take their time to make projects go forward. 🚀

[colynb]

I published version 3.0 to npm :-D I also created a new page on my site for the changelog. https://colyn.dev/serverless-dotenv-plugin-changelog/

…

On Fri, Jul 24, 2020 at 4:50 PM Danilo Campana Fuchs < ***@***.***> wrote: @danilofuchs <https://github.com/danilofuchs> *THANK YOU* for your help, I'm really glad we did the call! Really happy to be able to contribute! Keep up with the great work, the open source community grows a lot when people take their time to make projects go forward. 🚀 — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#55 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIAEJFPHJMT3BLR3Q2JTELR5IM5HANCNFSM4ML4JZ5A> .

--

--- *"A man who dares to waste one hour of time has not discovered the value of life." -- **Charles Darwin*