Track Virtual Workspace Support for Extension Authors

[aeschli]

This issue tracks progress on the Virtual Workspace Support for Extension Authors and helps with the adoption.

• Read the Virtual Workspace Extension Author Guide.
• Post questions and requests is this issue.
• Subscribe this issue and check back. We post here if new information is added to the guide.

[DanTup]

I have a question about the general expectation for language support in this feature. It seems like there are two possible routes:

1. Language servers only operate on the file content they know about (eg. in the case of LSP, files that have been opened and the server notified of their contents)
2. Language servers "crawl" files as necessary (via VS Code) to analyze the whole project/workspace (or at least, the things reachable from the open file(s))

It's not very clear from the published info which of these is the goal. The first one seems like it will result in a poor experience (for example, code completion or analysis won't work for anything imported from other files that haven't been opened). The second seems like it would just be a worse version of cloning the repo locally and then opening that (because everything would be slower, and running/debugging won't work).

Knowing what the user expectations will generally be in these workspaces would definitely help understand the best direction for language support. Thanks!

[jakebailey]

This got mass posted to us, but for Pylance, we can't really make use of this because the VS Code FS abstractions are not a part of the LSP; this sort of makes this feature problematic in the same way that remote SSH filesystems and such break. Given the proliferation of LSs, I'm not sure how well things are going to work without an LSP change to add some sort of VFS API.

[lramos15]

In the hex editor when doing vscode.workspace.fs.stat(uri) on newly created files the size will always be 0. However vscode.workspace.fs.readFile(uri) will return the correct bytes. /cc Kai Maetzel (@kieferrm) Who was seeing an issue because of this.

[majastrz]

For Bicep, it's the same as Pylance. We rely heavily on our language server, so we would have to be disabled or run with almost no functionality outside of the TextMate grammar.

[tamuratak]

LSP and the virtual workspace are related to

• Provide guidance how language servers should support Virtual Workspaces #123025
• Proposal: Allow a language server to provide a reference content for a specific uri scheme language-server-protocol#336

[alefragnani]

I have asked this on the issue that was opened on my repo, but maybe this could be useful for other extension developers too.

I miss the information (on that Author Guide) if I also need to update the engine entry on package.json. I guess no, but if yes, to which value (1.56 or 1.57 for to be in the Insiders).

I didn't have to do anything to the extension properly activate while connected to some Virtual Workspace (while debugging) but I'm asking this because I'm worried if, for any reason, I update the extension to support Virtual Workspaces (adding that capabilities entry to package.json) but the user remains with older releases of VS Code (prior to 1.56), which does not recognizes that, and the extension does not activate for any reason.

Thank you

[aeschli]

What are the expectations for language support with virtual workspaces?

Limited functionality is fine. The language extensions that ship with VSCode (TypeScript, JSON, CSS, HTML) just look at the open text document ('single file only').

[aeschli]

Alessandro Fragnani (@alefragnani) Updating the engine is not necessary, unless you also use new VSCode API from vscode.d.ts.

[DanTup]

Martin Aeschlimann (@aeschli)

Limited functionality is fine. The language extensions that ship with VSCode (TypeScript, JSON, CSS, HTML) just look at the open text document ('single file only').

Is it likely they will remain that way or is this just an intermediate step? There's a comment at #123025 (comment) suggesting LSP is getting virtual-FS support, so I'm still fairly confused which direction to take (I think the implementations of this would be quite different depending on whether it should use a full virtual filesystem versus just working on simple overlays/buffers for the existing open files so it's helpful to know how VS Code is present this to users).

I presume the single-file TS support won't have access to anything in node_modules, so most symbols will just be any and get no analysis/completion? This seems like a poor experience, but then, proxying the filesystem through the client over to GitHub also seems like it would be a poor experience.

[DavidAnson]

Similar to the LSP scenario above, what's the expectation for a linting tool in this context? The "single file only" model proposed above is convenient (and now works in a private branch for markdownlint), but that means any custom linting configuration won't be applied and the resulting warnings will be inconsistent vs. when opening the same file from the file system. For example, imagine ESLint requiring trailing semicolons or forbidding them depending on whether a file is virtual or not. The rules for loading configuration may be complex (i.e., not just a single file in the workspace root and possibly hierarchical), so scanning the virtual file system may not be practical.

What's the intended behavior? Will users be conditioned to expect that everything (language extensions, linting, etc.) is always a little wonky when using the virtual file system? Or will they consider such behavior bugs such that extensions end up disabling support because it's impractical to match non-virtual behavior?

[aeschli]

Is it likely they will remain that way or is this just an intermediate step?

We anticipate that only few language extensions will be able to work fully on a virtual file system. Most languages and language extensions use libraries and tools that do not have an abstraction of a file system and depend on synchronous file accesses. That's regardless of LSP adding the support for file systems.

We are looking into UI to signal users, that on this workspace some extensions are deactivated or work with limited functionality.

[alefragnani]

Do you have any plans to define a new virtual workspace ready keyword to be used for the Marketplace, just like you did when multi-root was released (https://github.com/microsoft/vscode/wiki/Adopting-Multi-Root-Workspace-APIs).

I would say the same idea could be expanded for the Workspace Trust feature, which is being tracked for extension authors in #120251

Thank you