4 ms·
Or we need to collectively stop using dotenv in favor of other, more formal formats like TOML.
by RussianCow 3y ago
Or we need to collectively stop using dotenv in favor of other, more formal formats like TOML.
- hotnfresh 3y agoIf you’re ultimately going to be reading actual env vars, the nice things that toml gives you won’t be there, and having used it as a crutch may leave you with bugs. If you’re reading env as input, eat the pain early or eat it later. If you’re not ultimately going to be reading actual env vars, then yeah—why even consider .env in the first place? Of course don’t use it.
- RussianCow 3y ago> If you’re ultimately going to be reading actual env vars I would argue that most of the time, you don't need to do this in the first place. Far too often people shoehorn things into environment variables that really shouldn't live there, like secrets and app configuration. If you're interfacing with existing software that reads from the environment, obviously you don't have control over that, so using a different format is out of the question (unless you're willing to convert it to env vars at runtime, but that sounds like more effort than it's worth).
- arielcostas 3y agoI like ASP.NET Core approach of having an `appsettings.json` where you just specify your settings, and also allowing to have `user-secrets` on a different directory, which prevents you from accidentally adding it to source control (which happens way more than it should). Of course, you can also use environment variables, but creating a JSON file that allows nesting properties is quite nice and probably easier for noobs than figuring out each .env implementation's quirks.