New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
suggestion: simplify load()
from std/dotenv
#4578
Comments
Can you elaborate on this?
Can you elaborate on this? What's the main differences?
Why remove all options? I saw some complaints about handling of
Sounds like unnecessary breaking change to me. |
Some aspects of
Mostly, not throwing when a
It doesn't have to go that far. Perhaps removing
It provides feedback on whether a |
I agree with items 1 and 4.
If we can't reach consensus about this, we could instead keep all options, just remove their defaults ".env.example" and ".env.defaults" so that it's mandatory to specify the filenames if you want to load them.
Currently it returns the parsed object, which is useful. If we make that change, it will be necessary to call One of the reasons why |
I still don't get
To my understanding
In what cases |
The design of
load()
fromstd/dotenv
has been a source of pain for some users (see references). It does much more than it should, such as checking for required environment variables and defining default values. #4019 explored the option of deprecating this API in favor of the new--env
CLI flag. IMO,--env
is undoubtedly superior toload()
for a few reasons. However, there may be cases when a user wants to load a.env
file programmatically.I suggest making the following breaking changes to
load()
instd/dotenv@1
:--env
..env.default
and.env.example
options..env
file exists but is invalid.References:
std/env
withassertEnvSet()
andsetEnvDefault()
#3874load.ts
andmod.ts
when used together withrun --watch=
#2490The text was updated successfully, but these errors were encountered: