I didn’t put up an update or made any releases for a while, but that doesn’t mean nothing was going on. Here is the current release cycle cover GitHub issue. But the most important change was the migration of the extension.

The migration

Just when the year turned to 2022, I wanted to make a small release since I had prepared a PR. However what I saw was that the Personal Access Token (PAT) used to deploy the extension was expired. It felt that this was a good excuse to try to solve one outstanding issue that was left after the code was migrated from Felix Becker’s GitHub account to Xdebug.

The extension still used felixfbecker publisher ID, that I did not have access to. I could not look at the stats under Marketplace, nor answer Reviews.

The weeks long effort was coordinated by VS Code PM - Isidor Nikolić - and at the very end, both php-debug and php-pack extensions were moved under Xdebug marketplace publisher.

I want to say again, what a great codebase Felix left and what a good learning experience this was for me.

PHP IntelliSense

One other unrelated thing is that I took over the PHP IntelliSense extension, also from Felix. The extension was delisted from the Marketplace and I have re-published it under my own publisher after fixing some basic problems that came with more recent PHP versions.

I will take time and write about it some time later, but let’s say it is a very interesting piece of code. The Language Server is written in PHP and the functions are exposed via Language Server Protocol (LSP) to the extension.

While this brings some benefits it also has downsides. I intend to make it more stable, improve caching of language data and make it more compatible with latest PHP. One thing I’d really like to do is make the extension aware of different PHP levels. We’ll see how it goes.

Merge environment

This was a very interesting one. I was aware of it, but not how it actually affected things. It started with a GH issue where a user complained that Launch currently open script doesn’t work. It can’t find his php binary. I tried to reproduce the issue on my PC and then on my Mac, but couldn’t.

As it turns out, I did not have the exact same conditions. The user had his php binary in a non standard place. But that should be accessible from PATH?

The Node.js docs read:

The command lookup is performed using the options.env.PATH environment variable if it is in the options object. Otherwise, process.env.PATH is used.

I guessed this means, that if the provided options.env had the PATH key it will be used, if not, it will fallback to process.env.PATH.

However digging through all the code I realized this is actually delegated to the OS via the execvpe or execvp system call. And the man states there that if there is no PATH in the provided environment it will fall back to some default /usr/bin:/bin. Since the executable was in that particular path on my system, I never felt the problem.

This also led me to suggest a documentation change in the Node.JS project.

Set Variable support

This was a very old PR created by Felix. With some updates and minor changes, VS Code PHP Debug now supports changing variables.

Evaluatable improvement

If you tried to evaluate variables by hovering over them in the code you will see that they more often than not don’t work. The reason for that is that VS Code, by itself, doesn’t understand PHP code really well.

Extensions can help by implementing the Evaluatable Expression Provider. This gets triggered when the user hovers over code and tells the debugger what to evaluate.

The proper implementation would be to implement this as part of the language extension. This is because the language extension should “understand” the code, where as the debug extension doesn’t have that information.

Nevertheless I decided to implement basic support directly in php-debug, since I don’t know how many people have both installed.

Luckily, PHP isn’t that complex and looking at the documentation, one can relatively simply extract variable names from text.

Sadly the RegEx abilities of JavaScript can’t compare to PCRE and so the current implementation lacks a lot and will be updated as soon as possible.

Auto configuration

Parts of the auto configuration logic were updated. First the existing php.executablePath setting was renamed to php.debug.executablePath because if conflicted with the one from PHP IntelliSense.

This setting is used when you run a script and don’t define explicitly what runtimeExecutable to use. If this setting is not set, the extension falls back on the PATH. If even that fails, you get a message and link to settings.

DBGP Proxy Support

One feature that was pending for a long time is the DBGP Proxy Support. If you are running the DBGP proxy you can instruct the extension to register with it when you start debugging. Here is the default configuration.

The only thing that needs to be set is the enabled key. The key setting is, by default, retrieved from php.debug.ideKey VS Code settings.

Conclusion

Ping me on Twitter or GitHub issues if you have problems or questions. The configuration of the extension is very flexible and can adapt to all sorts of strange environments. I’m planning to create a set of documentation pages that explain more in detail how it can be used in different setups. I’m always happy about feedback and would always like to know how to make debugging experience better. I’m currently focusing on Xdebug Cloud support.

Also if you use the extension and it makes your life easier consider donating via GitHub Sponsors.