StoneSVN: a Vue and Vite frontend inside a Tauri SVN desktop client

[firzen]

Sharing StoneSVN, an MIT-licensed SVN desktop client built with Vue 3, Vite, Tauri 2 and Rust. It runs on Windows, macOS and Linux and is developed from OrcaSVN.

For Vite users building desktop frontends, the concrete integration is small:

• Tauri's beforeDevCommand starts vite, and its devUrl points to port 1420. Vite uses strictPort so a busy port fails instead of silently changing the address expected by the desktop shell.
• The file watcher excludes src-tauri, keeping Rust changes outside the frontend watcher.
• TAURI_DEV_HOST, when set, controls the dev server host and the HMR WebSocket address; the HMR port is 1421 in that mode.
• Production builds run vue-tsc --noEmit before vite build. The build configuration groups Vue/Pinia/i18n, Element Plus and Tauri packages into manual chunks. These are build boundaries, not a measured startup-performance claim.

The Vue UI reviews multiple working copies, text diffs and commit selection; native SVN operations run through Tauri commands in Rust using a separately installed SVN CLI. The browser frontend does not execute SVN itself. General Merge, Switch and line-level Blame views are not currently available.

Build configuration · Tauri integration · Source and setup · Overview and installers

Feedback from developers using Vite inside a desktop webview would be useful, especially on keeping the frontend/native development boundary clear. Self-submission; this introduction was prepared with AI assistance.

[tal7aouy]

Nice writeup — the Vite/Tauri boundary is exactly where these setups usually get messy, so a few notes from running
similar stacks:

• strictPort + fixed devUrl is the right call. The one thing worth double-checking is that your clearScreen: false
  is set in the Vite config too, otherwise Tauri's Rust logs get wiped by Vite on reload and the native side
  becomes hard to debug.
• Watcher excluding src-tauri is good, but also consider ignored: ["/src-tauri/"] plus pointing envPrefix to
  include TAURI_ so the env-driven config (TAURI_DEV_HOST, HMR port 1421) stays explicit rather than leaking all
  env vars into the client bundle.
• On the HMR host: when TAURI_DEV_HOST is set for mobile/LAN testing, make sure server.hmr.host matches the
  device-reachable address, not localhost — that's the most common "HMR silently dead on device" trap.
• Running vue-tsc --noEmit before vite build is a sensible gate. If build time becomes an issue, vue-tsc --build
  with project references is usually faster than a full --noEmit pass.
• The manual-chunks grouping is reasonable for a desktop app where the bundle is loaded from disk anyway; as you
  note, it's a boundary choice, not a perf claim — I'd agree it mostly helps caching/debuggability here rather than
  startup.

The clean split of "browser frontend never executes SVN, native commands go through Tauri in Rust" is the correct
security posture. Looks solid — thanks for sharing.