Closes #56
Closes #60 -> doesn't work yet, the db-init service fails if the port is changed
This PR has a few things:
Devcontainers
I wanted to have a working docker-compose.yml file that doesn't have any devcontainer specific setting in it in order to be able to not use vscode devcontainers (I'm not a fan of having the code inside a container, only running the apps in containers is the way IMHO & and I prefer using my own vscode setup).
The second compose file (docker-compose.workspace.yml) is the one that runs a service that has the code, and it is the service specified in devcontainer.json.
Another issue with devcontainers is that it seems like we can't specify build args for compose files (only for dockerfiles). This means that to have the env vars during build time, we need to rely on the default behaviour that uses a .env file next to the compose files... So unfortunately the multiple env magic won't work with devcontainers.
Right now the devcontainer starts and you can access swagger in your browser. The hot reload should also be working. I saw some biome related errors and some elysia linting errors in the code, the devcontainer config should probably be changed to fix these. I'll look into it later
Env files
I moved the env files into a separate environments folder and split them. This way the DB won't have the app secrets at any point. Not a big deal in our case, but it was an easy change to make it a bit better. This might've broke the .local env logic that you created, LMK what you think about it
DB init step
To avoid relying on magic .sh scripts I just added a separate service that runs after the DB is up (db-init). It does the migrations & seeding, then exits. Then the app itself only starts when this init service completed.
Closes #56 Closes #60 -> doesn't work yet, the
db-initservice fails if the port is changedThis PR has a few things:
Devcontainers
I wanted to have a working docker-compose.yml file that doesn't have any devcontainer specific setting in it in order to be able to not use vscode devcontainers (I'm not a fan of having the code inside a container, only running the apps in containers is the way IMHO & and I prefer using my own vscode setup).
The second compose file (
docker-compose.workspace.yml) is the one that runs a service that has the code, and it is the service specified in devcontainer.json.Another issue with devcontainers is that it seems like we can't specify build args for compose files (only for dockerfiles). This means that to have the env vars during build time, we need to rely on the default behaviour that uses a .env file next to the compose files... So unfortunately the multiple env magic won't work with devcontainers.
Right now the devcontainer starts and you can access swagger in your browser. The hot reload should also be working. I saw some biome related errors and some elysia linting errors in the code, the devcontainer config should probably be changed to fix these. I'll look into it later
Env files
I moved the env files into a separate environments folder and split them. This way the DB won't have the app secrets at any point. Not a big deal in our case, but it was an easy change to make it a bit better. This might've broke the .local env logic that you created, LMK what you think about it
DB init step
To avoid relying on magic .sh scripts I just added a separate service that runs after the DB is up (
db-init). It does the migrations & seeding, then exits. Then the app itself only starts when this init service completed.