feat: support MSIX debugging with hot-reload#6
Conversation
velocitysystems
force-pushed
the
msix-debugging
branch
from
6039afb to
c206e7d
Compare
| $Manifest = Join-Path $AppDir 'Package.appxmanifest' | ||
| $Exe = Join-Path $TargetDebug 'tauri-app.exe' | ||
| # Build the Rust binary. | ||
| cargo build -p tauri-app |
There was a problem hiding this comment.
The old script had a comment explaining the build choice (# Use tauri build (not cargo build) so the webview loads frontendDist instead of devUrl.), and switching to cargo build here inverts that reasoning: a plain debug cargo build produces a dev-profile binary that loads devUrl (http://localhost:1420), which is exactly what makes the Vite hot-reload work. That subtlety tripped up a couple of us on review. What do you think about re-adding a one-line comment here noting why cargo build is used (so the webview targets the live Vite dev server rather than ../dist)? It would save the next maintainer the same head-scratch.
Comment added by AI model Claude
|
|
||
| winapp run $TargetDebug --manifest $Manifest --executable tauri-app.exe | ||
| # Start the Vite dev server in the background. | ||
| $vite = Start-Process 'cmd' -ArgumentList '/c', 'npx', 'vite' -WorkingDirectory $AppDir -NoNewWindow -PassThru |
There was a problem hiding this comment.
One reliability concern with launching via cmd /c npx vite: the $vite handle points at the cmd.exe wrapper, not the node/vite process it spawns. So the Stop-Process -InputObject $vite in the finally (line 57) only kills cmd, and the real Vite server is orphaned and keeps port 1420 bound. Because vite.config.ts sets strictPort: true, the next run then fails to start Vite ("Port 1420 is already in use").
Would launching the dev server in a way that lets you kill the whole tree fix this for you? e.g. keep the -PassThru PID and taskkill /T /F /PID $vite.Id in the finally, or start vite directly (node_modules/.bin/vite) instead of through the cmd/npx wrappers so the handle is the actual listener.
Comment added by AI model Claude
|
|
||
| try { | ||
| # Register and launch the app with MSIX package identity. | ||
| winapp run $TargetDir --manifest $Manifest --executable $Executable |
There was a problem hiding this comment.
Minor: Start-Process returns as soon as Vite is spawned, not when it's listening, so winapp run can launch the webview before the dev server is ready on :1420 — on a cold start that can show a blank window / ERR_CONNECTION_REFUSED until a manual reload. Would a short readiness poll before winapp run (loop on a TCP connect to localhost:1420 with a timeout) be worth adding here? Low severity for a dev helper, but it removes a first-launch papercut.
Comment added by AI model Claude
|
@velocitysystems Added minor comments. |
3 participants
Support MSIX debugging using
winappwith hot-reload using Vite.