Enhancement: Implement .env file support for configuration management

[HabeebullahOpe]

Is your feature request related to a problem? Please describe.

While there isn't a specific problem causing frustration, adding support for .env files would significantly enhance the project's configuration management. It would provide a centralized and consistent way to handle environment variables, improve security by keeping sensitive information out of the source code, and offer flexibility in managing different environments (development, testing, production).

Describe the solution you'd like

Implement support for .env files using the dotenv crate. This would involve loading environment variables from a .env file at the start of the application and making them accessible throughout the codebase. The .env file would be added to .gitignore to prevent sensitive information from being committed to version control. Additionally, the documentation would be updated to include instructions on how to set up and use the .env file.

Describe alternatives you've considered

Alternatives could include manually setting environment variables in the terminal or using configuration files specific to each environment. However, these approaches may lack the simplicity, security, and ease of use that .env files provide.

Additional context

Adding .env file support will improve the development process, make it easier for new contributors to get started, and enhance the overall maintainability of the project. It aligns with best practices for managing configuration settings and ensures a more secure and flexible setup.

[jacobhq]

We are waiting for the next release of the dotenvy crate, which should happen in April. In the meantime, I will do an implementation just using the dotenvy git repo as a dependency (as seen in allan2/dotenvy#144 (comment)). This will not be merged until the next dotenvy is released because it is bad to depend on a git branch of a project :)

[Valerioageno]

@jacobhq for this case we could consider creating our own implementation. It shouldn't be that hard.

The reason is that we have to keep it in sync with also the frontend part and we are not sure whether it is feasible with dotenvy.

Also we are waiting (after the fix on the tuono new tests we won't wait anymore) dotenvy's release for the compile time .env variables feature that it won't be required for the users app.

[jacobhq]

Ok! Do we just want to implement from scratch then?

[Valerioageno]

I'd investigate how hard it would be doing it from scratch! Then finding the best tradeoff for the implementation

[jacobhq]

@Valerioageno would you mind editing the description to include tasks to keep track of the PRs I will create as mentioned in #581 (comment)?

[Valerioageno]

Don't you have permissions to add sub-tasks?

[jacobhq]

No, only for the documentation repo

[jacobhq]

Do you think this needs an example. The next.js one demonstrates the precedence rules very nicely. If so should we put it in #584, or its own separate PR? Putting it in 584 would make it much easier to write, although I understand it would be a bit harder to review.

[Valerioageno]

Nice catch. I'd put the .env file on each example. Just to let users now by default. (fifth task 😄 )

[jacobhq]

I think maybe we should add it to the tutorial, but I don't think it needs to necessarily be added to all the examples. I do quite like the idea of a stand alone one to demonstrate precedence, but that would also be covered in the docs. WDYT?

[Valerioageno]

Most likely, any project is going to have shared configuration. Also existing frameworks like Next.js or Laravel have them by default

[jacobhq]

Fair point - let's do it then. I think a dedicated example would also be valuable to demonstrate precedence.

[Valerioageno]

Examples are for having templates for tuono new command. The more examples we have, the more maintenance cost they require. The least the best IMHO

[jacobhq]

Alright. If we write good docs, I don't think we'll need it :)

[allan2]

dotenvy maintainer here. Might I suggest using dotenvy 0.15.7? It's quite popular. You could switch to 0.16 eventually, which will be breaking, but it shouldn't be too difficult to migrate to since it's a small library.

The reason is that we have to keep it in sync with also the frontend part and we are not sure whether it is feasible with dotenvy.

I don't see this would have anything to do with your frontend, unless your frontend is WASM, which wouldn't have an environment anyway. One of the goals of dotenvy is to maintain compatibility with the popular implementations in other languages.

[Valerioageno]

Hey @allan2, thanks for joining the discussion!

The rationales behind using a custom solution are basically three:

• Avoid increasing the number of dependencies
• It is a quite easy implementation
• Need to match vite env logic (not sude dotenvy matches that)

If you have suggestions, we are all ears :)

[allan2]

Sure, you can roll your own if you prefer. I don't know what sort of "env logic" you are referring to.

[jacobhq]

Hi Allan, (I think) Valerio is talking about the logic around getting env vars from multiple files (eg .env, .env.local, .env.production etc). We have specific requirements, namely the fact that the order in which these files are applied must be exactly the same as vite to match how things work on the frontend side.

Hope that makes a bit of sense!