Manage env files (enhancement)

[eric-burel]

Since you are interested in dotenv files, I have some pain points with .env that could be adressed by a CLI tool.

Namely, I need to switch easily between a laptop and a desktop. And I have an app to maintain that is structured as a monorepo, so 2 APIs, a result app, a Next.js app. Next.js itself also generates lots of .env files for configuration (.env, .env.local, .env.development, .env.test...).

Keeping .env in sync is a pain. So I wonder if it would be possible to add a command that ties a local .env file, to another folder on disk. Typically, I would have a ~/Dropbox/env_files folder, or at least a ~/.env_files in the home, with subfolders per project. You could set that up once modenv init-backup ~/Dropbox/env_files [project-name] (and the current folder could be used as the project name if no project-name is provided).

Then modenv save would copy my local .env towards the home folder, and modenv update could do the opposite, updating the current folder .env based on the home folder.

The underlying issue is that .env are strongly tied to living in a local folder, but are hidden files, which makes them untrackable but also hard to backup. This could extend to backing up to cloud services in the future, the idea is the same: easily get the latest .env, easily save the modification you've made, to the cloud or to a local home folder.

Maybe this exists already? Is that something you'd like to see added in "modenv"? I am learning Rust and I would really like to contribute to something actually useful in order to progress.

Related: https://github.com/dotenv-org/dotenv-vault But I don't like those products that hosts secrets, I'd rather keep the secrets in my personal dropbox/gcloud instead of involving yet another service. I could even encrypt the file when storing it outside of the local folder.

Antoher alternative: https://www.doppler.com/ It seems to rely on injecting the environment variable (run a "doppler" command before running any other command) instead of .env files.

[kurtbuilds]

This is a cool idea. A few thoughts:

• It might be nice to have it take a url, so you could do: modenv push file://path/to/dropbox/folder, but also support other services, e.g. modenv push doppler://doppler/schema/means/we/can/talk/to/doppler/api
• Where does init-backup store the information for where the backup is saved? In the .env file?

When I needed to ship dotfiles to a friend, I ended up running this command: tar cz $(fd -IH "^.env($|\.)") > dotfiles.tar.gz, followed by tar xzvf dotfiles.tar.gz in the destination folder. Wanted to bring up a related use case in case there's opportunity to solve more than one problem at once.

Happy to review PRs, continue discussion about architecture, or answer questions about implementation.

[eric-burel]

I guess it would be stored in a "modenv" specific config file, like most tools do (at least in the JS ecosystem) The URL could be part of the config, like you define it once during init and then just call "modenv push", with maybe optional params to override the usual URL (eg make a one-off backup). The problem is that each service probably has its own format so you'd need to configure the "doppler" service instead of just providing a URL.

I'll give a shot at Doppler and then add this to my "Rust to-do list" (alongside learning Tauri, Deno and reading tons of docs :))