Debugging on windows : Node + VSCode bug

[mikael-desharnais]

Hi folks,

For a few days we've been facing a bug in our Theia extension development process and we found out that it is related to a Node "feature" and the way VSCode works. I would like to have opinions on how to solve this issue because I've reached the end of my ideas.
Here is the situation :

• We have built our development environment using the yeoman extension generator : The theia packages are located in the node_modules folder and our extension elsewhere.

• In our extension, we use the ConnectionHandler variable available in @theia/core/lib/common and we add our own JsonRpcConnectionHandler in order to communicate with the backend.

• We are working on windows and the problem is present with both Node 10 & 12

In this situation, when we start the browser backend from command line with yarn run start, everything works fine. If we start it from VSCode using the start debugging button, we get the "Cannot find a service for the path: /services/xxxxx" error message and of course the extension does not work.

My investigations led to the following conclusions :

• Node JS is case sensitive for its access to the filesystem (on all OSes including Windows) (it was reported in this thread and is not considered a bug : fa71e1b)
• VSCode goes for lower case when starting a debug session so I get a call that looks like node.exe c:\Users\xxxx\examples\browser\src-gen\backend\main.js
• When the basic theia packages import the ConnectionHandler it comes from a file located on c:... and when my extension (located outside of node_modules) does the same, it comes from a file located on C:/...

In conclusion, what happens is that the @Theia\core\src\common\messaging\handler.ts gets imported twice so the ConnectionHandler can have two different values depending on where you import it from and so when I inject my ConnectionHandler, it ends up in a different slot then the ones injected by modules that are in node_modules. In the end I get the error message above.

The problem is created by a combination of factors :

• We are working on windows (I wish we could do otherwise)
• NodeJS has this specific feature of being case sensitive when working on windows
• VSCode goes for lower case when the rest of the system clearly goes for upper case
• It may happen that theia & custom extensions do not live in the same folder and end up with different filename resolution in NodeJS

I do not get this problem when I work with the official repo which has all its extension living in the packages folder.
I do not get this problem when I change my launch.json file to
"program": "${workspaceRoot}/node_modules/@theia/cli/lib/theia.js", "args": [ "start", "--port=3000", "--no-cluster", "--app-project-path=${workspaceRoot}/browser-app", "--plugins=local-dir:plugins", "--hosted-plugin-inspect=9339" ],
In this case, I use the same entry point then the command line. The theia.js script then creates a child proccess using only "main.js" (without any disk letter reference) and so the system goes for upper case which solved the problem. Debugging with this solution works only with VSCode 1.47+ because it has a new debugger that tracks child processes and allows debugging them (not as well as the parent process because the internal nodeJS code does not support breakpoints). If the solution is to go for this modification, we could do a pull request to change the launch.json file both for the theia repo and the yeoman generator.

Thanks for reading until this point & thanks for your ideas if you have any.

[akosyakov]

Do you mean that ${workspaceRoot} variable while resolving should respect case sensitivity of the OS? What do you want to change in the theia repo? PR probably would make it more clear.

[mikael-desharnais]

At the moment, I was able to analyse the "bug" but I am unable to propose a solution. It is a combination of a several logics that not compatible, Windows with its non-case-sensitive FS, nodeJS with its case sensitive logics & VS Code with a case choice that is not the windows default one.
I'm not even sure that something can be done in Theia itself to solve the problem.
If somebody else can reproduce the problem and confirm my analysis, we could then publish a warning for all windows developers.

[MikaelDesharnais-ST]

Here is a patch that I can propose to solve this issue :

