Path conversion for windows and posix file systems

[msujew]

What it does

Closes #10552

Enables to convert URIs in the frontend to a file system path independent of the frontend OS (unlike vscode-uri.fsPath). This can be used to display backend paths, such as the file paths of opened editors in the title property.

How to test

This one is a bit difficult to test. The easiest setup would be to run Theia on a Unix machine and access the browser version on Windows.

---

1. Open a file in the editor. The title (hover display) of the file node should always display the correct backend path. I.e. C:\file\to\path.txt on windows and /path/to/file.txt on Unix.

---

0. Start Theia on a different OS than your frontend OS.
1. Download and install this extension (source)
2. Open the context-menu for package.json files which contain a dependencies section. The Install Dependencies menu entry should be visible.
3. Confirm that other configurations (electron/windows/unix) work as expected

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• As a reviewer, I agree to behave in accordance with the review guidelines

[msujew]

cc @bd82 @ChayaLau Since you were part of the discussion in #10552, I would like you to have a look at this, and whether it fixes your issue. It works on my end at least :)

[bd82]

Thanks @msujew

At the moment we have a workaround and also had the internal feature that needed the fix/workaround reduced in priority
So I am unsure when we will get around to testing it 😢

[msujew]

@bd82 Not a problem, I actually tackled this issue due to something different that I noticed, it just also fixes the issue you were experiencing ;)

[colin-grant-work]

@msujew, it looks like you could import isWindows from core/src/common/os.ts rather than relying on the ApplicationServer. That would give you what you need synchronously rather than waiting on a Promise.

[paul-marechal]

Except isWindows will give the OS of the running browser here, and not the remote backend? Not sure which one makes more sense here, but they aren't the same.

[msujew]

@colin-grant-work Exactly as @paul-marechal is saying, in this case we need the backend OS, since it specifies the string format of all file paths (forward- vs. backward-slashes, drive letters in front, etc.). The whole reason why this bug exists, is that the frontend and backend might convert the same URI into different strings, which would then result in a mismatch of the when context property of commands.

In particular, when we have something like resourcePath in ext:pkgJsonWithTestScript as a context, the monaco frontend on windows will convert the current resourcePath into something like \user\settings.json, while the posix backend path is actually using /user/settings.json. Monaco will then perform an in check on the ext:pkgJsonWithTestScript object, which will fail.

[colin-grant-work]

I suppose then I wonder whether we shouldn't make retrieving information about the backend OS part of the pre-load startup routine so that we can then access it synchronously from inside the application? That would alleviate some of my anxiety about race conditions.

[msujew]

@colin-grant-work Care to take another look at this? I also opened #10830 to keep track of all misusage of URI#path.toString().

[colin-grant-work]

@msujew, I've got a brand-new Windows system I should be able to test this on, so I'll take another look today :-)

[colin-grant-work]

The changes work for me in various combinations of Linux and Windows servers and browsers. My only comment is about the asynch retrieval of the backend OS, which is probably fine but could potentially go wrong. If it's impractical to make the check synchronous while the application is running, then I'm fine with the current implementation.

[msujew]

@colin-grant-work Alright, I did some larger refactoring for getBackendOS(), and now we preload the backend OS in the same step we also load localizations. That allows for sync access on the backend type. Is that more how you imagine it should work?

[colin-grant-work]

@msujew, I missed this review request - sorry; I'll take a look today.

[colin-grant-work]

The functionality continues to work, and the move to a preloader makes this code cleaner, cleans up a few other areas, and opens up a lot of possibilities (e.g. preferences) so that's a definite 👍. One or two minor things that you can address or leave, as you choose.