Support wp-cli in the browser

[adamziel]

What is this PR doing?

Adds wp-cli support in the browser!

This PR brings parts of #161 by @swissspidy into trunk to enable using wp-cli in the browser.

Codebase changes

• setSapiName method for PHP. wp-cli expects to see the exact string "cli" as the SAPI name.
• All PHP versions are now built with phar support.
• js_open_process is asynchronous via Asyncify. This is to enable calling setSpawnHandler(handler) from the parent site to set a handler in an asynchronous web worker. Unfortunately, using the Comlink messaging library is challenging with complex objects like spawn handlers so this PR ships a workaround where spawn handlers are passed as strings and eval()-ed in the worker. This shouldn't have any security implications as Playground enables evaluating arbitrary code by definition.
• proc_open waits for the process to spawn, and proc_close waits for the process to die. This is necessary to support the wp-cli behavior of piping its output through a pager program (like cat or less -S).

Follow-up work

• Remove eval() from setSpawnHandler(handler). Setting spawn handler works in Node.js where PHP runs synchronously in the same process, but these spawn handlers are challenging to transfer over postMessage as they're essentially composite EventEmitters that need to accept input inside the Worker process, handle it in the client process, and transmit it back to the worker process. Intuitively, it would be pretty easy if we used MessagePort directly. It seems like Comlink as an abstraction layer makes things much easier to a point, since we can magically call functions on objects living in another thread, but there's a boundary beyond which Comlink makes these API interactions more difficult.

cc @danielbachhuber @schlessera

[swissspidy]

There's a bunch of warnings, but it works! I suspect the warnings are related to PHP 8.2. There's a chance they wouldn't be there on PHP 8.0 or 7.4.

It's odd that you are seeing messages about missing ReturnTypeWillChange attributes, because those methods in core definitely do have these attributes. So this should not be happening at all.

[schlessera]

However, the help message doesn't show up as wp-cli pipes it through a pager – less -S in this case. less is not available in the browser so we must handle that on our side.

WP-CLI's behavior for this can be controlled via the standard POSIX PAGER environment variable. This means you can add whatever binary you want to use for output and have WP-CLI pipe everything through it via PAGER=<binary>. A simplified version could be PAGER=cat wp --help, for example.

[adamziel]

It's odd that you are seeing messages about missing ReturnTypeWillChange attributes, because those methods in core definitely do have these attributes. So this should not be happening at all.

Aha! I bet the minification (that runs on PHP 7.4) thinks those attributes are comments and it removes them.

[adamziel]

WP-CLI's behavior for this can be controlled via the standard POSIX PAGER environment variable. This means you can add whatever binary you want to use for output and have WP-CLI pipe everything through it via PAGER=. A simplified version could be PAGER=cat wp --help, for example.

In the browser we have neither so setting the PAGER is just choosing a different name for a custom callback handler we still have to provide. Once WASI is more baked out we should be able to use the actual pager binary, though!

[adamziel]

It took me the entire day but I figured it out. proc_open needs to wait for the process to spawn, and proc_close needs to wait for the process to terminate. I just pushed a code change that does that (and fixes proc_get_status() cc @mho22). Next week I'll fix the tests and hopefully land this PR!