feature: Allow overriding with other env files #44
Conversation
e-e
changed the title
renaming and additional readme revert pubspec.lock changes increment minor version level
|
Thanks for the PR just a note to say aware it's open and will make time to review and see how this aligns with larger .env libraries in regards to usage |
|
Hey @java-james. No pressure on the PR, but just wanted to report back that we are currently successfully using this addition in our app |
|
This would be so good to have! |
|
@e-e are you interested and available to update this PR to resolve existing conflicts? |
|
Would be really nice to have it to work! |
|
@java-james Hey! I won't have time to look at this for the foreseeable future, so if someone else wants to take it on by all means |
|
@java-james @e-e I think I've fixed the conflicts. What's the best way to send the fixes up? |
|
do you want to open a pull request against my fork? |
Update with upstream
|
@java-james sorry for the delay. Thanks to @StephenBrough the conflicts have been resolved |
|
Beauty, thanks. I will get this reviewed. |
|
I have reviewed this PR and am happy with the additional feature. Agree that it's an additional useful way to load/compose your env variables. edit: I was able to resolve the conflict in browser :) Waiting for workflows to run now |
|
Merged. Thanks for the contribution |
4 participants
Instead of managing multiple env files with duplicate data, this adds a way to provide additional env files to use as overrides. The idea here being that there would be a "base" env file, and then environment-specific env files which would override a subset of the base env file values.
There were some auto-formatting changes, but I tried to run them against
dartfmtand it said there were no changes to be made 🤷