Windows port PR 2: local dev experience#536
Open
ldstreet wants to merge 3 commits into
Open
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Deploying maple with
|
| Latest commit: |
2f47114
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://4c03f287.maple-ca8.pages.dev |
| Branch Preview URL: | https://windows-pr2-dev-experience.maple-ca8.pages.dev |
ldstreet
force-pushed
the
windows/pr2-dev-experience
branch
from
f3d5dae to
2e31359
Compare
ldstreet
force-pushed
the
windows/pr1-compile-launch
branch
from
4e074dc to
c5e79a2
Compare
ldstreet
force-pushed
the
windows/pr2-dev-experience
branch
from
2e31359 to
19af7c4
Compare
Idempotent PowerShell bootstrap for a fresh Win10/11 (x64 or ARM64) dev machine. Installs the Visual Studio Build Tools 2022 components, Node.js LTS, rustup, and standalone LLVM that PR 1's manual smoke discovered the hard way; writes a working frontend/.env.local template pointing at the prod enclave URL; safe to re-run. scripts/setup-windows.ps1 (MPLR-vuskayhx / 2a): - Preflight: PowerShell version, OS caption, admin check, winget availability, ExecutionPolicy relaxation (npm.ps1 needs RemoteSigned). - winget packages: VC++ 2015+ x64 (and ARM64 on ARM hosts — rollup's native module links against it), Node.js LTS (bun has no Win-ARM binary), rustup, LLVM.LLVM (backstop for `ring` 0.17 on aarch64-pc-windows-msvc, which needs clang for ARM64 asm even when the VS clang-cl component is present). - VS Build Tools 2022: downloads vs_BuildTools.exe and installs the exact components needed (VCTools workload, VC.Tools.x86.x64, VC.Tools.ARM64, VC.Llvm.Clang, Windows11SDK.22621). Branches on whether BuildTools is already installed: 'modify' subcommand with --installPath for adding to an existing install (avoids exit-1 from redundant --add args on top of present components), full install with --includeRecommended otherwise. --passive instead of --quiet because --quiet swallows exit codes on the modify path. Single-string ArgumentList with explicit quoting because Start-Process -ArgumentList <array> doesn't reliably quote space-containing paths in PowerShell 5.1. Verifies on disk via vswhere after install completes — 'finished install' from the bootstrapper doesn't always mean components landed. - Rust toolchain: pinned to 1.95.0 via a new -RustToolchain script parameter (default '1.95.0') that matches the CI pin in .github/workflows/desktop-build.yml + desktop-pr-build.yml. Installs the toolchain if absent, sets it as default, then on ARM64 hosts also adds x86_64-pc-windows-msvc as an extra target so the same machine can cross-compile the x64 Tauri bundle. - frontend/.env.local template: writes UTF-8 (no BOM, since Vite chokes on a BOM in .env files) with VITE_OPEN_SECRET_API_URL pointing at the prod enclave URL. Closes the silent white-screen-on-launch footgun caught during PR 1 smoke (Vite bakes env vars at build time, so an empty .env.local bundles empty strings). - ASCII-only output (the file itself is BOM-less ASCII). The few cases where flavor text in 'Next steps' wants an em-dash use '--' instead. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Closes the second half of PR 1's pain: every fresh Windows shell needed a
Developer PowerShell open (vcvarsall.bat), cargo target dir on the source
tree breaks on Parallels shared folders, and the ort crate would
auto-download an unpinned ONNX Runtime instead of using the SHA-verified
CI helper. These wrappers eliminate all three so the dev loop is a single
`just windows-dev`.
frontend/src-tauri/tauri.windows.conf.json (MPLR-kgoqxeac / 2b):
- Minimal Tauri config overlay that swaps bun -> npm for
beforeDevCommand / beforeBuildCommand. bun has no Windows ARM64 binary
(Node.js LTS via winget is the established workaround per
setup-windows.ps1) so the default `bun dev` / `bun run build` would fail
before tauri ever ran. Applied via `--config` from the just recipes,
not the default config -- everywhere else still uses bun.
scripts/tauri-windows.ps1 (MPLR-kgoqxeac / 2b):
- One PowerShell wrapper that handles `tauri build` and `tauri dev` based
on a -Command parameter. Steps the dev would otherwise hand-roll on
every invocation:
1. Locate VS Build Tools via vswhere (errors if setup-windows.ps1
hasn't been run).
2. Set CARGO_TARGET_DIR to %USERPROFILE%\maple-cargo-target (off the
source tree so Parallels shared-folder writes don't corrupt cargo
metadata). Overridable via -CargoTargetDir.
3. Source frontend/src-tauri/scripts/provide-windows-onnxruntime.sh via
Git Bash; parse its KEY=VALUE output and import as process env vars.
This mirrors how desktop-build.yml + desktop-pr-build.yml feed those
three vars into \$GITHUB_ENV -- local dev gets the same SHA-pinned
ORT as CI. -SkipOrt falls back to the ort crate's auto-download.
4. Chain vcvarsall.bat <arch> with the tauri command in a single
cmd.exe invocation so the MSVC env survives into the build. Apply
the Windows overlay via --config.
- Defaults to arch=arm64 (Snapdragon X laptops + Apple Silicon Parallels
are the primary audience); arm64_amd64 / x64 also accepted.
justfile (MPLR-kgoqxeac / 2b):
- New `windows-build` and `windows-dev` recipes, both guarded by the
[windows] attribute (just hides them off-Windows so the recipe list
stays clean for mac/linux devs). Each is a one-line PowerShell call
into scripts/tauri-windows.ps1 with the corresponding -Command.
- Recipes accept an `arch` parameter that pipes straight through to
vcvarsall (same arg shape as the iOS ios-dev-sim simulator parameter).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Closes the doc gap from PR 1 smoke: without docs, the next Windows contributor would rediscover every gotcha the hard way (clang-cl requirement, Parallels target-dir corruption, vcvarsall arch confusion, silent white-screen from missing .env.local). frontend/.env.local.template (MPLR-yeksjfcj / 2c): - Template with prod enclave URL pre-filled, comments explain the Vite build-time-baking gotcha and which vars are overridable. setup-windows.ps1 writes the same content into .env.local automatically; this file gives mac/linux devs (and non-bootstrap Windows devs) the same source of truth. - Kept .env.example as-is (abstract / self-hoster oriented); the new template is the working-default counterpart. docs/windows-build.md (MPLR-yeksjfcj / 2c): - End-to-end Windows dev guide: prerequisites (link to setup-windows.ps1), first build (just windows-build), iteration loop (just windows-dev), .env.local handling, gotchas table covering every footgun PR 1 smoke hit, CI vs local parity matrix (Rust 1.95.0, ORT 1.22.0 helper, Tauri overlay), and pointers to MPLR-goufxxvn (code signing) + MPLR-xhfehqft (native ARM64 shipping decision) for what's deferred. README.md (MPLR-yeksjfcj / 2c): - New "Windows" subsection under Prerequisites mirroring the existing macOS / Linux blocks: one-line setup invocation + link to the full guide. - New "Windows Development" section parallel to "iOS Development": the just windows-build / windows-dev quick reference + brief note on what the wrappers handle, plus a link to docs/windows-build.md. CLAUDE.md (MPLR-yeksjfcj / 2c): - Note in the Environment section that .env.local is required for any local build on any platform. Calls out the silent white-screen failure mode and points at the template + Windows-specific automation. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ldstreet
force-pushed
the
windows/pr2-dev-experience
branch
from
19af7c4 to
2f47114
Compare
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
AnthonyRonning
requested changes
May 26, 2026
Contributor
AnthonyRonning
left a comment
AnthonyRonning
left a comment
There was a problem hiding this comment.
I'm not sure I like many of these changes, nix should be used instead.
Contributor
There was a problem hiding this comment.
Collaborator
Author
There was a problem hiding this comment.
this points to a local backend which I don't expect us to really be running on a windows vm? to validate and test the windows build I think it probably makes sense to point to a prod/staging environment. but this file definitely feels like a duplicate, what if we point to /.env.example but in the windows setup we overwrite the value to be a real env?
Contributor
There was a problem hiding this comment.
I don't like this at all. Please use nix on windows.
Collaborator
Author
There was a problem hiding this comment.
I'd definitely love to use nix to stay consistent with the other platforms but my understanding is windows doesn't support nix unless you run it in a linux subsystem but then you wouldn't be able to compile the windows artifacts you need. did you have a specific strategy in mind for using nix on windows?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
setup-windows.ps1(2a) — idempotent bootstrap: VS Build Tools components, Rust 1.95.0 (CI pin), Node LTS (bun has no Win-ARM binary), Git for Windows (provides Git Bash for the ORT helper),just(justfile runner), VC++ redists, LLVM, and afrontend/.env.localtemplate. Defensively strips a UTF-8 BOM from an existing.env.local(PS 5.1 default-BOM I/O is a notorious footgun).tauri-windows.ps1+tauri.windows.conf.json(2b) — one-commandjust windows-build/just windows-devwrappers. Handles vcvarsall.bat lookup,CARGO_TARGET_DIRoff-source (Parallels-safe), ORT helper invocation, and the bun→npm overlay. Wraps both native and cross-arch builds (arch=arm64/x64/arm64_amd64).docs/windows-build.mdend-to-end guide,frontend/.env.local.template, README (Prerequisites + Development sections mirroring macOS/Linux/iOS), CLAUDE.md (.env.localrequirement note).Stacked on #520
Base branch is
windows/pr1-compile-launch, not master. Wait for #520 to merge before this can land on master.Patterns mirrored from #520 / master
-RustToolchainparameter (matchesdtolnay/rust-toolchainin CI)onnxruntime-pins.shgetswindows_arm64_*entries;provide-windows-onnxruntime.shreadsORT_TARGET_ARCH(defaultx64, so CI behavior unchanged).tauri-windows.ps1derives it from-Arch.just ios-build-onnxruntime→ script; same shape forjust windows-build→tauri-windows.ps1)# why:comments on every non-obvious workaround (MSYS2 path mangling,--passivevs--quiet, BOM-strip, etc.)Manual smoke
Validated end-to-end on Parallels Win11 ARM64:
git checkout→setup-windows.ps1→just windows-dev→ Maple launches to login screen with Vite hot-reload.onnxruntime.dllloads at runtime on native ARM64 (extends #520's x64-under-emulation data point).Out of scope
Test plan
build-windowsjobs (both PR + master push) pass — should be unaffected sinceORT_TARGET_ARCHdefaults to x64git clone→setup-windows.ps1→just windows-devsucceeds in ~30 min (the "Done when" criterion for MPLR-rqofgxpz)just windows-buildon ARM64 produces a working native NSIS installer🤖 Generated with Claude Code