Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #56
Closes #60 -> doesn't work yet, the
db-init
service 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.