phpdotenv: .env containing duplicates provides confusing outcome
Hello! Thanks for your library - it’s very helpful.
I recently came across a confusing situation, where I had inadvertently set the same variable twice in a .env file with different values (as part of a Laravel deployment).
Example:
APP_DEBUG=false
....
APP_DEBUG=true
Results in APP_DEBUG=false after loading.
I totally realize that it’s my responsibility to ensure that I’m not setting these twice, however I was surprised that there wasn’t something that would either warn me about a duplicate, or use the last-set value, since it was set later?
Is this something that should be handled in the library? I couldn’t find an associated test that expresses this concept.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 28
The last value should always be used.
There should NOT be a crash.
This is how exported bash variables work, which is what this project aims to mimic, and it’s the behavior pattern most expected by end-devs.
If this is to emulate shell Environment varialbes, so that one can do
. .env; mysql -u $DB_USER --password=$DB_PASSand easily load into docker environment variables, then you should strive for bash compatibility, which means that the last overwrites former.If this project’s goal is NOT to emulate shell env scripts, then we will have a situation like how the Laravel devs decided, unilaterally, in v5.8 to stop reading the env variables from, you know, the environment. That’s why I created phpexpertsinc/Laravel57-env-polyfill (plus you can now use
env()with vlucas/phpdotenv without needing Laravel).70 million downloads, true, but we are only talking about an extreme edge case here. Variables override is not a common use case for this library.