Add ability to shut off dotenv invocation

[gfmartinez]

So, this might be the wrong way to go about doing this, but I've run into two major issues in dealing with this dotenv wrapper for Ember:

1. When deploying to production in Heroku, the warnings can be confusing and alarming, when they really are meaning less because the environment variables are actually set within the Heroku environment; and

2. Sometimes the invocation of dotenv and the errors can cause build errors.

So, I've attempted to add the ability for users to bypass the use of dotenv in certain environments.

It seems there may be some consensus that dotenv should only be used for development (https://stackoverflow.com/questions/52546426/is-module-dotenv-for-development-only), but either way, giving control over the use to developers makes sense.

Happy to re-work, delete, or whatever seems appropriate.

Thanks!

[jasonmit]

What are your thoughts on renaming this to enabled?

[gfmartinez]

@jasonmit That sounds fine to me. Will update and push up shortly.

[andrejcremoznik]

This definitely needs to be merged. A missing .env file should be silently ignored. It's up to the devs to configure the env via env vars or dotenv. As it is currently, devs are forced into a .env file. That's just not how apps run in production or CI environments.

Edit: actually, this change isn't good enough. You shouldn't have to configure whether it's enabled or not when you can interpret that condition from the presence or absence of the .env file.

[jasonmit]

Part of v3.1.0, thanks

[jasonmit]

@andrejcremoznik feel free to submit a PR. I'm fine with this PR going in as-is since it's simply adding behavior to toggle the addon on and off.

[gfmartinez]

@jasonmit thanks for the merge. Glad to help out! Psyched for the changes.
@andrejcremoznik explicitly enabling or disabling gives the developer conditional control, whereas deriving use based on presence could allow for a failed build. I know several folks that use a .env file in their production build. If for some reason that file was missing in the build and they were expecting it to be there, the warnings would be helpful. If you go down that path, I'd just be sure to consider that use case, so that the app can Expect an .env file...