Consider not being as dumb with the frontend build files included #31

New Issue

2026-10-05T01:54:01+02:00

adam commented

2026-10-05 01:54:01 +02:00

Frontend build files included is kind to our less-resourced friends on raspis etc. but it sucks from a diff & dev perspective. Can we maybe just bundle with releases as an artifact? Do something where the release points to a special branch that has those prebuilt?

Frontend build files included is kind to our less-resourced friends on raspis etc. but it sucks from a diff & dev perspective. Can we maybe just bundle with releases as an artifact? Do something where the release points to a special branch that has those prebuilt?

adam closed this issue

2026-10-05 01:54:01 +02:00

adam commented

2026-10-05 01:54:02 +02:00

My 2-cents: do it as part of release artifacts and avoid the repo churn.

Anyone building/running off main likely isn't going to care about the prebuilt optimization. (Though I'm curious how much time it saves.)

Deeper thoughts:

e.g 3 (or more?) tiers of users:

just want to run it -- e.g. docker image release
download and run -- e.g. download tarball, install some things, then uv sync & run
dev-comfortable -- e.g. clone, install some things, npm & uv

For reference, before my raspi SD card died (again), I was still doing option-3 since I was poking around with code. Now that I'm deploying on an amd64-based machine, I'm doing both option-3 and option-1 (my own local built docker image).

I have to imagine once development stabilizes, I'll just switch do your pre-built docker image entirely.

My 2-cents: do it as part of release artifacts and avoid the repo churn. Anyone building/running off main likely isn't going to care about the prebuilt optimization. (Though I'm curious how much time it saves.) ### Deeper thoughts: e.g 3 (or more?) tiers of users: 1. just want to run it -- e.g. docker image release 2. download and run -- e.g. download tarball, install some things, then uv sync & run 3. dev-comfortable -- e.g. clone, install some things, npm & uv For reference, before my raspi SD card died (again), I was still doing option-3 since I was poking around with code. Now that I'm deploying on an amd64-based machine, I'm doing both option-3 and option-1 (my own local built docker image). I have to imagine once development stabilizes, I'll just switch do your pre-built docker image entirely.

adam commented

2026-10-05 01:54:03 +02:00

Yeah it's less about build time and more to help people who are on resource-constrained clients -- I have had n=3 reports that this is basically unbuild-able on raspi zeros. Basically, unless someone is willing to use docker, they're gonna need to build. I like the idea of just bundling it as an artifact at release time. I will probably do that.

Yeah it's less about build time and more to help people who are on resource-constrained clients -- I have had n=3 reports that this is basically unbuild-able on raspi zeros. Basically, unless someone is willing to use docker, they're gonna need to build. I like the idea of just bundling it as an artifact at release time. I will probably do that.

adam commented

2026-10-05 01:54:04 +02:00

this is basically unbuild-able

Ah, RAM constrained. I remember when I was trying to build ESPHome firmware on a 2GB raspi4; it'd constantly OOM.

I have to imagine folks that "just want to run", it's best to run a tagged release instead of running the random latest dev commit 😁

> this is basically unbuild-able Ah, RAM constrained. I remember when I was trying to build ESPHome firmware on a 2GB raspi4; it'd constantly OOM. I have to imagine folks that "just want to run", it's best to run a tagged release instead of running the random latest dev commit :grin:

adam commented

2026-10-05 01:54:04 +02:00

Yeah let's do that then -- package an artifact on release with a prebuilt frontend.

Yeah let's do that then -- package an artifact on release with a prebuilt frontend.

adam commented

2026-10-05 01:54:05 +02:00

Gave it a smoketest; on a separate machine, downloaded the zip and did just uv sync and uv run .... Looks good!

Though curious if the README "Quick Start" should now be reorganized.
I think there's now:

download a "remoteterm-prebuilt-frontend" release (unzip; uv sync; uv run)
clone and build yourself (git clone; uv sync; npm(s); uv run)
docker

Gave it a smoketest; on a separate machine, downloaded the zip and did just `uv sync` and `uv run ...`. Looks good! Though curious if the README "Quick Start" should now be reorganized. I think there's now: * download a "remoteterm-prebuilt-frontend" release (unzip; uv sync; uv run) * clone and build yourself (git clone; uv sync; npm(s); uv run) * docker

adam commented

2026-10-05 01:54:06 +02:00

Yeah that's a good organizational note; thanks! Will do.

Yeah that's a good organizational note; thanks! Will do.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/Remote-Terminal-for-MeshCore#31