Dotenv is definitely something that should not exist.
Direnv is the right way to go if you want a tool for this. Otherwise dotenv's implementation in bash is essentially `set -a; source .env`. Look ma, no custom parser!
Seems really silly to have a library do what two lines of shell can reasonably accomplish.
Comments
Dotenv is definitely something that should not exist.
Direnv is the right way to go if you want a tool for this. Otherwise dotenv's implementation in bash is essentially `set -a; source .env`. Look ma, no custom parser!
Seems really silly to have a library do what two lines of shell can reasonably accomplish.
Interestingly, using source would have the same "bug" as TFA mentions.
Though the obvious fix is to use single quotes in the .env file.
That's not what the agent suggested. The user asked for a fix, and I guess the AI blindly complied.
That shell snippet will expand shell variables in double-quote strings. And apparently the entire reason for this fork is to not do that.
Which is dumb. The canonical spec for .env should just be "whatever POSIX sh does."
Agree, not expanding is dumb.
One of the major benefits of a shell-based approach is your env vars could be generated from the output of a command.
Which can be trivially used to populate secrets from whatever your secret store of choice is.
Now we've also cleanly solved secret distribution for developers with one less dependency!