Open rubenfiszel opened 5 months ago
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
@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 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
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)
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
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.
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.
@rubenfiszel I will work on this next week. #784 needs to finished first.
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.