[ExtensionDev] Expose API to get at file system locations

[SrTobi]

Some extension relay on hard coded paths that are not exposed by vscode. See for example code-sittings-sync. Those extension are broken in the insiders version. I see t two possible ways:

1. Just expose all paths used by vscode to extensions. Otherwise they will hard code them. No more security, just more messy code.
2. Expose if the extension is used by the insider version. There might be a way, but I have not found it yet. I thought about getting the version and check if it ends with -insiders, but I have not found a way to get this information either.

[egamma]

Interesting... the insider version should be considered as a separate product, with its own user settings and extensions folders. This enables a clean side-by-side install. Therefore, the code-sittings-sync extension is product specific, depending on whether it is installed in the insiders or the stable product it should sync the corresponding product settings.

An extension gets its path passed in the ExtensionContext of the activate call. From the extension path you can derive in which product the extension is installed.
/.vscode-insiders/extensions/ or .vscode/extensions/.

Having said this a workaround, an extension should not have to do this path math and we exposing API to avoid this.

[jrieken]

To recap, the paths we should expose

• extensions home folder, like /Users/jrieken/.vscode-oss-dev/extensions
• user config folder, like /Users/jrieken/Library/Application Support/code-oss-dev/User

I am unsure if we should also expose the individual files inside that folder like settings.json, keybindings.json cos that list isn't finite.

[jrieken]

@alefragnani for the bookmark extension I believe you need the user config folder. is that right? @SrTobi I am unsure if you only looking at sync'ing the user-level settings.json or also at others, like our keybindings.json and a potential future bookmarks.json etc

[alefragnani]

@jrieken exactly... thanks 👍

[Tyriar]

FYI #5570 is moving the user data directory to be a sibling of the extensions dir.

[jrieken]

@Tyriar so should we expose the parent folder of those two directories?

[Tyriar]

@jrieken potentially... Post #5570, it might be better to move snippets, settings.json and keybindings.json to the parent directory so it stays away from Chrome's config. Do you know if there's any reason it's in user data as opposed to sitting next to extensions?

[jrieken]

no clue... @joaomoreno or @bpasero will know

[bpasero]

Historic reasons, we only had extensions folder a lot later.

[Tyriar]

Is it worth simplifying the structure further as part of #5570?

.vscode/settings.json
.vscode/keybindings.json
.vscode/snippets/
.vscode/extensions/
.vscode/userdata/
.vscode/rootuserdata/

[jrieken]

Moving to June considering those potential upcoming changes

[joaomoreno]

I like that very much.

[jrieken]

@joaomoreno @Tyriar where are we with this and what's the plan?

[Tyriar]

The pull is quite stale and probably needs to be redone, there is also the complication of Windows directory changing as well #7035. Just a matter of prioritizing it against the other stuff in my backlog (mainly terminal bugs and linux packaging improvements).

[Tyriar]

@jrieken I'd like #7035 to be figured out before moving on this again. We don't really want to be migrating settings around multiple times if we can prevent it. It sounds like #7035 would need an extensions manifest to correctly support roaming on Windows.

Considering that settings.json and keybindings.json would probably best be situated at the root directory, not in Chromium's user data, how about we make an API to get at the User directory for now, which will eventually become the root?

<root_settings>/settings.json
<root_settings>/keybindings.json
<root_settings>/snippets/
<root_settings>/extensions/
<root_settings>/userdata/
<root_settings>/rootuserdata/

[jrieken]

Sorry, again we didn't get to this... Tho we added a storagePath property for those extension that want to store state that doesn't fit into mementos but needs files/folders

[golf1052]

Just wanted to check in on this. I assume this is also being pushed out past August like #3884

[jrieken]

yeah - I am handcuffed as long as the underlying api/data isn't ready

[Tyriar]

@jrieken it should be fine to expose the User directory now, that will be the root config directory eventually after #3884. settings.json and keybindings.json will still be located there.

[davidsk]

Any movement on this item? I'm after a way to reliably locate the snippets folder.

[jrieken]

Sorry no - there is still no decision on how to re-structure the fs layout (which might then be a breaking change)

[shanalikhan]

@jrieken
Any update on getting the paths for extensions and all those things for portable mode.

#49306

[cantonios]

Most links related to obtaining the user-data-dir refer here, but the provided solution of using storagePath is workspace-dependent.

It seems storagePath is the fs-equivalent of the memento workspaceState.

Is there a similar option somewhere for the fs-equivalent of the memento globalState?

I could use the extension folder extensionPath, but this would mean that data will be lost if you ever remove the plugin or update to a new version.

[usernamehw]

Expose if the extension is used by the insider version. There might be a way, but I have not found it yet. I thought about getting the version and check if it ends with -insiders, but I have not found a way to get this information either.

const isInsiders = /insiders/i.test(vscode.env.appName);

Is there anything terribly wrong with this way of getting User dir?

const UserDirPath = path.join(extensionContext.logPath, '..', '..', '..', '..', 'User');

[Lakr233]

I have been thinking it would be possible to get it from the shell

	let ret = execSync("cd ~ && echo $(pwd)");
	LKutils.shared.setUserHome(ret.toString());

but an API is better for sure.

[roblabla]

I have a bit of an odd need for this:

I'm using an extension that has an interactive help showing the keybindings that can be used, edamagit. Here's a small example:

Now the problem is, the user can change the keybindings in their keybindings.json. To make sure the correct keybindings are shown, the extension parses the keybindings.json.

Now the problem is, when using the extension remotely, there appears to be no way to get to this keybindings.json file. Delving into the vscode source, it appears that the correct URI to access keybindings.json is something like vscode-userdata:c:/Users/roblabla/AppData/Roaming/Code - Insiders/User/setting.json. The problem is, this URI depends on a ton of app and os-specific information that seems to be totally inaccessible from a remote extension.

The only way I've found to access it is by spawning the settings editor with workbench.action.openGlobalKeybindingsFile:

    await commands.executeCommand('workbench.action.openGlobalKeybindingsFile');
    let keybindingsPath = null;

    for (let f of workspace.textDocuments) {
      if (f.uri.path.endsWith('keybindings.json')) {
        KEYBINDINGS_FILE_URI_CACHE = f.uri;
        break;
      }
    }

    // Close the keybinding and default keybinding views.
    await commands.executeCommand('workbench.action.closeActiveEditor');
    await commands.executeCommand('workbench.action.closeActiveEditor');

which is a pretty terrible idea (it temporarily spawns a visible keybinding editor, which makes for a rather jarring experience...).

Otherwise, the URI is available through the IEnvironmentService::keybindingsResource field, but this seems to be entirely inaccessible from extensions.