The concept is fine, but I'm a big fan of doing it with mise instead. It does the exact same thing plus a lot of other things really well. The environment for a project is not just things that get stored in environment variables, it also includes specific versions of tools, common project tasks, git hooks and such. Being able to manage all of that in one place ends up being really useful.

I also really like that for sensitive variables (AWS tokens, prod DB passwords, etc), I can keep those in a dedicated secret store (I use 1Password for personal projects and there are more enterprise focused alternatives for work).

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.

No, I also use direnv. It does everything I want, nothing I don't, and has been stable for me for years.

A bonus is that with that approach, you actually have real environment variables.

direnv + nix flakes solved so many problems for me, I have no idea how other people work on multiple projects at the same time without getting mixed up.

I also used to use direnv (and likewise eschewed .env), but more recently I moved env definitions to mise. Been working out nicely.

I use Mise for env. I primarily use it for installing tools and running tasks, having env support is just a cherry on top.

Direnv's first stable release was in 2013, .env was 2012 (adopted by Heroku).

So no, if anything direnv makes you hip and edgy.

I think there are two separate concerns here. The idea that long lived secrets survive in plaintext on a disk somewhere is a bad idea that should go away, but also tangential to that people have to have good hygiene around not printing evil things to logs. Latter is a lot harder to catch imo, and is a separate problem

> the guard over the missile launch switch

That's called a molly guard, but also a Debian package that asks you before you run shutdown if you're on the server you intended to shut down.

well mise uses dotenvy right now (for env._file anyhow), it may be worth switching to dotenv-ng but I haven't looked into it yet https://github.com/jdx/mise/blob/fc441787fe52b46be1245046758...

I assume you just mean normal [env] in mise.toml which is different, but this still is relevant to mise

I came in and thought it had something to do with Angular since `ng` is a popular pre/post-fix for Angular libraries.

Probably next generation.

Next generation I guess.

.env is self sustaining at this point. The functionality described in the post exists to help move people off of it. It’ll have a better chance of dying when fewer people use it and that starts with making it easy to move away from it.

It’s an open source project, so you don’t have to wish it.

“Hey dotenvy team, I’m a fan of your project and wanted to help out. I noticed that some of your announcements are AI generated, and would like to help bring back the human voice. I’ll be happy to proof read and/or write your blog posts and release announcements in the future. Let me know if this is something you could use.”