260719.2 · 54a57e628dcdc05034d13530c77bf700444f7368
chore(wasm): stop inlining ghostty-vt.wasm in ghostty-web.js
The vendored ghostty-web.js embedded a base64 copy of ghostty-vt.wasm twice, as default candidates for Ghostty.load(). That more than tripled the shipped bytes: the JS was ~1.2MB, 91% of it the inlined wasm, and the same wasm also ships separately as ghostty-vt.wasm.
Ghostty.load(url) uses `url ? [url] : defaults`, so when a caller passes an explicit wasm URL the inline defaults are never read, and tcell.js always passes one. Drop the two data:application/wasm;base64 entries and keep the ./ghostty-vt.wasm and /ghostty-vt.wasm relative paths as no-argument fallbacks. ghostty-web.js: 1.21MB -> 105KB; the wasm now ships once.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
reading declarations
Changes to README-wasm.md. All files
@@ -24,6 +24,8 @@ cp -R webfiles/ghostty-web /path/to/dir/to/serve/ The vendored `ghostty-web.js` is intentionally browser-only. Its upstream Node `readFile` fallback import is removed so browser-oriented servers and bundlers such as Vite do not try to resolve a Node file-system shim; the bundled code loads `ghostty-vt.wasm` with `fetch`. +The vendored `ghostty-web.js` is also de-inlined: upstream embeds a base64 copy of `ghostty-vt.wasm` twice inside the JS (as default candidates for `Ghostty.load()`), which more than tripled the shipped bytes. Those inline `data:application/wasm;base64,...` defaults are removed; `tcell.js` passes an explicit URL to `Ghostty.load()`, and the `./ghostty-vt.wasm` / `/ghostty-vt.wasm` relative paths remain as no-argument fallbacks. The wasm is therefore shipped once, as the separate `ghostty-vt.wasm`.+ For example: ```sh