For a while I’ve noticed that many people use dotenv in a suboptimal way, so yesterday I took the time to write a short article about better usage patterns (pretty basic stuff, so if you are an expert it’s likely that you will find it boring):
For a while I’ve noticed that many people use dotenv in a suboptimal way, so yesterday I took the time to write a short article about better usage patterns (pretty basic stuff, so if you are an expert it’s likely that you will find it boring):
My biggest gripe with the dotenv pattern is people treating it like a configuration file. If you want a configuration file, just use JSON/YAML/INI/XML. A lot of the implementations now try to add “improvements” to the format that makes them now not always reliably compatible with just sourcing them in bash, or as Docker environment file, which just kind of defeats the purpose?
I’m also not sure what’s so hard to just… source the
.envfile before you run your app.It is a quality of life improvement - maybe a minor one but it is an improvement. I think small quality of life improvements are important, as the fewer of them you have the bigger the problem as a whole they become.
That said, I think .env files are the wrong solution to the problem at hand. As you said, configuration files are the better way to solve this specific problem.
Sourcing the
.envrequires extra knowledge about shell scripting (even if it’s basic knowledge, not everyone has it).On the other hand, not all shells are POSIX compatible (for example, PowerShell in Windows), so if we want to make a cross-platform solution, it becomes a bit more complicated (and also requires more knowledge than the previous case).
Regarding what you commented about those incompatible “improvements”, I understand what you mean, but until now I didn’t find any case of this (so far, variable expansion is a native functionality of most shells nowadays).