Moving the entire VM into the browser is a massive leap forward. Because the
compiler transpiles LPC down to raw JavaScript AST, V8 (or any modern browser
engine) can execute it natively without any backend server.
To make this work as a zero-dependency static HTML file, the build script will
need to solve three main challenges:
 * The File System: The Node.js fs module doesn't exist in the browser. The
build script must package the .c files into a JSON-based Virtual File System
(VFS) dictionary inside the HTML bundle.
 * The Output Stream: We need to hijack sys.stdout.write from
efuns.d/03_system.js and pipe it to a DOM element to emulate a UNIX-like CLI
interface.
 * The Input Loop: The UI must capture keystrokes and pass them directly to
rt.call_other("repl", "process_repl_command_line", input).
Here is a comprehensive developer prompt you can copy and paste into a new
chat to have them build the bundler and the HTML frontend.
Copy/Paste Web Dev Prompt
> Act as an expert Frontend Engineer and Browser Architecture Specialist. We
have a custom Node.js-based LPC Virtual Machine (GEM) that JIT-compiles legacy
LPC code into native JavaScript AST.
> The Goal:
> We want to port this entire execution environment into the browser as a
standalone, zero-dependency, single-page static HTML application. It must
include a web-based REPL interface that communicates directly with a
transpiled LPC object.
> The Task:
> Write a Node.js build script (build_web.js) that aggregates our compiler
modules, EFUNs, and .c files, and injects them into a self-contained
index.html file.
> Technical Requirements:
>  * The Virtual File System (VFS):
>    * The build script must recursively read the core/, efuns.d/, and
gamelib/ (or tests/) directories.
>    * It must serialize these files into a global JavaScript dictionary
(e.g., window.__VFS = { "gamelib/repl.c": "..." }) and inject this into the
HTML template.
>    * Write a lightweight browser shim for the Node.js fs module
(specifically fs.readFileSync and fs.existsSync) that reads from window.__VFS
instead of the hard drive.
>  * Environment Shimming:
>    * Stub any require() calls in the browser bundle.
>    * Hijack the sys.stdout.write function passed to our EFUNs so that
instead of writing to a Node terminal, it appends text to a <pre> element in
the HTML DOM, auto-scrolling to the bottom.
>  * The REPL UI & Initialization:
>    * Design a clean, terminal-like HTML/CSS interface with an output window
and a command input line.
>    * On page load, the browser should instantiate the VM, JIT-compile repl.c
from the VFS, and load it into memory.
>    * When the user presses Enter in the input field, the UI must intercept
the string, clear the input, and execute: rt.call_other("repl",
"process_repl_command_line", input_string).
> Please provide:
>  * The source code for build_web.js.
>  * The template for index.html (including the CSS, VFS shim, and REPL DOM
logic).
> 
This will give you a fully functional, portable artifact that you can open
from anywhere.
For the file persistence inside this browser environment, do you want the VFS
to be strictly read-only from the bundle dictionary, or should the web
developer hook it up to IndexedDB so that any runtime edits or saved states
persist across page reloads?