feat(dev): Windows dev environment for pnpm dev:app:win

[sanil-23]

Summary

• Promote scripts/run-dev-win.sh from a hidden helper into a discoverable pnpm dev:app:win script (alongside the macOS dev:app).
• Auto-bootstrap the MSVC C++ environment inside the launcher so it works from any plain Git Bash, not just from the "x64 Native Tools Command Prompt for VS 2022".
• Make setup-chromium-safe-storage.sh a clean no-op on non-Darwin platforms so the cross-platform dev:app pipeline stops trying to call security on Windows / Linux.
• Pin the CMake generator (Ninja) and the rustc linker (MSVC link.exe absolute path) so they can't disagree or get shadowed by Git's coreutils link.exe.

Problem

Windows dev today is gated on undocumented setup. pnpm dev:app is the macOS-flavored launcher (sets $HOME/Library/Caches/tauri-cef, runs setup-chromium-safe-storage.sh which calls macOS-only security, sets APPLE_SIGNING_IDENTITY); it surfaces in pnpm run and looks like the canonical dev entry point. The only Windows-aware launcher (scripts/run-dev-win.sh) lives off-script with no entry in package.json, so a Windows dev who follows the obvious path hits a chain of obscure failures:

• security: command not found (mac keychain CLI invoked unconditionally)
• ninja: error: loading 'build.ninja' (CMake configured with VS generator but build step invokes ninja because CMAKE_MAKE_PROGRAM was set without CMAKE_GENERATOR)
• /usr/bin/link: extra operand '...rcgu.o' (rustc resolves bare link.exe to Git's coreutils symlink utility instead of MSVC's linker)

Even when devs do find run-dev-win.sh, it required manually launching the "x64 Native Tools Command Prompt for VS 2022" first or the C++ toolchain would be invisible.

Solution

Discoverability. Add dev:app:win to both app/package.json and package.json (root proxy) so pnpm run lists it next to dev:app. Same script-naming convention as the existing macos:* entries.

Cross-platform setup-chromium-safe-storage. Add a [[ "$(uname -s)" != "Darwin" ]] && exit 0 guard at the top. macOS Keychain logic is preserved verbatim below the guard. Linux's password store is already configured via --password-store=basic from the Tauri shell; Windows uses DPAPI and doesn't need any seeding.

Auto-bootstrap MSVC env in run-dev-win.sh. When cl.exe isn't on PATH, the script:

