Closed eric-burel closed 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
.
Once this runs, I'm happy to merge in and cut a release.
Published as 0.9.0!
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?