Repository navigation
[Bug]: Direct desktop builds ignore --build-version in the bundled client #12767
Description
Activity
Thanks for the tight repro and the source-level diagnosis — this checks out.
Confirmed.
scripts/build-desktop-artifact.tsresolvesappVersionfrom--build-version/T3CODE_DESKTOP_VERSIONand writes that onto the staged Electronpackage.json(so the updater andresources/app.asar/package.jsonare correct). Thevp run build:desktopchild is spawned withoutAPP_VERSION.apps/web/vite.config.tsthen falls back toapps/web/package.json(currently0.0.42) and bakes that intoimport.meta.env.APP_VERSION. Settings → About (AboutVersionTitle), diagnostics, and version-skew all read that compiled constant.This is the same client-vs-Electron split as the old v0.0.10 reports (#928, #947), but not a duplicate: those were official release tagging/version-bump order. Current release/CI still runs
scripts/update-release-package-versions.tsbefore the JS bundle, then packs with--skip-build, so this report correctly does not claim shipped GitHub release assets are wrong.Scope: direct
build-desktop-artifactruns where the requested version differs from workspace package versions (Linux AppImage here; same script path on Windows/macOS).--skip-buildkeeps already-built client assets by design.Severity: minor bug (maintainer / local nightly / fork builds). Official release workflow is insulated.
A fix PR is already open: #12768 (pass
APP_VERSIONinto the desktop/web build). Review note: that only updates the client compile. The bundled server still reportsapps/server/package.json(ServerEnvironment). After an APP_VERSION-only change, a nightly client talking to the local0.0.42server could start showing version-skew. Official releases avoid that by rewriting web and server manifests. Worth aligning both sides (or invoking the existing version-align script) so client, server, and Electron agree.Next step: review #12768; keep this issue open until that lands.
I'd like to take this — working on a fix.
stepping back — #12768 already covers this
Area
Build, CI, or release tooling
Steps to reproduce
c14f6015bfe479d313355cb234af1a5c16dbb15f(v0.0.43-nightly.20260920.2018). The web package version is0.0.42.APP_VERSIONunset, build directly:vp exec node scripts/build-desktop-artifact.ts --platform linux --target AppImage --arch x64 --build-version 0.0.43-nightly.20260920.2018resources/app.asar/package.jsonversion.Expected behavior
The bundled client reports the artifact version selected with
--build-version(orT3CODE_DESKTOP_VERSION).Actual behavior
Settings shows
Version 0.0.42, although the installed/running desktop package has the requested nightly version. The desktop updater can correctly show “Up to Date” alongside the stale label.Observed on a locally built Linux AppImage based on this tag, with unrelated local feature patches and artifact version
0.0.43-nightly.20260920.2018000. I verified the running package version and the installed binary's checksum; this was not an old executable. The same missing propagation is present in the upstream source.Cause and scope
build-desktop-artifact.tsresolvesappVersionfor packaging but invokesvp run build:desktopwithout providing that version to the child build.apps/web/vite.config.tsreadsAPP_VERSION, falling back toapps/web/package.json; Settings displays that compiled constant.This specifically affects direct artifact builds whose requested version differs from the workspace package versions. The official release workflow runs
update-release-package-versions.tsfirst, so this report does not claim official release assets are affected.--skip-buildnecessarily uses already-built client assets.Impact
Minor bug: the version shown in Settings contradicts the installed desktop/updater version and makes update verification confusing. The same client constant is used in diagnostics and version-skew reporting.
Environment
Linux x86_64, Electron AppImage, nightly source tag above.
I searched existing issues and PRs and did not find a matching report.