-
Notifications
You must be signed in to change notification settings - Fork 28.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Track Virtual Workspace Support for Extension Authors #123115
Comments
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 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 Thank you |
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'). |
@alefragnani Updating the engine is not necessary, unless you also use new VSCode API from |
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 |
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 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? |
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. |
Do you have any plans to define a new 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 |
Thanks for the clarification - although I'm still a little unsure. For some languages (for example Dart) it might be possible to run entirely from a virtual filesystem but it would involve effort (to support remote and async filesystems). Whether that's worthwhile will depend on how common this scenario is and whether users would expect it. TypeScript is a good example that's probably fairly similar to Dart (it likely needs lots of info from Thanks! |
Some additional questions:
|
@DanTup Yes, of course a local folder could be added, which could turn The virualWorkspace capability in the |
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 |
Are extensions always running with the |
Yes, the globalStorageUri remains a |
I'm updating an extension to not support virtual workspaces, but it seems the Debug Session does not respect that I mean, I added The only way I could test my extension was packaging and installing the Is debugging really not supported, or should I open an issue for you to take a look? Thank you |
@alefragnani Looks like a bug, please open a separate issue. |
Is there a particular URI scheme that virtual workspace folders will have? |
Hi @bmewburn , Yep, it is defined as Hope this helps |
|
@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 - |
@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 @DavidAnson , Totally agree. Right now I have a few mapped on my extensions for specific scenarios I had to take care, like |
|
Just out of curiosity, what was the main reason to create the new 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 ( 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 |
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. |
This issue tracks progress on the Virtual Workspace Support for Extension Authors and helps with the adoption.
The text was updated successfully, but these errors were encountered: