feat: support bun-like .env hierarchy in docker compose

[yamcodes]

The Bun .env hierarchy supports defining .env.local files to take precedence over the .env file in order to locally customize environment variables.

In our use case, this is useful for defining a different POSTGRES_PORT in case 5432 is already used by another connection.

This way, we can keep .env source controlled for example purposes and allow people to customize it by duplicating the file, renaming to .env.local and assigning different values. The resulted file will not be in source control.

This PR adds the same level of support to docker-compose which doesn't officially support .env hierarchy.

Now you just need to run bun db:up and it will spin up the Postgres docker container with .env as a default or with .env.local if you have one instead.

[Hajbo]

I feel like we should put the webservice into a container too. Also, is there a way to specify the switches in the bun:db command? E.g. I would generally dislike using -d, but others tend to prefer it

Regarding the .env file hierarchy, I don't think it's particularly needed. You'd only use docker compose locally, I don't think there are cases where you'd switch envs like that during development. Nevertheless, they are super useful during deployments

[Hajbo]

Accidentally closed it...

[yamcodes]

I feel like we should put the webservice into a container too.

Sure, 100%, I opened an issue for this in #41.

[yamcodes]

Also, is there a way to specify the switches in the bun:db command? E.g. I would generally dislike using -d, but others tend to prefer it

Yes bun db:up -d will work after removing -d from the package.json script, sorry. Just tested it. The npm equivalent is npm run db:up -- -d. Bun is fun!

---

Edit: sorry, tested this on a branch without the .sh script. In this case I need to propagate the params. Fixed here.

[yamcodes]

Regarding the .env file hierarchy, I don't think it's particularly needed. You'd only use docker compose locally, I don't think there are cases where you'd switch envs like that during development. Nevertheless, they are super useful during deployments

Right now I can't spin up the db server because I have another connection running on port 5432 (the work one). I have to close it in order to develop this project and go back and forth.

Sure, I can simply change the POSTGRES_PORT in .env but that's source controlled so it's just another overhead to exclude when committing things, also I might accidentally commit it

IMO, the simplest solution is to add support for a .env.local file and then I can use my own environment variables freely.

[Hajbo]

Regarding the .env file hierarchy, I don't think it's particularly needed. You'd only use docker compose locally, I don't think there are cases where you'd switch envs like that during development. Nevertheless, they are super useful during deployments

Right now I can't spin up the db server because I have another connection running on port 5432 (the work one). I have to close it in order to develop this project and go back and forth.

Sure, I can simply change the POSTGRES_PORT in .env but that's source controlled so it's just another overhead to exclude when committing things, also I might accidentally commit it

IMO, the simplest solution is to add support for a .env.local file and then I can use my own environment variables freely.

Makes sense 🙌