Framework parity: unskip js-etherpad / js-next-* on the V8-imports lane (ECO-416) - #132
Merged
Merged
Conversation
Arshia001
force-pushed
the
eco-416-framework-parity
branch
from
July 28, 2026 14:41
6f5b264 to
0a3e9ba
Compare
…ne (ECO-416)
With GuestHeap removing the copy-layer corruption and the N-API import layers
now re-raising guest WASI process exits, all framework/standalone apps run on
the V8 WASIX (imports) lane at parity with the QuickJS lane. Drop the V8-only
edge skips:
- framework-test-v8-wasix: drop FRAMEWORK_TEST_EDGE_SKIP='js-etherpad'
- standalone-build-test-v8-wasix: drop
FRAMEWORK_TEST_EDGE_SKIP='js-next-ssr,js-next-standalone'
Only the docusaurus static sites stay skipped (FRAMEWORK_TEST_NODE_SKIP) --
they fail to build on the Node.js reference itself, and the QuickJS lane skips
them identically. Also pass --quiet to `wasmer run` on both V8 lanes so the CLI
progress spinner never pollutes captured output.
Fix a latent harness bug surfaced by unskipping js-next-ssr: the Next.js
standalone server binds `server.listen(port, process.env.HOSTNAME)`, and the
runner forwards the ambient machine HOSTNAME into the guest. That hostname does
not resolve inside the WASIX guest (its mounted /etc/hosts only knows
localhost) and, on a Debian/Ubuntu host, resolves to 127.0.1.1 rather than the
127.0.0.1 the harness polls -- so the server bound the wrong address (or hung
on the lookup) and the harness fell back to serving the static export instead
of live SSR. Pin HOSTNAME to the loopback host in makeProjectEnv (mirroring the
existing HOST and standalone.json's entry.env) so any server reading
process.env.HOSTNAME binds the address the harness actually probes. js-next-ssr
now validates via `start` (live SSR), not the static fallback.
Verified: full framework suite 14 pass / 0 fail and standalone 3 pass / 0 fail
on EdgeJS V8 WASIX, no regressions vs Node.js.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Arshia001
force-pushed
the
eco-416-framework-parity
branch
from
July 28, 2026 14:57
0a3e9ba to
6921727
Compare
syrusakbary
approved these changes
Aug 7, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes the last framework-lane gap between the V8-imports (WASIX) lane and the QuickJS lane.
What
framework-test-v8-wasix: dropFRAMEWORK_TEST_EDGE_SKIP='js-etherpad'.standalone-build-test-v8-wasix: dropFRAMEWORK_TEST_EDGE_SKIP='js-next-ssr,js-next-standalone'.--quiettowasmer runon both V8 lanes (spinner must not pollute captured output).NODE_SKIP— those fail to build on the Node.js reference itself (build tooling); the QuickJS lane skips them identically.scripts/framework-test.js): pinHOSTNAMEto the loopback host inmakeProjectEnv.Why it works now
This rides on top of two already-landed ECO-416 fixes: GuestHeap (removed the copy-layer corruption — the "binary-garbage-as-JSON" failures) and the N-API import-layer WASI-exit re-raise (fixed etherpad's unclean exit). Together they let all edge apps run at parity.
The
js-next-ssrharness bugUnskipping
js-next-ssrsurfaced a latent harness bug. The Next.js standalone server bindsserver.listen(port, process.env.HOSTNAME). The runner forwards the ambient machine HOSTNAME into the guest, but that name does not resolve inside the WASIX guest (its mounted/etc/hostsonly knowslocalhost) and on a Debian/Ubuntu host resolves to127.0.1.1, not the127.0.0.1the harness polls. So the server bound the wrong address / hung on the lookup, and the harness fell back to serving the static export instead of live SSR.Fix: pin
HOSTNAMEto the loopback host (mirrors the existingHOSTandstandalone.json'sentry.env).js-next-ssrnow validates viastart(live SSR), not the static fallback.Verification
js-etherpad,js-next-standalone,js-next-ssrall validate viastart.Dependency
Requires a
wasmerprovisioned from this ECO-416 stack (napi #47 → wasmer #6829), same as the sibling edgejs PRs. Stacked on #131 (eco-416-pseudo-tty).🤖 Generated with Claude Code