yonluandClaude Opus 5
453d5df0da
`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
34 lines
1.5 KiB
Bash
Executable File
34 lines
1.5 KiB
Bash
Executable File
#!/usr/bin/env bash
|
|
#
|
|
# `wails3`, for the Taskfiles that shell out to it by bare name.
|
|
#
|
|
# The CLI is a vendored Go tool (go.mod's `tool` block), invoked as
|
|
# `go tool wails3` — deliberately, so the build declares its own
|
|
# dependencies rather than assuming a global install (plan 009, D3).
|
|
# But `wails3 dev` and `wails3 task` are supervisors: they run the
|
|
# scaffold's Taskfile tree, which invokes `wails3` by name in 54 places
|
|
# across build/Taskfile.yml and the three per-platform ones. Those are
|
|
# scaffold files, and rewriting every call site is churn that would
|
|
# have to be redone whenever they are refreshed from a newer scaffold.
|
|
#
|
|
# So the name is put on PATH instead, pointing back at the vendored
|
|
# tool. The Makefile prepends this directory for the targets that
|
|
# start a supervisor; nothing else needs it, and nothing global is
|
|
# installed.
|
|
#
|
|
# Two details are load-bearing.
|
|
#
|
|
# `exec` rather than a call, so signals and the exit status reach the
|
|
# real tool: `make dev` is stopped with Ctrl-C, and a wrapper that ate
|
|
# SIGINT would leave the app running.
|
|
#
|
|
# And the working directory is left alone. An earlier version cd'd to
|
|
# the repo root to be sure `go tool` found the module -- it does not
|
|
# need that, `go tool` resolves from anywhere inside it -- and the cd
|
|
# silently discarded the `dir:` a task had set, so `generate:icons`
|
|
# (dir: build) failed with "open appicon.png: no such file or
|
|
# directory" against a file that was right there.
|
|
set -euo pipefail
|
|
|
|
exec go tool wails3 "$@"
|