core

Roves' general-purpose native bridge. Every other module (process, cache) is a thin, typed wrapper around a call to invoke() here.

import { invoke } from "@drincs/roves-api/core";

await invoke("exit");

invoke<T>(cmd: string, args?: Record<string, unknown>): Promise<T> calls a native roves: command and returns its JSON-decoded result. Under the hood it's a plain fetch("roves:<cmd>?<args>") against the engine's own roves: custom protocol handler.

roves: is deliberately small and general-purpose — window/process lifecycle today, more as Roves grows its own native surface. Larger, self-contained SDKs (Steam) get their own dedicated protocol instead of being routed through here — see steam.

Most of your game's code should reach for process/steam/cache/saves directly rather than calling invoke() by hand — it's exported mainly so those modules (and any future ones) have a single, consistent implementation to build on.

isAvailable()

import { isAvailable } from "@drincs/roves-api/core";

if (isAvailable()) {
  // running inside Roves
}

isAvailable(): boolean — synchronous, no await needed. true when this page is actually running inside Roves, false in a regular browser (or any other embedder). There's no build-time signal for this — instead, Roves injects window.__ROVES__ = true into every page as soon as <head> exists, before the page's own scripts run (mirroring how Tauri exposes window.__TAURI_INTERNALS__), and isAvailable() just reads that marker directly — no fetch() round trip. A plain browser never gets this marker, which is exactly what this reports as "unavailable".

Check this before calling into saves (or any other Roves-only module) if your code might also run outside Roves — e.g. a browser preview during development.

systemInfo()

import { systemInfo } from "@drincs/roves-api/core";

const info = await systemInfo();
console.log(`${info.os_type} ${info.os_version} (${info.architecture})`);

systemInfo(): Promise<SystemInfo> returns host OS and engine diagnostics — useful for bug reports and graphics-compatibility triage, since Servo has a different renderer than Chromium/WebKit and the same WebGL feature probes a game might already run don't tell the whole story:

interface SystemInfo {
  os_type: string; // e.g. "windows", "macos", or a Linux distro id like "ubuntu"
  os_version: string | null;
  bitness: "64-bit" | "32-bit";
  architecture: string; // e.g. "x86_64", "aarch64"
  engine_version: string; // the running Roves/Servo build's own version
}

Field names deliberately mirror @tauri-apps/plugin-os's (type()/version()/arch()) and the os_info crate's (os_type/version/bitness/architecture) own conventions. engine_version names the actual Servo fork build that's running — the equivalent of a "webview version" elsewhere, but naming the rendering engine itself rather than a wrapper around someone else's, which is what matters when triaging a graphics/rendering report.