PHP: Do not pull WebGL in Playground web

[adamziel]

Motivation for the change, related issues

Only uses -s MAIN_MODULE when building for Node.js+JSPI to fix a crash in the web version of Playground.

#2248 added -s MAIN_MODULE to the main emcc call linking the final PHP.wasm file. It worked fine in Node.js, but on the web, after rebuilding with recompile:php:web:jspi:8.4, Playground threw a ReferenceError: document is not defined.

It turn out, -s MAIN_MODULE pulls in a pile of extra libraries in case some dynamically loaded lib needs them. One of them was webgl that assumes globalThis.document exists – hence the error. See this Emscripten thread for more details.

Implementation

Moves -s MAIN_MODULE to platform-only flags for Node.js+JSPI.

I've tried switching to -s MAIN_MODULE=2 as suggested in the mailing lists. It fixes it for the web build, but it breaks loading XDebug.so in Node. The error says missing export type for core_globals. I assume we need to pull in some additional dependencies and declare them explicitly.

Remaining work

Rebuild all the PHP versions – Node.js and Web – and confirm the tests pass

---

Unrelated – I've noticed to patch with-xdebug.ts as follows to be able to run it from source:

diff --git a/packages/php-wasm/node/src/lib/xdebug/with-xdebug.ts b/packages/php-wasm/node/src/lib/xdebug/with-xdebug.ts
index 3b40aa2b3f..41fec3d237 100644
--- a/packages/php-wasm/node/src/lib/xdebug/with-xdebug.ts
+++ b/packages/php-wasm/node/src/lib/xdebug/with-xdebug.ts
@@ -17,7 +17,11 @@ export async function withXdebug(
        }
 
        const fileName = 'xdebug.so';
-       const filePath = await getXdebugExtensionModule(version);
+       let filePath = await getXdebugExtensionModule(version);
+       if (filePath.startsWith('file://')) {
+               filePath = filePath.substring(7);
+       }
+
        const extension = fs.readFileSync(filePath);
 
        return {

cc @mho22 @zaerl

[zaerl]

I've tested on web and CLI, and everything is working. 👍

[adamziel]

Thank you!

[mho22]

@adamziel I am currently trying to reproduce the issue you had a couple days ago :

Unrelated – I've noticed to patch with-xdebug.ts as follows to be able to run it from source:

-       const filePath = await getXdebugExtensionModule(version);
+       let filePath = await getXdebugExtensionModule(version);
+       if (filePath.startsWith('file://')) {
+               filePath = filePath.substring(7);
+       }
+

I achieved to reproduce the issue with this command :

node --experimental-wasm-jspi --loader=./packages/meta/src/node-es-module-loader/loader.mts packages/php-wasm/node/src/lib/xdebug/test.ts

where my test is simply :

import { withXdebug } from "./with-xdebug";

withXdebug( '8.3', {} );

However, I found out the error occurred because the loader added file:// to the path I return with the following code at line 120 :

const specifierUrl = new URL(specifier, 'file://');
for (const format of ['raw', 'json', 'url']) {
	if (specifierUrl.searchParams.has(format)) {
		// This is a custom format import and can be handled by our custom loader.
		return {
			url: specifierUrl.href,
			format,
			shortCircuit: true,
		};
	}
}

So we have two solutions here :

1. I apply what you suggested in the with-xdebug.ts file and add a comment to explain why.
2. I customize the ?url in ?import-url or something to separate the Vite ?url behavior from our custom plugin.

Even if these solutions are temporary, because I guess we will soon propose a better feature based on this issue, I would like to suggest the second solution to avoid any questions about that particular behavior when using a loader.

What do you think about that ?

[adamziel]

I agree, thank you for good investigation!