What are the best practises behind the usage, debug and production of GLSP Client/Server

[YHAMSTM]

Hello there,
My current goal is to work and extend the capabilities of both the client and the server.
I am currently working around GLSP Client/Server implementation in VS Code, and I am facing troubles while trying to debug the client content.
I am doing the same way as I did when working with GDB DAP (cdt-gdb-adapter) which is

• Installing both GLSP Client/Server dependencies
• Start yarn in watch mode
• Starting GLSP Server (Node Server) in VS Code Editor
• Starting GLSP Client (VS Code Extension)

Server works as expected, but some parts of the client are not able to break.
Did I miss something in the setup ?

EDIT: looks like some parts on the server are not breakable as well...

Best regards,
Yanis

[tortmayr]

Hi @hamitiya-STM

Server works as expected, but some parts of the client are not able to break.

The debugging setup is a bit tricky here. Most of the client code is loaded in via webview. Since a webview is part of the frontend process of VS Code it cannot be debugged in the standard way (i.e. by setting break points in a source file). Instead you have to use the Developer Tools in the VS Code runtime instance (i.e. the new instance that opens when you use the Workflow GLSP Example launch config). The developer tools can be opened via menu ( Help -> Toggle Developer Tools) or with the Ctrl+ Shift + I keyboard shortcut.
Here you can search for source files via Ctrl+P and add your breakpoints.

[YHAMSTM]

Thanks for your answer. Yes it is what I'm doing when debugging with Webviews in general.
But on my side, this code appears as minified. My issue is related to the build side I suppose ?

[tortmayr]

Yes, I would assume so. From what you are describing I hues that the sourcemap support in your webpack.config isn't configured properly and so you only can debug the bundled js file.

In order debug the .ts sources you have to set the devtool option to source-map or source-map-eval and need to configure a sourcemap loader for your *.js files (https://github.com/eclipse-glsp/glsp-vscode-integration/blob/855391037088c3f516094b27d8a9b9fb9d3b6857/example/workflow/webview/webpack.config.js#L15)

[YHAMSTM]

Not sure why it was different on my side, but it works now ! Thanks for your fast replies !

[YHAMSTM]

On the same part, if I take this line for example: (on the server side)

    protected loadFromFile(url: URL): GModelRoot {
        try {
            const fileContent = this.readFile(url);
            if (!fileContent) {
                return EMTPY_ROOT;
            }
            if (!isSModelRootSchema(fileContent)) { // this one
                throw new Error('The loaded root object is not of type SModelRootSchema');
            }
            return this.modelSerializer.createRoot(fileContent);
        } catch (error) {
            throw new GLSPServerError(`Could not load model from file: ${url}`, error);
        }
    }

When I break on this line and do a Step-In, I am redirected to the minified version, even if a source-map is available. Is this something you are experiencing as well ?

[tortmayr]

Unfortunately we don't have an example up and running that integrates a glsp vscode extension with the node server framework so I cannot test this. Debugging in the workflow-example sources of glsp-server-node works fine for me, but that is expected because we don't bundle the workflow example server with webpack so there are no minified sources.