feature: Support for the Debug Adapter Protocol

[rubenfiszel]

Our users would like a debugger. I figured since monaco-languageclient is mostly vscode at this point it might not be too hard but wanted to have your opinion on the matter, how hard would it be to make pydebug and bun-debug work with monaco-languageclient. I was thinking it could use the same approach of json-rpc over websockets.

[CGNonofr]

While the language client protocol relies on an external libraries (vscode-languageclient), the debug adapter protocol is built-in in the VSCode extension API.

You can have a look at the demo of monaco-vscode-api, this file in particular: https://github.com/CodinGame/monaco-vscode-api/blob/main/demo/src/features/debugger.ts and the server: https://github.com/CodinGame/monaco-vscode-api/blob/main/demo/src/debugServer.ts

[rubenfiszel]

@CGNonofr just to be sure, is the conclusion of your answer that it wouldn't be very hard?

I can see in the code that for instance it launches a docker container (https://github.com/CodinGame/monaco-vscode-api/blob/main/demo/src/debugServer.ts#L10) etc which assume it's a local vscode. How hard would it be to only retain the socket client part and launch the server part separately and connect it using websocket so that we can have a debugger "in the browser".

[CGNonofr]

@CGNonofr just to be sure, is the conclusion of your answer that it wouldn't be very hard?

Indeed

Just be aware that to be able to use all the features the debugger have, you'll also need some VSCode components (the call stack, the console...)

I can see in the code that for instance it launches a docker container (https://github.com/CodinGame/monaco-vscode-api/blob/main/demo/src/debugServer.ts#L10) etc which assume it's a local vscode.

Not sure what you mean by local vscode, that's the server part that need to run on a machine

How hard would it be to only retain the socket client part and launch the server part separately and connect it using websocket so that we can have a debugger "in the browser".

That is EXACTLY what I've mentioned is doing

[rubenfiszel]

Just be aware that to be able to use all the features the debugger have, you'll also need some VSCode components (the call stack, the console...)

How would one enable that with the current components from this repo?

(Thanks a lot for the answers)

[CGNonofr]

The simplest way is to take the whole VSCode workbench, using the workbench service override

Otherwise, you can use the views service override, which allows to render the sidebar/panel part the way you want

There is currently no way to render specifically a component

[rubenfiszel]

Sent email but putting discussion back here at @CGNonofr request:

At Windmill, we would be very interested to make an open-source POC of having the https://github.com/microsoft/debugpy and bun debugger work with "monaco-editor": https://bun.sh/guides/runtime/vscode-debugger

It would likely be enough for us to have a working example similar to the examples you have already on the monaco-languageclient repo.

@CGNonofr replied:
Are you expecting it to run fully in the browser? What is your use-case?

---

We do not need the server to run in the backend, we can have it be routed using websocket to a separate backend, that's already what we do on: https://github.com/windmill-labs/windmill/blob/main/lsp/pyls_launcher.py

We do not need every features, the more the merrier but breakpoints with context would already be amazing.

This is what https://app.windmill.dev looks like:

and being able to add breakpoints and the vscode context panel would be really cool. Maybe a REPL if possible but not necessary.

[CGNonofr]

Having breakpoints in the editor and being able to hover variables to get its value is easy.

You also can configure the debug toolbar to be floating to make it appears on screen.

The context panel would require to use VSCode components though. Another solution is to re-code it yourself, based on the VSCode services I guess.

[kaisalmen]

@rubenfiszel I will work on this next week. #784 needs to finished first.

[rubenfiszel]

Hi @kaisalmen , let us know if you'd like to sync about it but super excited to follow the progress and collaborate on this

[kaisalmen]

Hi @rubenfiszel I wanted to get this done and finally release new major versions before end of November, but that didn't work (things took longer, not enough time for OSS). I planned it for this week and that was realistic time-wise, but a hand injury unfortunately prevents me from doing coding/computer work this week.
I want to get this done before Christmas (this and the final releases), but I need to re-asses time available for OSS work next week. I should be able to work normally again next week and come back to you.

[kaisalmen]

Hey @rubenfiszel I have started to look into this / make up my mind yesterday. I think it makes most sense to demonstrate a python debugger (and this is also in line with your initial request/question). The monaco-vscode-api demo uses a JavaScript debugger based on GraalVM and it I think we can use graalvm/graalpy running in a Docker container similarly here.

What I am not so sure about is how much we can generalize the client part. This remains to be seen once I put everything together.

Timewise:

1. We should get final versions of the major lib versions out of the door first. They are overdue. The only blocker is the peer dependency issue. I hope to come up with an idea there (release either Friday or early next week).
2. Afterwards, I will implement this and if necessary release x.1.y version if any things are missing to make it work (next week). For any other missing feature on our idea list this must be done similarly, too.

WDYT?

[rubenfiszel]

Yes that'd be awesome. Once there is a v0 working, I think it will be much easier for everyone to contribute on smaller parts and understand the limitations and requirements.

[kaisalmen]

@rubenfiszel new major versions are finally available (see also #809 (comment)). The peerDependencies issues was more work than expected.