test: add browser test harness #563
Conversation
kateinoigakukun
force-pushed
the
pr-8b2c52b750dfe1d1529003eff104cb9cefdffc19
branch
from
dbdbc48 to
244388f
Compare
There was a problem hiding this comment.
I ran all of this locally to understand what is going on and I think this makes sense. It does increase the amount of code to maintain but it seems worth it in order to check this in the browser. Let's hope the CDN artifacts don't cause an issue during CI (they shouldn't, right?) but if they do we could figure out workarounds.
Thanks @kateinoigakukun for working on this!
| ConsoleStdout.lineBuffered((stderr) => { | ||
| console.error(stderr); | ||
| }), | ||
| new PreopenDirectory("/", new Map()), |
There was a problem hiding this comment.
Shouldn't there be some way to use the preopens we pass along in the --dir CLI args... or no?
How do the tests that need special access work?! Or maybe that's just the fts.c test that we skip in browser?
There was a problem hiding this comment.
Good catch. The preopen is unnecessary and I don't think it's even worth adding --dir emulation support to the harness. File system emulation is not part of wasi-libc's responsibility and it's not the main focus here, so I just skipped tests using --dir for now.
kateinoigakukun
force-pushed
the
pr-8b2c52b750dfe1d1529003eff104cb9cefdffc19
branch
from
244388f to
424d3a1
Compare
This commit adds a browser test harness to run the tests in the browser.
kateinoigakukun
force-pushed
the
pr-8b2c52b750dfe1d1529003eff104cb9cefdffc19
branch
from
424d3a1 to
5048494
Compare
| * This script is served by `harness.mjs` and runs in the browser. | ||
| */ | ||
| import { WASI, File, OpenFile, ConsoleStdout, PreopenDirectory } from 'https://cdn.jsdelivr.net/npm/@bjorn3/browser_wasi_shim@0.3.0/+esm' | ||
| import { polyfill } from 'https://cdn.jsdelivr.net/npm/wasm-imports-parser@1.0.4/polyfill.js/+esm'; |
There was a problem hiding this comment.
It seems like we are taking a dependency here this WASI implementation. Maybe this should be documented somewhere? What happens if this breaks? Who maintains this WASI implementation?
There was a problem hiding this comment.
Added a sentence about the dependency to test/README.md: #576
If the dependency breaks, wasi-libc's CI can fail, but nothing affects the users of wasi-libc. Although it's maintained under a personal namespace, the implementation is the most reliable one on browser today as far as I know.
There was a problem hiding this comment.
FWIW, I see this browser testing infrastructure as useful but experimental. If we were to run into many problems consistently, I think it would make sense to rip it out. (and I reviewed it with that in mind). But I'm hopeful that things are stable enough at this point that that won't be a problem.
This commit adds a browser test harness to run the tests in the browser.
Motivation
We are heavily using wasi-libc on browsers but we don't have any test for the case in wasi-libc. In theory, there should be no behavioral difference between wasmtime and browsers (as long as WASI implementations are correct) but browsers have their own limitations in their Wasm engines. For example, memory.atomic.wait32 is not permitted on the main thread.
We are working on adding some mitigation for such browser-specific issues (#562) and this test harness will help to validate the fix.