search

microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
164.19k stars 29.29k forks source link

Manage special defaults of the `virtualWorkspaces` property #122836

Closed egamma closed 3 years ago

egamma commented 3 years ago

Extensions have started to adopt the new Virtual Workspace capability: Guide, Tracking Issue

Until extensions have adopted the new capability, we came up with an internal list of extensions that we think should be disabled in virtual workspaces. The list that is reflected in product's project.json.

The issue is used to keep the list updated. We can remove extensions as a soon as they adopted the virtualWorkspaces property.

rebornix commented 3 years ago

@aeschli from the release note that it seems we generated list by checking if an extension is using fs. Do you have an idea how this will impact Vim. Vim's desktop version uses fs but it can work with a virtual file (textDocument). Asking as the wiki link is not valid yet.

egamma commented 3 years ago

@rebornix @aeschli has started to update the guide https://github.com/microsoft/vscode/wiki/Virtual-Workspaces and there is more info available.

Just to share what I've found when I did the initial checking of the Vim extension. I found that it works OK, but I haven't tested all the features of Vim. From reviewing the code the extension already abstracts fs access in src/platform/node/fs.ts and uses vscode.workspace.fs where possible 👍 . However, vscode.workspace.fs is not used everywhere and it would be good investigate the impact of this in a virtual workspace setup and to handle it gracefully. For example, unlink is using fs directly.

cyrilletuzi commented 3 years ago

My Angular Schematics extension is doing a lot of files/paths management, and trying to comply with the virtual workspaces guide (PR cyrilletuzi/vscode-angular-schematics#551) revealed many things (being forced to use Node APIs because of missing methods on vscode.Uri, being forced to use fsPath in some place because of an issue with path in some scenarios, etc.). Where should I report these things?

aeschli commented 3 years ago

@cyrilletuzi You can find path like utilities in the vscode-uri node module: See https://www.npmjs.com/package/vscode-uri, section Usage: Util

cyrilletuzi commented 3 years ago

@aeschli Thanks, vscode-uri solved some of my issues.

  1. Is there a reason some methods (like joinPath()) are directly available in @types/vscode while some others (like dirname() and basename()) require vscode-uri? Now that you explicitly require to not use Node APIs directly, it would make sense to include everything directly in @types/vscode.

Also, there is still some issues and missing features so I'm able to get rid of all Node APIs:

  1. I need path.relative() a lot, and it doesn't exist in vscode-uri. Can it be added? It would work the same (2 Uris as params, and returns a string representing the relative path).

  2. 116298, which was not taken into account properly, should be reopened and fixed (otherwise I'm forced to use .fsPath in some places, as .path is buggy in some scenarios explained in the issue).

  3. vscode.workspace.createFileSystemWatcher() only accepts a fsPath string, and not a Uri as all other VS Code APIs. Do you confirm it's intended and it can't be done with schemes other than file, and thus that extensions require a manual check (if (uri.scheme === 'file'))?

aeschli commented 3 years ago

Only one more adoption since July. My guess is that given we provide the default, the listed extensions don't have any pressure to adopt.

I'll close this issue now and will make changes to our default on request.