⚠️ Warning: Project archived! Due to lack of time, I was not able to continue working on this project 😔
It served mainly as a playground to test ReasonML both on the FE & BE, but ultimately it was taking too much time and I'd like to shift my focus on different stuff.
Feel free to ping me if you think the development should resume.
- vscode editor
- vscode remote-containers extension
- Windows: Docker Desktop 2.0+ on Windows 10 Pro/Enterprise. (Docker Toolbox is not supported. Windows container images are not supported.)
- macOS: Docker Desktop 2.0+.
- Linux: Docker CE/EE 18.06+ and Docker Compose 1.21+. (The Ubuntu snap package is not supported.)
The issue behind the choice of choosing vscode editor as a requirement is that reasonML intellisense and warning / error display (in editor) uses artifacts generated by the bucklescript compiler.
Since the bucklescript compiler runs and generates artifacts inside a docker container, it's not possible to get the features described above to work correctly.
The solution right now is to use an extension like remote-containers, which allows you to use a Docker container as a full-featured development environment.
This means that you will get access to the filesystem inside the container, with an already-defined set of vscode extensions.
Further documentation about remote-container extension
Further documentation about remote-container in a monorepo
The steps required to start the remote-container extension for a specific module are:
- open the action menu (cmd + shift + p on macOs)
- select Remote-Containers: Open Folder in Container
- select the module folder (i.e. web)
Here's a demo:
- the 1st time (only) that you run this, it will take a LOT of time, since it will create the docker images for all the services and spawn containers from them
- containers don't stop automatically after closing vscode editor - this can be easily done through
docker container stop [CONTAINER_ID]
though
All the services logs can be checked through docker logs --follow [CONTAINER_ID]
. Container ids can be retrieved through
docker ps
(useful to debug bsb / gatsby / nodemon issues)
Single module-related documentation:
Continuous delivery is managed through google cloudbuild.
Commits on master will thus automatically trigger a build => test => deploy pipeline.
There are 2 kind of cloudbuild pipeline triggers implemented:
- module-specific trigger: when an update to a specific module is detected, the correlated specific module pipeline will trigger - no deploy pipeline will be triggered when no change is detected
- base-image trigger: when an update to the base Dockerfile is detected, the build & push base image pipeline will be triggered
The bsb compiler/gatsby is no longer working correctly and needs to be restarted
In order to restart bsb, close vscode, stop the container through docker container stop [CONTAINER_ID]
, and restart vscode through the method described above.
This will restart the container correctly, and will probably fix your issue.