Run JSPI in Node.js

[adamziel]

JSPI landed in trunk in both @php-wasm/web and @php-wasm/node packages. I couldn't figure out how to enable JSPI support in Node.js, though. It worked back in #1339 with the following CLI flags, but it doesn't work anymore:

$ node --experimental-wasm-stack-switching ./test.js

$ node --experimental-wasm-jspi ./test.js

Could that be related to the new JSPI API in v8? That would be weird, though, because WebAssembly in either case the WebAssembly object doesn't expose any JSPI-related keys – new or old. There's no Suspending, Function, Suspender, and anything else:

> WebAssembly
Object [WebAssembly] {
  compile: [Function: compile],
  validate: [Function: validate],
  instantiate: [Function: instantiate],
  compileStreaming: [Function: compileStreaming],
  instantiateStreaming: [Function: instantiateStreaming]
}

Once we can running the JSPI build in the CLI, we'll be able to check how many new plugins can be installed compared to the Asyncify build:

https://github.com/bgrgicak/playground-tester/

cc @bgrgicak @brandonpayton

[adamziel]

The experimental flags work in Node.js. It's just Node won't display WebAssembly.Suspender or WebAssembly.Function when logging the WebAssembly object. It seems like Node.js v22.9.0 still implements the older JSPI specification. I can call these just fine:

new WebAssembly.Suspender();
new WebAssembly.Function();

But the ones from the new JSPI API fail:

new WebAssembly.Suspending();
WebAssembly.promising()

Node.js v22 LTS is stuck with the current v8 release:

As v22 will get stuck with V8 v12.4 as LTS, it will be increasingly difficult to backport patches for them even if the bugs are fixed.

This means we can either wait for Node.js v23 (scheduled for release on Oct 15) and hope it will ship the latest v8 version, or we can build JSPI binaries for Node.js using the older API.

I'd say let's wait for Node.js to catch up. Any code we write to support the older API will take time to write and we'll have to undo it in a few months anyway. Patience is the key.

[adamziel]

I just confirmed Node.js v23 nightly supports the latest JSPI API!

[adamziel]

I just triggered the unit tests using this command and a lot of them passed 🎉

$ ~/Downloads/node-v23.0.0-nightly2024100909d10b50dc-darwin-x64/bin/node --experimental-wasm-jspi --experimental-wasm-stack-switching --expose-gc node_modules/nx/bin/nx run php-wasm-node:test

There were some failures, though. Both ones that we can safely ignore, such as

   ❯ src/test/php-crash.spec.ts > PHP 7.0 – process crash > Does not crash due to an unhandled Asyncify error
     → php.run should have thrown an error

And ones we'll need to look into:

   ❯ src/test/php-request-handler.spec.ts > PHPRequestHandler – Loopback call > Spawn: exec() can spawn another PHP before the previous run() concludes
     → expected 'Starting: <br />\n<b>Warning</b>:  ex…' to deeply equal 'Starting: Ran second.php! Done'
   ❯ src/test/php-request-handler.spec.ts > PHPRequestHandler – Loopback call > Loopback: handler.request() can be called before the previous call concludes
     → expected 'Starting: <br />\n<b>Warning</b>:  ex…' to deeply equal 'Starting: Ran second.php! Done'
stderr | src/test/php-crash.spec.ts > PHP 8.1 – process crash > Does not crash due to an unhandled non promise err

   ❯ src/test/php-networking.spec.ts > PHP 8.3 > should be able to make a request to a server
     → expected '<br />\n<b>Warning</b>:  file_get_con…' to deeply equal 'response from express'
   ❯ src/test/php-networking.spec.ts > PHP 8.3 > cURL > should support single handle requests
     → Test timed out in 1000ms.
If this is a long-running test, pass a timeout value as the last argument or configure it globally with "testTimeout".
   ❯ src/test/php-networking.spec.ts > PHP 8.3 > cURL > should support multi handle requests
     → Test timed out in 1000ms.
If this is a long-running test, pass a timeout value as the last argument or configure it globally with "testTimeout".

[brandonpayton]

Nice work here!

❯ src/test/php-networking.spec.ts > PHP 8.3 > cURL > should support single handle requests
→ Test timed out in 1000ms.

It seems unlikely that this failure is due to a long-running test, but maybe it would be worth increasing the timeout to check.

See:
"JSPI much slower than Asyncify on asynchronous JS to WebAssembly calls"
https://issues.chromium.org/issues/41491351

[adamziel]

#1876 should do the trick

[adamziel]

Fixed in #1876. The next released packages will support JSPI.

[adamziel]

The latest @wp-playground/cli release supports JSPI on node.js v23 with the experimental flags. This runs without any issues:

~/Downloads/node-v23.0.0-nightly2024100909d10b50dc-darwin-x64/bin/node --experimental-wasm-jspi --experimental-wasm-stack-switching  ./cli  server

There isn't yet an easy way of checking which build are we running. It would be cool to add a line to phpinfo().

cc @bgrgicak I'm really curious how many more plugins would now insta..

[adamziel]

@wojtekn this would make Studio much more stable with MySQL - no more WASM crashes

[bgrgicak]

cc @bgrgicak I'm really curious how many more plugins would now insta..

I need to spend some time making the test runner scalable and adding support for different tests.
Adding JSPI support sounds like a good way to do that. After it's working well we could provide a straightforward way for others to add more tests in the future.