Conversation
Since d937c8c ("wasm: enable JSPI") ProcessGlobalArgsInternal() unconditionally appends --experimental-wasm-jspi to the V8 argument list. V8 only defines the experimental_wasm_* flags when it is built with V8_ENABLE_WEBASSEMBLY, and configure --v8-lite-mode sets v8_enable_webassembly=0. V8::SetFlagsFromCommandLine() is called with remove_flags=true, which silently leaves unrecognized flags in argv, so node reports "bad option: --experimental-wasm-jspi" and exits with kInvalidCommandLineArgument. The first binary to run that code is node_mksnapshot, so every --v8-lite-mode build has failed since v24.20.0: bad option: --experimental-wasm-jspi node_mksnapshot failed with exit code 9 Forward v8_enable_webassembly to all targets as V8_ENABLE_WEBASSEMBLY, the same way common.gypi already forwards the other V8 build flags, and only push the JSPI flag when WebAssembly is compiled in. Refs: nodejs#59941 Assisted-by: claude:fable-5.1 Signed-off-by: Piotr Kubaj <[email protected]>
|
Review requested:
|
|
Welcome to Node.js, and thank you for your first contribution! Before review, please take a moment to read:
Please make sure every commit is signed off. For a first pull request, GitHub Actions require collaborator approval and Jenkins CI must be started by a collaborator or triager, so an initial wait is normal. Caution AgentScan found account activity patterns that may be consistent with automation. This is a heuristic, not proof that this pull request was opened by an agent or violates policy. AI-assisted contributions are permitted, but automated tooling must not open pull requests without advance approval, and contributors must personally understand, test, verify, and take responsibility for every submitted change. See the AgentScan analysis, AI use policy, and automation policy for additional context. |
Since v24.20.0 (backport of #59941)
ProcessGlobalArgsInternal()pushes--experimental-wasm-jspiunconditionally. With./configure --v8-lite-mode,v8_enable_webassemblyis 0, V8 is built withoutV8_ENABLE_WEBASSEMBLY, andthe whole
experimental_wasm_*flag block inflag-definitions.hdoes notexist.
V8::SetFlagsFromCommandLine()is called withremove_flags=true, whichsilently leaves unknown flags in
argv, so node reports them as bad options andexits with
kInvalidCommandLineArgument. The first binary to run that code isnode_mksnapshot, so every lite-mode build fails:This forwards
v8_enable_webassemblyto all targets asV8_ENABLE_WEBASSEMBLY, the same waycommon.gypialready forwards the otherV8 feature defines, adds the
%default the file needs for node-gyp, and onlypushes the JSPI flag when WebAssembly is compiled in. V8's public headers do not
reference
V8_ENABLE_WEBASSEMBLY, so defining it for node's own sources doesnot affect the V8 API.
--v8-lite-modeis not covered by CI, which is why this was not caught.Verification
./configure --v8-lite-mode(thewww/node24port with theJIToption off):node_mksnapshotnow succeeds and the build completes;node -p 'typeof WebAssembly'printsundefinedas expected for lite mode.node -p 'typeof WebAssembly.Suspending'still prints
function, so JSPI remains enabled.AI disclosure
The root-cause analysis and the patch were drafted with Claude (Anthropic's
coding agent). I verified the analysis against
deps/v8/src/flags/flag-definitions.h,deps/v8/src/flags/flags.cc,configure.pyandtools/v8_gypfiles/features.gypi,and build-tested both configurations listed above myself.
Refs: #59941