gotth-live-dev

Overview ¶

Command gotth-live-dev is the server half of FR-57: it watches a gotth-live application's source, rebuilds it when a Go or templ file changes, and restarts it. The browser half is client/dev-reload.js, which notices that the build identity moved and reloads the page.

Neither half needs the other to be this program in particular. Anything that rebuilds and restarts the process — air, wgo, reflex, entr, a shell loop — produces a new executable and therefore a new build identity, and the page reloads exactly the same way. This one exists so the feature has a default that is in the repository, needs nothing installed, and is held by the same CI as the library.

Running it ¶

# from your application's module, against the checked-out library:
go run github.com/candacelabs/csf/pkg/gotth/internal/cmd/gotth-live-dev

# with arguments for your application, after --:
go run github.com/candacelabs/csf/pkg/gotth/internal/cmd/gotth-live-dev -- -addr 0.0.0.0:8080

It lives under internal/ and is still reachable from a consumer's module: Go's internal rule governs IMPORTS, and a main package named on the command line is not imported by anything. The alternative — a package at the module root — would be a third exported package, which internal/arch caps at two and which needs a ruling rather than a directory.

What it does on a change ¶

.templ changed   templ generate, then go build, then restart
.go changed      go build, then restart
build failed     nothing is restarted; the previous build keeps serving,
                 its build identity is unchanged, and the page in the
                 browser does not reload. Fix and save again.

It builds with `go build -o` and runs the resulting binary rather than using `go run`, so the process it supervises is the application itself and not a toolchain that spawned it. See supervisor.build.

What it does not do ¶

It does not know about the browser, the WebSocket, or the session. It does not preserve anything across the restart, because nothing here can: the server-held state of a session belongs to the process that is being replaced. docs/guide/dev-reload.md says what survives and what does not, in those terms.