{{ message }}
Repository navigation
Track Virtual Workspace Support for Extension Authors #123115
Description
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.
Metadata
Metadata
Assignees
Labels
No labels
Activity
DanTup commentedon May 7, 2021
I have a question about the general expectation for language support in this feature. It seems like there are two possible routes:
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 commentedon May 7, 2021
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 commentedon May 7, 2021
In the hex editor when doing
vscode.workspace.fs.stat(uri)on newly created files the size will always be 0. Howevervscode.workspace.fs.readFile(uri)will return the correct bytes. /cc Kai Maetzel (@kieferrm) Who was seeing an issue because of this.majastrz commentedon May 8, 2021
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 commentedon May 8, 2021
LSP and the virtual workspace are related to
feat: support virutal workspaces (microsoft/vscode#123115)
alefragnani commentedon May 9, 2021
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
engineentry onpackage.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
capabilitiesentry topackage.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 commentedon May 10, 2021
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 commentedon May 10, 2021
Alessandro Fragnani (@alefragnani) Updating the engine is not necessary, unless you also use new VSCode API from
vscode.d.ts.DanTup commentedon May 10, 2021
Martin Aeschlimann (@aeschli)
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
anyand 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 commentedon May 11, 2021
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 commentedon May 11, 2021
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 commentedon May 11, 2021
Do you have any plans to define a new
virtual workspace readykeyword 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
3 remaining items
DanTup commentedon May 18, 2021
Yep, that makes sense. Here I was just wondering about handling the case where a user has an old Dart SDK (where the LSP server didn't correctly handle non-file URIs) and wanted to warn them if they had a virtual workspace (but wasn't sure if it was safe to only do at startup or it could occur later).
Perfect, thanks!
I'm still interested to know what the plan is for TypeScript. Dart is similar in many ways and if TS decides full support is not feasible, I suspect the same would be true for Dart. If TS decides it's possible (which presumably involves sucking
node_modulesinto the server via the client) then that suggests Dart could do similar. It's hard to justify putting too much work into trying to support a virtual filesystem in the language server without some better ideas about the intended direction/expectations of this.brettfo commentedon May 20, 2021
Are extensions always running with the
file:scheme? Specifically, willExtensionContext.globalStorageUrialways be local? If not, what's the guidance for extensions that need to unzip external tools to the local disk and invoke them withchild_process.spawn()?aeschli commentedon May 21, 2021
Yes, the globalStorageUri remains a
fileuri and you can spawn external tools. Just the workspace resources are virtual, so maybe the spawned tool might not know how to deal with a virtual resource URL.alefragnani commentedon May 22, 2021
I'm updating an extension to not support virtual workspaces, but it seems the Debug Session does not respect that
capabilitiesflag.I mean, I added
"virtualWorkspaces": falseto thecapabilitiesproperty inpackage.json, but whenever I run a debug session and connect to some Virtual workspace, the extension remains enabled.The only way I could test my extension was packaging and installing the
.vsix.Is debugging really not supported, or should I open an issue for you to take a look?
Thank you
aeschli commentedon May 25, 2021
Alessandro Fragnani (@alefragnani) Looks like a bug, please open a separate issue.
bmewburn commentedon May 31, 2021
Is there a particular URI scheme that virtual workspace folders will have?
alefragnani commentedon May 31, 2021
Hi Ben Mewburn (@bmewburn) ,
Yep, it is defined as
vscode-vfs.Hope this helps
aeschli commentedon Jun 1, 2021
vscode-vfsis just the one we use for RemoteHub, but others are possible too. It's everything exceptfileandvscode-remoteDavidAnson commentedon Jun 1, 2021
Martin Aeschlimann (@aeschli) It would be nice to have the schemes defined in the .d.ts so extensions don’t need to hardcore strings. It would also be nice to have helpers like “isVirtual” for dealing with this. Similarly, a table of behaviors would be instructive - I’m not sure my code handles -
vscode-remotecorrectly as this is the first I’ve seen it.alefragnani commentedon Jun 1, 2021
Martin Aeschlimann (@aeschli) , do you have plans/scenarios for other so-called virtual workspaces that are not related to RemoteHub?
I mean, up until Virtual Workspaces came out (last release), I only had to deal with
vscode-remotescheme, which is used by Docker, SSH, WSL, and more recently Codespaces. In this case, I'm only talking about the native remotes.David Anson (@DavidAnson) , Totally agree. Right now I have a few mapped on my extensions for specific scenarios I had to take care, like
untitled,search-editor-body,vscode-remoteandvscode-vfs.aeschli commentedon Jun 2, 2021
vscode-remoteyou will only see if your extension needs to run on the UI side (extensionKind: 'ui'). By default extensions run on the machine where the workspace is and therefore see only 'file' URIs.Then there are 'untitled' URIs for new, unsaved files. And then there are file system providers that are contributed by extensions and can be many things.
We call them all virtual.
alefragnani commentedon Jun 2, 2021
Just out of curiosity, what was the main reason to create the new
vscode-vfsscheme, instead of usingvscode-remotewith a different authority, like happened with Codespaces?A lot of recommendations you see in the guide above also applied to remotes, and I guess (based on my extensions at least) if your extension works on remotes (
extensionKindasui), it may work out of the box with Virtual Workspaces.Sure, I’m probably not seeing all the complexities under the hood (in fact, I’m pretty sure 😬) , but I was wondering if it wouldn’t make extensions to support it with no changes at all.
Thank you
aeschli commentedon Oct 21, 2021
The guide now moved to the docs: https://code.visualstudio.com/api/extension-guides/virtual-workspaces
Closing the tracking issue now. Please create an issue if you have any requests on virtual workspaces.