The .env File Nobody Needs
vivianvoss.net
vivianvoss.net
I think it falls short in meeting people where they are when they use env files. I appreciate the section at the end that says "if you must use dotenv files", but surely there's gotta be a middle ground where you can still leverage the OS and not lose out on convenience.
I think it could even look like an npm package that helps you set up the service correctly for local development, accounting for the reality that there is likely several projects on a developer's machine and some of these projects are there temporarily.
* of course, there's still all that stuff about environment variables being visible to other processes, so we still need decent runtime infrastructure for envvars like `DATABASE_URL_FILE`, a temporary file where the application can read the secret at runtime. I'd love to see that in Node instead of the `env-file`
Where .env files shine is that: - they act as a declaration of expected environment variables, - they are project-scoped, which is one big issue with using "/etc" for example
I personally like to set a .env.example for my collaborators to know what's expected, and I use a .envrc with direnv. And to make it more secure, I always have .envrc in my global gitignore so I can't just forget it.
The drawback is that for any non-interactive run (debugger) I have to manually add each variable each time.
And that we shouldn't need to download something like dotenv to address something the operating system should handle.