I have a similar use-case to the issue mentioned in #10 and in an effort to reduce additional dependences, such as env-cmd, opted to alter this code to provide a "non-strict" option to production builds.
I've added a boolean flag "--strict" or "-s" to allow production builds to use the default values provided in the .env file.
I believe this adds two key uses:
The option to default to existing values in cases where that variable may not always be provided
The ability to specify environmental variable overrides of the .env for local runs, and observe the effect in a development build.
I also added in a test for a line in production builds that was previously uncovered.
Fixes #10
I have a similar use-case to the issue mentioned in #10 and in an effort to reduce additional dependences, such as env-cmd, opted to alter this code to provide a "non-strict" option to production builds. I've added a boolean flag "--strict" or "-s" to allow production builds to use the default values provided in the
.env
file.I believe this adds two key uses:
I also added in a test for a line in production builds that was previously uncovered.