Guchho docs
GitHub

Guchho 1.0.8

The compiler API - lexer, parse and print - now runs on the WebAssembly engine, in Node and in the browser.

#

Released 2026-10-19.

Added

#

The compiler API on WebAssembly

#

@guchho/wasm now exposes the engine's own lexer, parser and printer. Until this release the WebAssembly engine could only build and transform; token-level and tree-level access lived in the native binary alone. The engine grew a service dispatch entry point (guchho_service), and the package wraps it with the same shapes the native compiler API publishes — the engine is the same C++ code behind the same protocol, so a caller moving between the two changes the import name, not the types.

  • Top-level exports: configure, loadFiles, lexer, parse, print, build, request and version run against one shared engine, from both ESM and CommonJS. configure({ files }) installs the in-memory file tree before the first call on the browser path; on Node the host file system is mounted and configure() is optional.
  • Engine instances: an engine from createGuchho() answers lexer(), parse(), print(), request() and requestRaw() alongside build() and callMain().
  • Three languages: html, css and js, each with its own token kinds and tree summary — nodes for HTML, top-level rules for CSS, symbols and part counts for JavaScript. parse answers with a numeric handle; print turns one back into source.
  • In the browser: it all runs in process, no native binary anywhere. The playground's Lexer and AST tabs are this API, showing the token stream and parse summary for whatever is in the editor.
import { lexer, parse, print } from "@guchho/wasm";

const source = 'console.log("hi");';
const tokens = await lexer(source, { language: "js" });
const parsed = await parse(source, { language: "js" });
const { code } = await print(parsed.ast, { language: "js" });

The guchho package's lexer(), parse() and print() fall back to this engine on Node too, native-first: a native binary, when one is installed, answers without loading the WebAssembly module at all. With only @guchho/wasm installed, the compiler stages now work where before they failed.

Typed browser entry for guchho

#

The guchho package ships a browser.d.ts and lists every named export of its browser entry explicitly, so import { build, lexer } from "guchho" in a browser bundle is a real named binding with types, not a namespace with one useful member.

Fixed

#
  • stop() no longer abandons its wait for the service to exit when the service is idle. Callers that stop and then exit no longer race a background exit.
  • The handle-to-language map behind parse()/print() is cleared when the native service ends. A restarted service reuses handle ids, and a stale entry could attribute a reused id to the wrong language.

Upgrading

#

Nothing here is breaking. Upgrade to pick up the compiler API on WebAssembly:

npm install -g guchho@1.0.8
npm install -D @guchho/wasm@1.0.8

Full comparison: v1.0.7…v1.0.8.

Edit this page on GitHub