Loopback Harness
Your driver as an fs/promises-shaped object, in-process — no kernel, no privileges, every platform.
import { createLoopback } from "mountx";
import type { Loopback } from "mountx";#createLoopback(driver)
function createLoopback(driver: FsDriver): Loopback;A driver with every optional method present (missing ones throw ENOSYS), every path normalized before the driver sees it, capabilities resolved, and two whole-file conveniences on top:
interface Loopback extends Required<Omit<FsDriver, "capabilities" | "mountx">> {
readonly driver: FsDriver;
readonly capabilities: ResolvedCapabilities;
readonly mountx: MountxExtensions | undefined;
readFile(path: string): Promise<Uint8Array>;
writeFile(path: string, data: string | Uint8Array): Promise<void>;
}const fs = createLoopback(driver);
fs.capabilities; // every capability resolved
fs.driver; // the driver you passed
await fs.writeFile("/a.txt", "text"); // create + truncate
await fs.readFile("/a.txt"); // no handle danceThis is what driver authors test against, and what the Tier-0 conformance suite runs on. Anything that works through createLoopback() works through a mount — the loopback is not a mock, it is the same normalization and capability layer a real session applies, minus the kernel.
#Next
- Mounting — the same driver, as a folder.
- Capabilities — what
fs.capabilitiesdecided, and how.