VS Code Extension

Roves is a VS Code extension that runs a web project you've already built locally with the Roves shell, straight from VS Code's own Run and Debug UI — no Rust or Python toolchain, and nothing added to your project. It's the fastest way to try a change in the real engine during development, without reaching for Packmaster or the GitHub Action, neither of which are meant for a tight local edit-reload loop.

Install

Search for Roves in VS Code's Extensions view, or install directly from the Marketplace listing.

Use

Add a configuration to your project's .vscode/launch.json:

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "roves",
      "request": "launch",
      "name": "Run with Roves",
      "preLaunchTask": "build",
      "distFolder": "dist"
    }
  ]
}

(VS Code's own "Add Configuration…" in launch.json, or the Run and Debug view's configuration dropdown, offers a Roves: Run snippet to start from.)

preLaunchTask is a plain VS Code task that builds your project first — e.g. in .vscode/tasks.json:

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "build",
      "type": "shell",
      "command": "npm run build",
      "presentation": { "reveal": "silent", "close": true }
    }
  ]
}

Press F5 (or Run and Debug → select the configuration → the ▷ button). The first time, this downloads the right roves_shell_<platform>[_steam].zip release asset for your OS from Roves' GitHub releases, showing progress in the status bar, and caches it in VS Code's own extension storage — never inside your workspace. Every following run reuses that cached shell instantly, unless you change the configured version.

Stop it from the debug toolbar's stop button, same as any other debug session. Output (the shell's own stdout/stderr) streams into the Debug Console.

How it works

No mach bundle, no packing — the extension writes a small launch.json next to the cached shell binary, pointing its url field directly at your project's built index.html by absolute path. bundle_launch.rs (the part of the engine that reads this file) resolves that path via a plain filesystem join, and joining an absolute path onto anything just returns the absolute path unchanged — so this works without your content ever needing to be copied, packed, or bundled next to the shell at all. See Content root & client-side routing for what that launch.json-driven boot actually does once the shell opens it (game://content/, not a raw file:// path).

Steam App IDs go through the same steam_appid.txt-next-to-the-binary convention Packmaster already uses.

Launch configuration properties

Known limitations

• Only runs a loose (uncompressed) build — it doesn't pack content the way mach bundle --content-compress=auto does. Not needed for a local dev loop, and not something a real bundle for distribution should skip — use Packmaster or the Action for that.
• Downloaded shells are cached per version/platform/Steam-variant and never cleaned up automatically — delete old ones yourself from the extension's storage folder if you want the disk space back.