Three edits to the scaffold, each of which the generated tree gets
wrong for a shipped app.
**The phone ABI got a debug library.** Upstream's `build` task forwards
ARCH to compile:go:shared but not PRODUCTION, so the arm64 leg
recomputed BUILD_FLAGS against an unset variable and took the debug
branch -- while amd64, which package:fat calls directly with
PRODUCTION: "true", was correct. A release APK therefore shipped a 40MB
unstripped debug library for the only ABI a release is for, beside a
31MB production one for the emulator. 34MB APK before, 27MB after.
**The APK could be installed once and never updated.** Android orders
releases by versionCode and refuses anything not greater than what is
installed; the scaffold hardcodes 1, so the first install would have
been the last and the only way out is an uninstall, which takes the
user's library with it. It comes from YJ_VERSION_CODE now, which CI
derives from the tag (1.3.1 -> 10301, monotonic while minor and patch
stay under 100), with a default that keeps a local build working.
Integer.parseInt, not `(...) as Integer`: Groovy binds the call
parentheses to versionCode before the cast, so the latter reads as
`versionCode("1") as Integer` -- it sets a String, then casts the
setter's null return, and Gradle fails the whole project with "Value is
null" pointing at that line.
**And it identified itself as com.wails.app.** applicationId is
app.yellowjacket now, matching build/config.yml's productIdentifier,
and the label is YellowJacket rather than "Wails App".
Two things follow from that rename and both bite:
The identity is declared twice. applicationId is what Gradle installs;
APP_ID in build/android/Taskfile.yml is what every adb-driven task
uninstalls, launches and filters, and nothing enforces agreement.
ANDROID.md says to set APP_ID in build/config.yml -- that does nothing
in beta.8, checked both ways: `wails3 task` builds its var set from CLI
KEY=VALUE arguments and the Taskfile tree and never reads config.yml,
and even when set it feeds only those adb commands, never Gradle.
And `namespace` deliberately stays com.wails.app, because that is the
Java package MainActivity and WailsBridge live in and renaming it means
renaming their source. So the launcher activity is
app.yellowjacket/com.wails.app.MainActivity, and the short
`.MainActivity` form resolves the dot against the applicationId and
fails with a class-not-found that reads like a broken build.
Plan 015 phase 0 established that this app cross-compiles for Android
with no source changes at all. A CGO_ENABLED=0 probe of the whole tree
for android/arm64 fails on exactly two packages -- ebitengine/oto/v3
and wails/v3/pkg/application -- and both fail only because their
Android implementation is cgo, which is what the NDK supplies. Notably
modernc.org/sqlite, the entire database layer and the thing most likely
to have no Android target, is clean. The fat APK (arm64-v8a + x86_64)
builds in about 25 seconds.
So build/android/ stops being ignored. This commit is the tree exactly
as `wails3 generate build-assets` emits it, so that the next commit is
a readable diff of what we changed and a future refresh has something
to compare against.
Two things about how it is carried:
`wails3 update build-assets` does NOT generate it, contrary to what
CLAUDE.md has claimed since the v3 migration. In beta.8 that command
extracts only internal/commands/updatable_build_assets, which is
darwin/ios/linux/windows; the android tree comes from `generate
build-assets`, which rewrites the whole of build/. It was generated
once into a scratch directory and copied across, so from here it is
committed and hand-edited like source. Only its output is ignored --
jniLibs (~60MB of per-ABI c-shared libraries), gen/, overlay.json and
Gradle's own directories.
And it brings one Go file into ./... -- scripts/deps/install_deps.go,
the interactive SDK installer behind `task android:install:deps`, which
trips 24 of our strict linters. golangci excludes the directory rather
than reformatting upstream's file, which the next refresh would undo
and which would make the diff against upstream unreadable. This repo
uses `make android-setup` instead.
Neither packaging/arch/PKGBUILD nor the Homebrew formula had been run
since Phase 1, and both were still calling v2's CLI: `wails3 build`
takes -tags, -obfuscated and -garbleargs and nothing else, so
`-clean -trimpath -ldflags` fails at the flag parser. Both also
installed from build/bin/, which is v2's output path — v3 writes to
bin/, and build/ is tracked build assets now.
Three more things the tree needs that neither recipe had. The tasks
invoke `wails3` by bare name, so scripts/toolbin has to be on PATH or
the build dies at its first sub-task. `wails3 build` has no -ldflags at
all, and build:native computes BUILD_FLAGS in its own vars: so a CLI
variable cannot override it — LDFLAGS_EXTRA is appended inside the
production -ldflags string instead, on linux and darwin alike, empty by
default so make build-dev/build-prod are unchanged. And bundling is a
separate step from building: `task build` produces a bare binary on
both platforms, so the formula's macOS path runs `task package`.
The build assets were the scaffold's, not this app's. Info.plist named
CFBundleExecutable `yjref` and com.example.yjref, nfpm packaged
./bin/yjref, the .desktop template said "A yjref application" — an .app
built from that plist would not have launched. They generate from
build/config.yml, whose info block had never been filled from
wails.json either; `wails3 task common:update:build-assets` is the fix.
nfpm's homepage and license are not derived from it and are set by
hand, which is noted in place, and the refresh regenerates build/ios
and build/android, which this repo does not carry.
arch-package.yml's pacman list moves to webkitgtk-6.0/gtk4 to match the
PKGBUILD's depends(): makepkg installs nothing itself, so a mismatch
fails at link time rather than at check time.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UDCbcCZQepnpSQYJ6SxxZm
`make sandbox`, `make dev`, `make build-dev` and `make build-prod` all
died with "/bin/sh: wails3: command not found". `wails3 dev` and
`wails3 task` are supervisors: they run the scaffold's Taskfile tree,
which invokes `wails3` by bare name in 54 places across four files. The
CLI is a vendored Go tool by design (plan 009, D3 — a global install
would be this build's first undeclared dependency), so that name did
not exist.
scripts/toolbin/wails3 execs `go tool wails3`, and the Makefile
prepends that directory only for the targets that start a supervisor.
Rewriting 54 scaffold call sites would be churn to redo on every
scaffold refresh; nothing global is installed either way.
The shim does not cd. The first version did, to be sure `go tool` found
the module — it does not need to — and that silently discarded the
`dir:` a task had set, so generate:icons failed with "open
appicon.png: no such file or directory" against a file that was there.
Three things the build path needed once it got that far:
- `frontend/package.json` gains `build:dev`, which build:frontend runs
under DEV=true and which did not exist.
- Vite binds 127.0.0.1. It defaulted to `localhost`, which resolves to
`[::1]` only here, while wails3 dev's asset proxy dials IPv4 — so the
first request for the dev server was refused and the first paint
raced a retry. Zero proxy errors after.
- The icons and the .desktop file are generated on every build.
icons.icns/icon.ico are deterministic from our appicon.png (verified
by regenerating), so the regenerated pair is committed and the churn
ends; .task/ and the .desktop file are ignored.
Also corrects a claim: build-prod strips and trims but does **not**
UPX-compress — that was v2's `-upx` flag. Phase 1 recorded UPX as
still working, but neither build target had been run.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UDCbcCZQepnpSQYJ6SxxZm
Phase 1 of plan 009. The app still builds and runs on v2 — nothing in
main.go or backend/ has moved yet — but the v3 CLI, its pinned runtime
and its build-asset tree are now present, which is what Phase 2 needs.
- wails/v3 v3.0.0-beta.8 pinned per D5, and wails3 added to the `tool`
block beside the v2 CLI per D3. Both are vendored; neither is a
global install.
- build/ now holds the v3 build assets, copied wholesale from a
`wails3 init` scaffold rather than hand-written. That collides with
this repo's existing use of build/ as ignored build *output*, so
.gitignore narrows to build/bin/ and bin/ and the assets are tracked.
The mobile platforms are not carried: this is a desktop player
(MPRIS over D-Bus, beep, XDG paths) and cannot target them.
- build/config.yml's info block is filled from wails.json, which stays
for now because the v2 CLI still reads it.
- Taskfile.yml defaults PACKAGE_MANAGER to pnpm, since the scaffold
assumes npm and frontend/package.json.md5 is part of the dep-caching
scheme.
One deviation from the plan worth recording. webkitgtk-6.0 is not
installed on this machine, so the default GTK4 path is unavailable and
the gtk3 fallback is in use. That also means `go tool wails3` does not
work — the CLI itself fails to compile without webkitgtk-6.0 — while
`go run -tags gtk3 .../cmd/wails3` does. The Makefile rewrite in the
next commit has to account for that, and it goes away once the GTK4
dependency is installed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UDCbcCZQepnpSQYJ6SxxZm
logan
yonluandClaude Opus 5