How to enable extensions in VS Code workspace?

[Greenheart]

How to make extensions like Prettier work in a collaboration session? Also, Go to definition and TypeScript intellisense don't work as expected.

When joining a session, a virtual workspace is created at ~/.config/Code/User/globalStorage/typefox.open-collaboration-tools/workspaces/Oe49SfaBFj0I09GZ_0cXPE9l/Open\ Collaboration.code-workspace:

{
  "folders": [
    {
      "name": "<project-name>",
      "uri": "oct:/<project-name>/<project-name>"
    }
  ]
}

According to VS Code command Workspace: Manage Workspace Trust, it says "This window is trusted".

However, VS Code extensions only work for the session host - not for the participants. This makes it seem like the workspace is in fact not trusted.

Alternatively, this might be caused by the virtual workspace oct:/<project-name>/<project-name>. Perhaps VS Code only allows extensions to run on local files, and not custom protocol URIs.

It might be worth exploring how VS Code LiveShare solved this. Perhaps they use an actual directory synced to the participant computer, which enables extensions?

[msujew]

Hey @Greenheart,

I can't reproduce this issue with the TypeScript extension in VS Code. The extension works as expected, given that there is no disk access that the extension can use to provide all the workspace information. It will mainly use the information that is available in the currently open files:

(screenshot showing working TypeScript intellisense for a guest of a workspace)

It might be worth exploring how VS Code LiveShare solved this. Perhaps they use an actual directory synced to the participant computer, which enables extensions?

AFAIK Live Share also provides a purely virtual file system. I did a bit of reverse engineering when I started with this project. But they also do a lot of Microsoft magic that non-Microsoft extension developers aren't allowed to use (i.e. proposed VS Code API).

Perhaps VS Code only allows extensions to run on local files, and not custom protocol URIs.

That's entirely up to the extension, whether it supports virtual files. I've implemented extensions in the past that can do both.

[Greenheart]

Thanks for the investigation!

Examples of what is not working

Correction: I can confirm TypeScript intellisense works in .ts files. However, it does not work in .svelte files (where the TypeScript intellisense is supported by the svelte.svelte-vscode VS Code extension v109.11.1 and the Svelte language server). Similar problems happen in .astro files, using the astro-build.astro-vscode VS Code extension v2.15.4.

In other words, the TypeScript intellisense works in .ts and .js files, but not in other filetypes where TypeScript is used.

In the Extensions panel, searching for @workspaceUnsupported shows that the TypeScript and JavaScript Language Features extension (built-in by vscode) is limited in virtual workspaces. On the extension details page there is a warning showing "In virtual workspaces, resolving and finding references across files is not supported.". This might be causing problems for Svelte and Astro because they likely use this feature of the TS extension. In Live Share sessions, both Svelte and Astro work as expected.

Prettier formatting

Formatting with Prettier behaves differently compared to Live Share. There seems to be a conflict between the extensions provided by the session host, and the extensions of participants. For example:

1. Participant formats a file with Prettier, which saves the changes first locally and then sends it to the OCT session host.
2. On the host computer, the code is formatted again (seemingly using a different config), which gives a different result and causes the code to flicker between the two different versions. This code is saved for the session host, becoming the source of truth which is synced back to participants.
3. Back on the participant computer, the code flicker back and forth, and results in "unsaved changes" in the editor.

Workspace Trust investigation

We thought workspace trust might be behind the problems, but then we disabled it by setting "security.workspace.trust.enabled": false in the User settings.json. However, the extensions still didn't work as expected.

There is a difference in how Live Share and OCT handles trusted workspaces. Live Share creates a temporary directory on the participant's computer which can be added as a trusted workspace. OCT only creates a virtual workspace but no directory. This makes the participant see the workspace as "trusted", but it's not added to the list of trusted directories. It seems like VS Code does not recognise the oct:/<project-name>/<project-name> path, and this might cause the extensions to misbehave.

Questions for further investigation

• Would VS Code extensions work better if OCT used a temporary directory for each participant, similarly to how Live Share implemented this?
  • Would this also resolve the warning for the TS/JS language features? ("In virtual workspaces, resolving and finding references across files is not supported.")

[msujew]

I see, thanks for the info. I'll take a closer look at this in the upcoming days.

Formatting with Prettier behaves differently compared to Live Share. There seems to be a conflict between the extensions provided by the session host, and the extensions of participants.

I would assume that the guest version of the extension isn't really aware of the config file (due to the lack of a real file system), which results in the flickering.

[msujew]

I just took a look at the TypeScript extension source code, and found something interesting. It seems like the extension isn't actually active when the workspace is using the vsls (Visual Studio Live Share) URI scheme. Instead, the live share extension itself is registering all the language services, which it then resolves using the host machine. See this example from the deobfuscated completion provider:

Image

We already had in mind to implement something similar soon - I've created #164 to track this. It's something I should be able to work on this in the next few weeks.

[Greenheart]

That's a really interesting find - nice work! 😄

the live share extension itself is registering all the language services, which it then resolves using the host machine

This makes sense. The TS language server and prettier formatting are both significantly slower in Live Share sessions with bad network connections. Likely because of the network round trip.

When adding these capabilities to OCT, it's worth exploring what kind of data various language services and editor extensions pass back and forth. Luckily most extensions and language services are open source and could be adapted to work within OCT sessions. The most important one to start with is probably the TS/JS language services.

Perhaps the OCT protocol could have a generic format that supports several types of language services and editor extensions. Basically allowing participants to interact with the language services and editor extensions on the host machine. For example, formatting with Prettier or getting the latest state from the TS language service on the host.

However, we would have to be very careful to only expose limited capabilities to reduce the risk of security issues.

Suggested workaround in the meantime:

Could the OCT VS Code extension disable unsupported extensions for participants in OCT sessions? With prettier disabled, session participants would not see the flickering. Since the host machine usually has "formatOnSave" enabled, the formatted result would still be transferred back to session participants whenever anyone saves files.

Alternatively, problematic extensions could be documented, and encouraging session participants to disable these extensions. It could be as simple as Extensions and Language services don't work completely as expected, followed by a list of extensions to manually disable. This could be removed for the 1.0 release in the future.