index 62304ebaa..d306a6f12 100644
--- a/dev-packages/application-manager/src/generator/backend-generator.ts
+++ b/dev-packages/application-manager/src/generator/backend-generator.ts
@@ -78,6 +78,28 @@ module.exports = (port, host, argv) => Promise.resolve()${this.compileBackendMod

     protected compileMain(backendModules: Map<string, string>): string {
         return `// @ts-check
+if (process.platform === "win32") {
+    var l1 = process.argv[0][0]; var l2 = process.argv[1][0]; var ll1 = l1.toLowerCase(); var ll2 = l2.toLowerCase();
+    let requiresOverride = l1 != l2 && ll1 == ll2;
+    if (requiresOverride) {
+        let adaptDiskLetter = l2 == ll2 ? "".toUpperCase : "".toLowerCase;
+        let adaptPath = (path) => {
+            return !path ? path : adaptDiskLetter.apply(path.substr(0, 1)) + path.substr(1);
+        };
+        var Module = require('module');
+        Module.prototype.require = new Proxy(Module.prototype.require, {
+            apply(targetMethod, targetObject, argumentsList) {
+                targetObject.filename = adaptPath(targetObject.filename);
+                targetObject.path = adaptPath(targetObject.path);
+                targetObject.paths = targetObject.paths.map((path) => adaptPath(path));
+                targetObject.require = targetMethod;
+
+                return Reflect.apply(targetMethod, targetObject, argumentsList);
+            }
+        });
+        console.warn("Overriding NodeJS require method : OS=Windows + (" + l1 + "!=" + l2 + "&&" + ll1 + "==" + ll2 + ")");
+    }
+}
 const { BackendApplicationConfigProvider } = require('@theia/core/lib/node/backend-application-config-provider');
 const main = require('@theia/core/lib/node/main');
 BackendApplicationConfigProvider.set(${this.prettyStringify(this.pck.props.backend.config)});

I've tested it on a few different comouters and it seems to work. At the moment, I cannot propose a PR because my company does not allow me to do so. It should be OK by september.

[kittaakos]

@mikael-desharnais, can you share an example repo that I can try to debug on Windows? Just to see if I can reproduce the Cannot find a service for the path: /services/xxxxx error.

[MikaelDesharnais-ST]

@kittaakos Yes, I'm going to create a basic demo repo.
Should be done by the end of the day.

[MikaelDesharnais-ST]

@kittaakos : Here it is :
https://github.com/MikaelDesharnais-ST/minibug
It is a very simple repo built using the yeoman extension generator.

[kittaakos]

This should fix your debugging issue on Windows:

diff --git a/.vscode/launch.json b/.vscode/launch.json
index 63be103..be833d0 100644
--- a/.vscode/launch.json
+++ b/.vscode/launch.json
@@ -14,6 +14,12 @@
                 "--port=3000",
                 "--no-cluster"
             ],
+            "windows": {
+                "env": {
+                    "NODE_ENV": "development",
+                    "NODE_PRESERVE_SYMLINKS": "1"
+                }
+            },
             "env": {
                 "NODE_ENV": "development"
             },
@@ -33,6 +39,10 @@
             "name": "Start Electron Backend",
             "runtimeExecutable": "${workspaceRoot}/node_modules/.bin/electron",
             "windows": {
+                "env": {
+                    "NODE_ENV": "development",
+                    "NODE_PRESERVE_SYMLINKS": "1"
+                },
                 "runtimeExecutable": "${workspaceRoot}/node_modules/.bin/electron.cmd"
             },
             "program": "${workspaceRoot}/electron-app/src-gen/frontend/electron-main.js",

See #3590 for more info.

[MikaelDesharnais-ST]

Indeed, your solution works just fine and is way better than mine.
Maybe we could create a PR ?

[xai]

Hi!

I came across this post because we are currently facing the same issue with Theia extensions in Windows. We use the NODE_PRESERVE_SYMLINKS workaround mentioned here as well but for us it leads to a situation where breakpoints no longer bind in the browser backend.

I also created a minimum example from a yeoman generator and added a simple backend contribution. In Windows, the backend code would not run when the launch configuration is started unless the NODE_PRESERVE_SYMLINKS workaround is applied (see this branch). Unfortunately, now the code runs but breakpoints in my backend contribution do not bind anymore.

@paul-marechal has also quickly looked into the matter together with @sdirix (on a different example) but I think there were problems reproducing the issue in the end.

I also tested the patch from @MikaelDesharnais-ST from this thread and it works for me - code runs and breakpoints bind.

Is merging the patch an option or is there something else I could try?

[xai]

Actually by now I am pretty sure the whole issue is a vscode js-debugger issue and should be adressed there in the first place. I think I can provide a patch for the js debugging extension and we hopefully can get rid of the NODE_PRESERVE_SYMLINKS thing again.

[paul-marechal]

The only difference we could find between the Theia instances when running from a normal terminal versus from VS Code's debugger is that the latter injects a script before running the actual JS program to debug. This is done via the NODE_OPTIONS environment variable, and it seems to inject a minified version of the following script: https://github.com/microsoft/vscode-js-debug/blob/v1.56.2/src/targets/node/bootloader.ts?

[xai]

Current status is that we created an issue and a PR in the js-debugging extension. If someone else is currently having these kind of issues in Theia projects, I would be interested if the patched debugging extension is resolving the problem in those cases. Also, many thanks to @mikael-desharnais and also @paul-marechal for the thorough investigation and your effort on this!