Debug extension priority

[zobo]

When creating a launch.json to debug a program, the type field lets the user tell what "language" they are debugging.
Debugging extensions register this via debuggers.type contribution point.

If there are there are multiple extension that register the same debugger type, the first will (probably) be selected in alphabetical order.

Is there a way for the user to explicitly tell what extension to use for a conflicting debugger type? Maybe a setting could be used to override this?

Ref: xdebug/vscode-php-debug#905

[roblourens]

This is a problem that shows up in a lot of extension API, the result is sometimes basically undefined behavior, because we don't really want this situation to happen and hope that extensions will try to pick a unique ID.

How long have these two extensions had this conflict? Can users just disable the one they are not using?

[zobo]

Hi Rob!
There is some more context on the linked issue, but I should have explained the problem a bit better.

1. If you develop an extension to debug PHP, you will hardly pick any other type than php. Potentially, if I can register more type names, I could add xdebug and dbgp - but that could cause even more conflicts since dbgp is a protocol that can be used in more languages...
2. Even though xdebug.php-debug only provides debugging functionality, the other extension offers a bunch of things (I think it includes, debug, LSP, tests and more), so by disabling that, you loose all of it. Seems that some users would still prefer to use the official debug extension - and are surprised by this behavior.

Ideally each function would be packed into a small extension (allowing the user to pick between different providers) but at the end this is the authors choice. And not an unusual one, as can be seen with other commercial or big-company backed extensions (like Dart/Flutter, JS, TS...).

A solution I can imagine for this is that the user can set a setting where they define what extension ID is used for a certain debug type.
Even better, when functionality from a debug extension is needed (launch.json snippets, session start...) and there are completing extensions, the user gets a picker - if the setting isn't set already.

I think that if extensions have other conflicts - like define settings with same names - the user gets an error while extension loading.

I don't know if there were any other cases like this before, but ultimately it should be the users word at the end.

[roblourens]

Ideally each function would be packed into a small extension

I definitely agree

but at the end this is the authors choice

alas, you're right

JS, TS...

js-debug is a clean single-purpose extension, language features and other tools come in other extensions, fwiw

Do you think that we could bring this up with the devsense maintainers to have them consider forking the debug feature into a separate extension? They can bring it along with their PHP extension using an extensionPack so users won't miss anything, but would be able to separately disable that debug extension. I would strongly prefer this to coming up with a setting for this scenario.

[VSCodeTriageBot]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!

[zobo]

Sorry, could not get to this before. I will try to reach out.

[zobo]

Hi @roblourens !

Hopefully I can recycle this issue if not, I'll open a new one. I exchanged some ideas with the Devsense maintainers DEVSENSE/phptools-docs#355 and there were some ideas I'd love to get your input on.

One was to use a when inside the contributes.debuggers. Would that be possible? I was not able to find a documentation reference...

The other is if the authors decide to split the extension up. Could they add a extensionPack entry to the main (LSP) extension manifest and a extensionDependencies to their subordinate debugger extension manifest? Or is there a better way to do it?

Also what would be the best way for those two extension to communicate. I listed some ideas in the linked issue. If you have any extra input here.

Last and most ideal for us would be if VS Code could handle this the same way that it handles code formatters. If there are multiple, the user gets a dialog. I'm guessing picking one of the DAPs for the specified debugger type wouldn't be such a big deal, but I can't imagine what to do with all the other debugger related VS Code APIs inside those extensions then. And the host of things that come with a typical DAP package.json manifest...

I understand this is probably a first and also very uncommon situation we are discussing here so I don't expect much effort to go into this. Maybe a small step could be to show a notification to the user on startup that there are two conflicting extension registering for a certain debugger type. I can offer to look into implementing this as a POC and see where and if we go from there.

[roblourens]

One was to use a when inside the contributes.debuggers. Would that be possible? I was not able to find a documentation reference...

Yes, this is supported and would totally be possible

The other is if the authors decide to split the extension up

That is another valid option. The Python extension is actually in the process of doing this. They have different motivations but it's the same idea, the debugger will have its own extension. You might take some inspiration from them https://github.com/microsoft/vscode-python-debugger

Last and most ideal for us would be if VS Code could handle this the same way that it handles code formatters

I don't see it as the same situation. Having multiple code formatters for a language is normal and expected but overloading debug IDs shouldn't happen regularly.

Maybe a small step could be to show a notification to the user on startup that there are two conflicting extension registering for a certain debugger type.

I don't know what the user would be expected to do about this. I'd prefer that we just address this case. If UX is needed to guide the user maybe it should come from one of the extensions.

[zobo]

Yes, this is supported and would totally be possible

Great, will let the devsense authors know this could be the way.

That is another valid option. The Python extension is actually in the process of doing this. They have different motivations but it's the same idea, the debugger will have its own extension. You might take some inspiration from them https://github.com/microsoft/vscode-python-debugger

Also great, will try to look at that and point out how they are doing it.

I don't see it as the same situation. Having multiple code formatters for a language is normal and expected but overloading debug IDs shouldn't happen regularly.

Valid point.

I don't know what the user would be expected to do about this. I'd prefer that we just address this case. If UX is needed to guide the user maybe it should come from one of the extensions.

Follow up question. How can an extension know there is a "competing" extension for the same debug type? I can't seem to find a suitable VS Code API.
I can imagine doing a very specific lookup like vscode.extensions.getExtension('xdebug.php-debug') !== undefined but is there a better way?

Thanks!

[roblourens]

I don't think there's really any way to know for sure.

[syafiq90]

I am experiencing a similar issue where "devsense.com" in the VSCode extensions is consuming up to 5GB of memory on my M1 Mac and causing faster battery drain than usual. The process name in Activity Monitor is "devsense.php.ls". Please review the memory usage of this extension and consider optimizing it.

[roblourens]

You can file an issue on the devsense extension for that.

[VSCodeTriageBot]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!