While not mounting / makes sense and indicates an obvious problem, won't this create another problem where XDebug won't be see the project files? Which means breakpoints won't work? It sounds like we need a way of passing the PHP site path to withXdebug() so it can be used instead of process.cwd(). WDYT?

@adamziel that was my initial thought when looking at the changes, but I am able to debug with the packaged version of Studio and using npm start in Studio. According to Claude:

NODEFS mount is not needed because:

1. WordPress is written to /wordpress/ in MEMFS
2. Xdebug reports /wordpress/... paths
3. IDE path mapping handles translation

So maybe we could remove phpRuntime.FS.mount?

EDIT: I have tested locally removing that mounting (commit 2fbf899) and debugging works fine for me using PHPStorm, I can add breakpoints and step through the code. Should I push the changes for review?

This is weird! I remember we've tweaked this exact mount specifically to get the path mapping to work. Or was it the path mapping in the browser devtools and not in the IDE? 🤔 In which case we're missing a unit test to keep that part working. Let's get some input from @mho22 or @brandonpayton here.

@adam @epeicher Before Xdebug 3.5, path mapping didn't exist and absolute paths were used to make Xdebug step debugging find files, this means PHP.wasm virtual filesystem needs to mount the current working directory to create these absolute paths. That is why we run :

with-xdebug.ts on line 89 :

phpRuntime.FS.mkdirTree(process.cwd());
phpRuntime.FS.mount(
    phpRuntime.FS.filesystems['NODEFS'],
    { root: process.cwd() },
    process.cwd()
);
phpRuntime.FS.chdir(process.cwd());

But this could probably be replaced by IDEs path mappings and Xdebug 3.5 path mappings. I am currently working on an exploratory pull request.

In the meantime we could merge this since it won't break the previous behavior and avoid breaking the Electron one. But this doesn't mean Xdebug will work correctly in Electron without IDEs path mappings.

Edit: It seems a patch has been merged on Studio waiting for this issue to be fixed but we still can merge this one.

Thanks for explanation and for merging this @mho22!

It seems a patch has been merged on Studio waiting for this issue to be fixed but we still can merge this one.

Yes, that's right, we merged a patch to this package to unblock the XDebug timeout for the release, but we plan to delete it after upgrading to this version.