kurtbuilds / modenv

A CLI to easily manage .env files and keep them consistent. It is simple, fast, error resistant, and composable.
MIT License
56 stars 2 forks source link

Generate files only when necessary #5

Closed eric-burel closed 2 years ago

eric-burel commented 2 years ago

Hi, Some frameworks like Next.js are expected to have weird conventions. In Next (v12.3 at the time of writing), ".env", ".env.development", ".env.production" and ".env.test" are tracked files, and ".env.local" are untracked* files.

Currently, "modenv" will generate ".env.production" and ".env.example" if they do not exists, but these files do not make sense in Next.js (and maybe other frameworks).

So what I propose:

Specific scenario: In Next.js for instance, ".env"/".env.local" are equivalent to ".env.example"/".env" in other projects. In Remix, the initalization is handled by a custom script specific to each stack, so we don't need modenv eitther. Normal scenario: It will still work for other projects where there is no ".env" set as a default or just a ".env.example" the normal workflow happens, generating ".env", ".env.example" and ".env.production"

A small thing that bugged me: the code is different for generating ".env" or ".env.production" based on ".env.example", why? It seems the logic is the same but you use 2 different way, the ".env.production" code is terser.

Another Rust related thing: do you use &str or &'static str for global string values?

kurtbuilds commented 2 years ago

This sounds pretty reasonable to me.

It's a &'static str, but it's fine to elide the 'static.

The idea for the differing behavior between populating .env versus .env.production is that in my usage, I'll sometimes keep .env.example populated with default values, e.g. PORT=5000 HOST=0.0.0.0, but I don't necessarily want those to populate by default into .env.production.

kurtbuilds commented 2 years ago

Once this runs, I'm happy to merge in and cut a release.

kurtbuilds commented 2 years ago

Published as 0.9.0!