Consider offering debugger as a separate extension

[zobo]

Hi all.

I maintain vscode-php-debug and occasionally get issues, where it turns out users have installed both extensions and end up using the debugger implementation from this extension. Since both extensions register the same debugger type - in this case behavior in vscode is undefined - I have no option to help those users. Aside from asking them to disable this extension, where they loose all the other functionality with it.

I believe the correct way would be to provide the debugger as a separate extension and bring it in with an extensionPack. This would allow users to selectively enable or disable them, but would easily be installed with the main extension.

Would you consider such a change?

Thanks and all the best.

[kanlukasz]

I have the same opinion about this. This should be separate extensions.
An extension pack should be created and this may be an alternative if someone needs all of them

[jakubmisek]

@zobo @kanlukasz Thank you for the suggestion! Yes, that would make sense.

Technically, our debugger implementation uses many features from the language server (it analyses side-effects of evaluated expressions, avoids evaluating dangerous code in tooltips, provides debug inline values, provides completion in the Watch panel, integrates with .phar files, and more). So that makes it pretty dependent on our PHP extension. Also together it has a lower startup footprint.

Splitting the extension in two is possible (they would need to communicate through VS Code API). Still, Debug extension alone (without the PHP extension) would lack essential features. From experience, I would expect a lot of users will complain that it doesn't work as advertised ...

I'd rather be looking for some VSCode setting, that would allow specifying the preferred debug extension (the same as they have it for specifying preferred code formatter).

[jakubmisek]

got it - we can have a setting that would disable/enable our debugger. package.json > "debuggers" has "when" property we can take advantage of. We can also automatically disable our debugger if there is another php debugger installed.

[zobo]

Hi @jakubmisek thanks so much for getting back on this!

I completely understand - and know - that enhancing a DAP only debugger extension requires support from a LSP extension (most notably the mentioned inline value providers as well as evaluatable expression providers) so having your debug extension without the "main" one would make no sense.
I just want to point out some mechanisms you could use if you'd decide to split them up.

The debugger part could define a extensionDependencies directive in the manifest, making it so that it would not start without the main extension.
Since both extensions would guarantied be active you could use the getExtension method to directly reach the main extension exported methods without much VS Code API overhead.
You are probably right about a separate extension causing a bit more startup time, but since most of the code there (I guess) is just registration of on demand callbacks that should not have such a large impact.

I'm not sure about where inside contributes, I have not seen or tested such. However I'd bet you register a bunch of debugger specific providers and those would need to be disabled as well as they could conflict with a different debugger type DAP implementation.

In the end I agree with you that ideally this would be something VS Code handles to some extent, code formatters for example.

I'll reach back out to Microsoft see if we can get any guidance how to best approach this issue.

[zobo]

Got some interesting feedback from Microsoft regarding this situation. Apparently one approach would be to use a variable as you suggested - not sure yet how to detect that there is another extension registering the same debug type - or a split, the same way python debugger is doing.