January: 21

Notes

2024

2:40pm - Food

Food

Went on a sleepless adventure to restock my empty fridge, the lack of healthy food in my diet and the overall lack of sleep are both a dangerous combo. My heart is wondering why I am running on red bull, like a college frat boy, I can tell I am getting old lmfao.

4:29pm - Nx

Nx

I have to go back and update the Nx Run commands for the Rust WASM, the two commands were the trunksetup and the trunkdeploy. There is also another issue that we might have to tackle and that is the nx migration to version 17.3.0, which is currently in beta right now.

6:01pm - TrunkSetup

TrunkSetup

The first of the nx command would be the trunksetup, here is the json for the nx command to help setup and run the command.

    "trunksetup": {
        "executor": "nx:run-commands",
        "options": {
            "commands": [
            "rustup update",
            "sudo apt-get install -y libxcb-render0-dev libxcb-shape0-dev libxcb-xfixes0-dev libxkbcommon-dev libssl-dev",
            "rustup target add wasm32-unknown-unknown",
            "cargo install --locked trunk"
            ],
            "parallel": false
        }

    }

The executor will be nx:run-commands and then followed by the commands, which would setup the environment for the trunk to build the wasm. Finally, we set the parallel to false, to keep the commands linear, which would take a bit more time but it would help dismiss errors. If we wanted to set the parallel to true, then we would have to further split the commands.

Next I am going to split the trunkdeploy into two commands, one being the trunkserve and the other trunkrelease. This is just to avoid any confusion and making it easier to do developement and production cycles.

The trunkserve would be an easy nx run command.

    "trunkserve": {
        "executor": "nx:run-commands",
        "options": {
            "cwd": "apps/rust_wasm_embed",
            "commands": [
            "trunk serve"
            ],
            "parallel": false
        }
    }

Just a quick note, we have to cwd to the root of the project.

Finally, we would add the trunkrelease, which will build the wasm and prepare the WASM and hash files for us to use. Here we will just copy over the trunkserve and rename the serve with the release.

    "trunkrelease": {
        "executor": "nx:run-commands",
        "options": {
            "cwd": "apps/rust_wasm_embed",
            "commands": [
            "trunk build --release"
            ],
            "parallel": false
        }
    }

The next move would be to test case the nx run commands through the kbve shell file, like this:

    ./kbve.sh -nx rust_wasm_embed:trunkrelease

Which we will then add into our Github action for the trunk release and organize the pipeline!

Before pushing through, I believe it would make sense to sync the branches up for a release and then add in this feature? We could also not do that and just try a rolling update and see how it would work?

7:15pm - HerbWASM

HerbWASM

We need to make sure that the WASM that gets released from the rust_wasm_embed has a clean folder to deploy to! This includes making sure the folder gets wiped clean and that only successful builds get copied over for a new dev branch. Okay, let me take a step back, the work flow would be like this:

• [1] There are changes to the rust_wasm_embed application using nx affected or file changes inside of /apps/rust_wasm_embed/src/
• [2] During the alpha branch, these changes should be lint and tested, using a combination of unit and integration testing. If any fails, then we do not move it out of alpha.
• [3] Duriing the beta branch, we would run the trunk release and then create a new pull request with the distrubtion files, as a patch back into the same mono-repo.
• [4] Finally during the new patch, with the files, we would setup more unit / integration testing but this time between the Astro website and the wasm embeds.

This would be the current workflow / pipeline that I would want to build out tonight.

The current route that I am taking would be to create a quick custom shell script to handle the /dist/ folder migration. Under the nx run commands, we would just have it deploy the script for now, by making sure to chmod +x and then running it. The script name, hmm, I am thinking of calling it herbwasm.sh for now, but I can always come back and update it.

Opps, the script would be called pipelineherbwasm.sh, and it will be placed under the tools/scripts/public/wasm/ folder.