Consider dropping the "light" PHP build

[adamziel]

Playground ships three PHP builds:

• CLI
• Web – with extensions ("kitchen sink")
• Web – without extensions ("light")

With the upcoming JSPI support we'll have to ship twice the .wasm binaries – one set built with JSPI for the runtimes that support it, and another set built with Asyncify for the browsers that don't. That's 48 binaries instead of the 24 we have today. That's a lot! It's a build time burden and the disk space burden.

What if we dropped the "light" build entirely? WordPress doesn't work correctly with it, which makes it useful for extreme compatibility testing but not so useful for most real world scenarios. JSPI will unlock dynamic extensions loading so eventually we'll be able to ship a barebones version of PHP and load as many extensions as needed.

Questions to answer:

• How many people actually use the light build?
• Is it by accident, or do they rely on it?

cc @brandonpayton @bgrgicak @eliot-akira

[eliot-akira]

For my use case (in-company dev tools), mostly we've been using the server-side modules @php-wasm/node and cli.

• PHP parser for gathering docblock comments to generate documentation
• PHP linter and formatter (Code Sniffer with custom WordPress Code Standards)
• A fork of wp-now with small feature to load mapping paths from .wp-env.json (compatibility with existing setup)

As for the web build of PHP-WASM, I have a side project of a custom self-hosted Playground site, but that's fallen behind recent upstream development - it's using the "kitchen sink" variant.

I'm also exploring the use of GitHub Pages to embed a Playground instance that runs a plugin at the newest commit, using github-proxy.com. So far I'm using the default settings, which is apparently the "light" variant according to the API docs for getPHPLoaderModule.

In all cases, if the default and only variant changed to "kitchen sink", it would be better and backward compatible.

[bgrgicak]

I would remove the light package. We want Playground to be compatible with a regular LAMP server and disabling features that we support doesn't make a lot of sense except if you really want to reduce the size. Even the size matters less now when we have caching because it happens only once (until an update is available).

Here are some usage stats.

The Website reports that 1.3% of Playgrounds are loaded with the light PHP build.

[adamziel]

Oh nice, I'm glad we're collecting that information. I would assume a part of that 1.3% are stale Blueprints and maybe even documentation examples. I would love to hear more from the people who are intentionally using the light build, but reaching them might be quite difficult. Let's prepare a PR, then, write a make.wordpress.org/playground post and share it on the w.org slack before merging.

[adamziel]

PR ready: #1861