how can we write JS/TS custom route with hot reload?

[maxirozay]

The doc says that it will pick up wasm files in in wasm folder and the code example is in TS. I see that there's a guests folder in the examples with build scripts but is there a place where we can just write TS/JS routes and trailbase will compile them automatically on the go?

Do we have to copy the wasm-guest-ts example and run it or there's a place like traildepot/wasm where we can just add TS files and trail run will compile them directly then restart to serve the changes?

[ignatz]

Not quite. Have you seen https://github.com/trailbaseio/trailbase/blob/main/examples/wasm-guest-ts/hot-reload.ts? Which sets up a watcher, recompiles TS and SIGHUPs TB? When you add new routes, SIGHUP won't be enough due to how Axum handles routes. In that case you'd have to restart

[maxirozay]

Yes that's what I used so I had to copy the file and restart trailbase when the code changes. That's why I was wondering if there was a solution inside trailbase that would handle the hotreload and the restart.

[ignatz]

Yes that's what I used so I had to copy the file and restart trailbase when the code changes. That's why I was wondering if there was a solution inside trailbase that would handle the hotreload and the restart.

IMHO, there's two parts to this question:

1. The hot reload dev workflow should absolutely be able to copy the wasm component, SIGHUP the server or even restart when necessary. None of this requires any intimate knowledge of WASM component building inside TB.
2. Should the TB server/cli do this instead? Maybe, depends on the details.

For more context: the "LangX" -> WASM flows, are all very different and some rather involved. Building them into the binary, seems out of the question. Some may even argue that a production binary shouldn't contain dev workflows, since it carries overhead and may increase the attack surface. However, one could argue having a dormant file-watcher wouldn't be too bad and you'd probably be right. The file watcher could then just run shell commands to build the WASM files. This would probably require us to standarize the WASM component package layout more. Right now they're independent, TB only cares about a properly built WASM component and nothing else. A few things TB would need to keep track off:

• Find and validate installed WASM toolchain,
• Find, validate and invoke the right JS toolchain (npm, pnpm, yarn, bun, deno, ...)
• Handle Linux, Mac, Windows,

Naively, I do think there may be merit in standardizing the package/component layout more but I'm less sure if the TB should deal with all the crap or whether we can improve the external hot-reload to a point where it's equivalent or better?

[maxirozay]

I don't really know much about this topic so I can't advise well but I agree that it shouldn't be part of the binary and a cli with a command like trail dev or have the hot reload file in the TB package maybe.