1. Locates the latest VS install via vswhere.exe -latest -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64.
2. Writes a tiny launcher .bat that calls vcvars64.bat then dumps set (a temp .bat avoids MSYS's quote-mangling of cmd //c "call \"...\"" invocations).
3. Re-exports the captured env into the bash session — PATH gets Windows-to-Unix conversion per entry, INCLUDE/LIB/LIBPATH stay in Windows form for cl.exe, and the VS-specific vars (VSCMD_*, VCToolsInstallDir, WindowsSdkDir, UCRTVersion, …) come along.
4. Verifies cl.exe is reachable; fails fast with a clear error if not.

Pin the CMake generator and the linker. After the env load:

• export CMAKE_GENERATOR=Ninja — without this, CMake auto-picks the VS generator on Windows (creates .sln files), but the cmake --build step invokes ninja because CMAKE_MAKE_PROGRAM is set, leading to "build.ninja not found".
• export CARGO_TARGET_X86_64_PC_WINDOWS_MSVC_LINKER=<absolute path to MSVC link.exe> — derived from dirname "$(command -v cl.exe)". cargo passes this to rustc as -C linker=<path> directly, bypassing PATH lookup entirely so Git's /usr/bin/link.exe can never win.

Submission Checklist

• N/A: dev-environment plumbing — no runtime code paths exercised
• N/A: dev-environment plumbing
• N/A: no feature surface added or removed
• N/A: no feature IDs touched
• No new external network dependencies introduced
• N/A: not a release-cut surface
• N/A: no linked issue

Impact

• Windows dev only. No effect on macOS / Linux dev or on the shipped product (release builds use pnpm tauri:build:ui / macos:build:* paths, none of which this PR touches).
• macOS dev:app is unchanged; the chromium-safe-storage script behaves identically on Darwin (the guard is a leading early-exit on non-Darwin only).
• First-time Windows pnpm dev:app:win may take an extra few seconds while the MSVC env loads; subsequent runs in the same shell are no-ops because cl.exe is already detected.

Related

• Closes:
• Follow-up PR(s)/TODOs: companion fix in fix(welcome): include bearer token in core RPC test-connection probe #1301 (Welcome page bearer token); both surfaced while debugging Windows dev together

Summary by CodeRabbit

• New Features
  • Added a Windows-specific development script to simplify starting the app in Windows environments.
  • Integrated MSVC toolchain support into the Windows dev setup for more reliable native builds.
  • Added a macOS-only guard to the Chromium safe-storage setup to avoid running macOS keychain steps on other platforms.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 03b05e2b-3792-49fe-8d40-05264505aa66

📥 Commits

Reviewing files that changed from the base of the PR and between 9ba78f9 and 7fba3cd.

📒 Files selected for processing (1)

• scripts/run-dev-win.sh

---

📝 Walkthrough

Walkthrough

Adds a Windows MSVC bootstrap to the Windows dev runner, exposes new Windows dev scripts in root and app package manifests, and adds a macOS-only early exit guard to the Chromium safe-storage setup script.

Changes

Windows MSVC Development Toolchain Setup

Layer / File(s)	Summary
Script Wiring app/package.json, package.json	Added dev:app:win scripts to app and root manifests to invoke the Windows development workflow.
MSVC Bootstrap / Env Discovery scripts/run-dev-win.sh	Inserted an MSVC bootstrap block that locates Visual Studio via vswhere, launches vcvars64.bat through a temporary BAT to capture environment, and extracts MSVC-related variables.
Tool Validation & Export scripts/run-dev-win.sh	Verifies presence of cl.exe and link.exe, pins the MSVC link.exe path, exports CARGO_TARGET_X86_64_PC_WINDOWS_MSVC_LINKER for Rust builds, updates PATH to prioritize MSVC tools, and sets CMAKE_GENERATOR=Ninja.
Integration Point scripts/run-dev-win.sh	Runs the MSVC bootstrap before existing CEF runtime setup and other Windows tooling logic in the script.

macOS Platform Isolation

Layer / File(s)	Summary
Platform Guard scripts/setup-chromium-safe-storage.sh	Added a Darwin-only guard that exits early on non-macOS platforms and expanded comments describing macOS-specific behavior.

Sequence Diagram(s)

sequenceDiagram
  participant Dev as Developer (shell)
  participant Runner as scripts/run-dev-win.sh
  participant VSWhere as vswhere.exe
  participant VCVars as vcvars64.bat
  participant MSVC as MSVC toolchain (cl/link)
  participant Build as Cargo/CMake/Ninja

  Dev->>Runner: invoke run-dev-win.sh
  Runner->>VSWhere: query Visual Studio installations
  VSWhere-->>Runner: installation path(s)
  Runner->>VCVars: launch vcvars64.bat via temp launcher
  VCVars-->>Runner: environment variables (PATH, INCLUDE, LIB, etc.)
  Runner->>MSVC: verify cl.exe and link.exe on PATH
  MSVC-->>Runner: tool paths confirmed
  Runner->>Build: export CARGO_TARGET_..._LINKER and CMAKE_GENERATOR=Ninja
  Dev->>Build: proceed with Cargo/CMake build using configured MSVC toolchain

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related PRs

• tinyhumansai/openhuman#1015: Also modifies scripts/run-dev-win.sh and introduces Windows-specific development/tooling steps.

Suggested reviewers

• senamakel

Poem

🐰 I hopped into scripts with a grin,
found vswhere, vcvars, and cl.exe within.
I set the linker, told CMake “Ninja, go!”,
now Windows builds hum, neat and slow.
A tiny rabbit cheers the dev-win win 🎉

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly describes the main change: adding a Windows development script entry to enable Windows developers to use pnpm dev:app:win.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@scripts/run-dev-win.sh`:
- Around line 36-118: The script currently pins link.exe only inside the
bootstrap branch, so when cl.exe is already on PATH the pinning (msvc_cl_dir,
msvc_link_unix, msvc_link_win, and export of
CARGO_TARGET_X86_64_PC_WINDOWS_MSVC_LINKER) is skipped; move or duplicate the
link discovery/pinning logic to run after the cl.exe bootstrap if-block (use
command -v cl.exe to find cl.exe, compute msvc_cl_dir via dirname "$(command -v
cl.exe)", derive msvc_link_unix/msvc_link_win and export
CARGO_TARGET_X86_64_PC_WINDOWS_MSVC_LINKER, and prepend msvc_cl_dir to PATH) so
the linker is pinned regardless of whether vcvars64.bat was invoked.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: f8eb90d8-604a-405d-b07f-53af9ee42575

📥 Commits

Reviewing files that changed from the base of the PR and between a3a1843 and 9ba78f9.

📒 Files selected for processing (4)

• app/package.json
• package.json
• scripts/run-dev-win.sh
• scripts/setup-chromium-safe-storage.sh

[sanil-23]

Heads-up: the latest Markdown Link Check run (post-7fba3cd5) failed on a transient TLS handshake error fetching https://tauri.app/plugin/updater/ from docs/AUTO_UPDATE.md — a file this PR doesn't touch. Earlier runs on this PR passed; the check just needs a re-run when a maintainer next reviews.

Lychee log:

[ERROR] <https://tauri.app/plugin/updater/> | Network error: TLS handshake failed