--target web: codegen diverges based on `file:` dep path — strips FFI imports OR emits invalid WASM (#687 stack fallthru)

[proggeramlug]

Summary

On perry compile --target web, Perry's output diverges dramatically depending on whether the file: dependency path in package.json points inside or outside the project root. The same source tree, same perry 0.5.178, same engine produces two different broken builds:

package.json bloom dep	modules found	wasm size	ffi imports	WASM valid?	runtime behavior
"file:./vendor/bloom/"	1 native	216 902 B	9	✅ OK	runs but every bloom/core-wrapped call silently no-ops (see below)
"file:../engine/"	10 native	413 500 B	140	❌ FAIL	WebAssembly.compile(): Compiling function #687 failed: expected 0 elements on the stack for fallthru, found 130

Real-world impact: Bloom Jump (the game) uses the first path in CI → ships to https://bloomengine.dev/jump/ as a white screen, because runGame(callback)'s bloom_run_game FFI import was stripped.

Repro

Project layout:

• src/main.ts — imports runGame, initWindow, loadSound, … from "bloom/core", "bloom/audio", etc., plus declares some bloom_* functions directly (declare function bloom_load_texture(...)).
• package.json — has one dependency: "bloom": "file:<path>".
• perry.toml — standard project config.

Compile the identical src/main.ts twice, only changing package.json's bloom dep path:

A. "bloom": "file:./vendor/bloom/" (engine cloned/symlinked into vendor/bloom/ inside the project)

$ perry compile --target web src/main.ts -o out
Found 1 module(s): 1 native, 0 JavaScript
Generating WebAssembly...
WASM output: out.html (715.7 KB)

$ wasm-tools dump out.wasm | grep -cE 'module: "ffi"'
9

The only ffi imports emitted are the 9 declare function bloom_*(...) in main.ts. Every FFI call routed through the bloom/core (and sibling) module's re-exports (runGame → bloom_run_game, initWindow → bloom_init_window, loadSound → bloom_load_sound, getPlatform → bloom_get_platform, …) is stripped. WASM compiles and runs, but the affected calls silently do nothing — in the jump game, runGame's web branch never registers a frame callback, so the canvas stays blank and the game never starts.

B. "bloom": "file:../engine/" (engine living outside the project)

$ perry compile --target web src/main.ts -o out
Found 10 module(s): 10 native, 0 JavaScript
Generating WebAssembly...
WASM output: out.html (1232.2 KB)

$ wasm-tools dump out.wasm | grep -cE 'module: "ffi"'
140

$ node -e 'WebAssembly.compile(require("fs").readFileSync("out.wasm")).catch(e => console.log(e.message))'
WebAssembly.compile(): Compiling function #687 failed: expected 0 elements on the stack for fallthru, found 130 @+408287

Perry now discovers all 10 bloom submodules and emits 140 ffi imports — correct. But the resulting WASM function #687 has a stack-fallthru validation error, so the browser refuses to instantiate the module. (The exact "found N" count varies with engine state: 130 with my local engine checkout, 103 with a fresh origin/main clone.)

Expected

Both paths should produce the same valid WASM — either both with the full 140 imports, or both with the subset that survives DCE, but with consistent DCE such that the game's call graph isn't partially severed.

Environment

• perry 0.5.178 (tested perry-macos-aarch64, perry-macos-x86_64; CI uses perry-linux-x86_64, same symptoms per the deployed artifact)
• Project: https://github.com/Bloom-Engine/jump
• Engine: https://github.com/Bloom-Engine/engine (tested both origin/main fresh clone and a local checkout — both trigger B's codegen bug)

I can hand over the full compiled out.wasm files from both A and B if that helps diagnose — just point me at where to drop them.

Workaround

None from the jump side that I've found:

• Adding declare function bloom_run_game(callback: number): void; + bloom_run_game(cb as any) directly in main.ts does get the import emitted under path A — but only under path B (which then hits the #687 codegen bug).
• Rewriting every bloom/core call as a direct declare function in main.ts would require ~30 declarations and still only fixes path A.

The fix needs to land in Perry's web-target codegen.

[proggeramlug]

Fixed in v0.5.205 via d639688 — the #687 stack-fallthru error was caused by JS-style "extra args silently ignored" semantics meeting WASM's strict call arity rule: every direct-Call site in crates/perry-codegen-wasm/src/emit.rs (Expr::Call FuncRef, Expr::Call ExternFuncRef, Expr::New user-class ctor, Expr::SuperCall, Expr::StaticMethodCall) padded UP with TAG_UNDEFINED when args.len() < expected but lacked the mirror drop-excess branch. Extras evaluated past the callee's declared param count leaked onto the enclosing block's operand stack and accumulated until _start's final end tripped the validator. Fix is one for _ in expected..args.len() { Drop } loop after each existing pad-up loop.

Verified in current main (v0.5.261) — all 5 sites still carry matched pad-up/drop-excess pairs.

The path A module-discovery divergence (1 module + 9 FFI imports) reported alongside the WASM bug couldn't be reproduced in a fresh clone of bloom-engine/jump + bloom-engine/engine — most likely an artifact of the local vendor/bloom snapshot at the time, and the visible "every bloom/core call silently no-ops" symptom was the browser refusing to instantiate the invalid WASM with the surrounding JS glue swallowing the error. If path A reproduces again in a fresh repo, please file a follow-up.