Suggestions to .env files

[KinyaElGrande]

1. Will you kindly update your readme and include how to run your first application
2. Is it possible to have the .env ignorable and having like another file like the way Laravel does it with .env.example

[reindert-vetter]

1. I will indeed describe that more clearly.
2. Would you like to describe better when and how you use it. I never really thought it necessary how Laravel does that. But maybe I don't understand the use cases well enough.

[binary-vision]

A bit of unbiased input on my experience of .env files. Personally I almost always use docker for dev and live so env vars can be set via the compose/stack configs, so not sure the .env file approach is a requirement, but understand there are benefits.

• .env is gitegnored to ensure that no sensative information is stored in GIT.
• .env.example contains a full list of environment valiables which can be set. this can be used as a bases for the .env used for local dev.
• .env.testing is used for any env vars used during unit testing
• .env.dusk is for env vars set suring dusk test runs - probably not applicable to this project.
• Unique .env files are created for each deployed environment e.g. production/staging at point of deployment. when deploying laravel using docker stcks, the .env file is deployed using data stored in a docker secret.

Let me know if i can be of any more help - or if im not helping at all :)

[reindert-vetter]

@binary-vision @KinyaElGrande Thanks for your explanation. I don't know yet what will determine which file to use. I first assumed that a user would rename .env.testing to .env if the user needs it.

For example, if the application finds out that tests are running, it is already too late (to suddenly choose .env.testing). Then the files have already been loaded and the configuration has been set up.

Perhaps it is good to be able to give a flag to the CLI to determine which environment file to use. Would that be a solution?

[binary-vision]

I guess it depends what you are trying to achieve/solve.
All projects that I work on have a bash script which is called to perform any actions. The new sail addition to Laravel works in a very similar way.
so if you want to run tests, you just run ./scriptname test and the script runs anything required. This removes any complexity if you have multiple docker-compose files or just different containers for different things for example.
It also means that all projects are uniform when it comes to the cli side of things.

Have you thought about utilising makefiles for example?

[reindert-vetter]

@binary-vision Makefiles can be very useful indeed. If Confetti offers more options that cannot be available in the standard CLI tool, I will certainly consider makefiles.

@KinyaElGrande I am now going to program that you can determine with a parameter which env file should be loaded.

[reindert-vetter]

Done: 🎊

With command flag --env-file you can define a path for your env file: go run . app:serve --env-file ".env.testing"