Provide UI to easier changing of the running location of an extension

[zsiegel92]

Documentation of the remote.extensionKind setting is minimal despite it being very important. There are many issues involving "Remote-SSH" connections using more remote compute resources than users would like (#151205, #1110, #182903, and StackOverflow e.g.), and perhaps these issues could be resolved with a better settings.json API for this behavior and improved documentation.

Proposed change to settings.json: global "ui" extension configuration

In my case, I would like all extensions that can run on "ui" to do so.

Currently, I inspect ~/.vscode-server/extensions/extensions.json and add all the "identifier"."id" values I can find to "remote.extensionKind" in settings.json with the value ["ui"]. I add them manually. This seems like a bad system to me! I should not have to do this. Perhaps the settings UI can give each extension a checkbox setting for "run locally if possible".

For extensions that cannot run on "ui", I would like an option for them to not run at all and/or to give an error message. Maybe "cannot run in workspace" in the extensions UI.

Extension-specific settings plus a "run all extensions on "ui" setting would suffice.

Proposed improvement to documentation

The default value of the "remote.extensionKind" setting seems to be:

"remote.extensionKind": {
        "pub.name": [
            "ui"
        ]
}

What is this "pub.name"? This does not seem to be documented, but several GitHub issues quote settings.json files containing this value.

Also, my method of inspecting ~/.vscode-server/extensions/extensions.json is basically something I figured out on my own. If this is the best method for forcing extensions to run on "ui", then please document this procedure. If there's a better way, please document it.

Thank you for the "Remote-SSH" extension! I use it every day and I really appreciate it. I have had to piece together subsets of this extension's functionality in the past and I can't overstate how useful it is to have it all together. Feels like good design to me! Thanks.

[alexdima]

Extensions have a way in their manifest file (in their package.json file) to declare how they operate in a remote environment. This is done via the "extensionKind" field in their package.json.

• "extensionKind": "ui" -- this indicates that the extension can only execute on the ui, for example an extension that allows connecting to a microcontroller via an usb port.
• "extensionKind": "workspace" -- this indicates that the extension can only execute on the workspace, for example a language server extension that needs to spawn processes which need the files to be on disk
• "extensionKind": ["ui", "workspace"] -- this indicates that the extension can execute on both sides, but prefers to execute on the ui side.
• "extensionKind": ["workspace", "ui"] -- this indicates that the extension can execute on both sides, but prefers to execute on the workspace side.
• the extensionKind can be missing. In this case, we assume that the extension author did not do any specific remote testing for their extension and we therefore execute the extension by default in the place which most resembles local development, and that is the remote (workspace) side.

The above is documented at https://code.visualstudio.com/api/advanced-topics/remote-extensions#incorrect-execution-location , but the audience of that document is extension authors, not users of extensions.

The above can be overriden by advanced users via settings.json, via the remote.extensionKind setting, where each entry is an extension identifier. Extension identifiers consist of <extension publisher>.<extension name> or pub.name in short form.

---

From your feedback, I think you would like for a better experience in managing your extensions, for easier changing of the location where an extension is installed at / executed at.

[zachsiegel-capsida]

@alexdima thanks so much for this response and the context you provided!

You're right about what I'm looking for. Looking forward to seeing this issue progress!

[sandy081]

@zachsiegel-capsida Can you please explain what is missing for you in current Extensions UI?

[zachsiegel-capsida]

@sandy081, the response above from @alexdima exactly summarizes what I'm looking for in terms of configuration. He mentioned

The above is documented at https://code.visualstudio.com/api/advanced-topics/remote-extensions#incorrect-execution-location , but the audience of that document is extension authors, not users of extensions.

and my issue is basically that I think there should be more user-facing configuration and documentation regarding whether extensions run on the remote versus UI.

I would like all extensions that can run on "ui" to do so.

Ideally, a well-documented settings option would force all extensions that can run on the UI to run on the UI. I believe this would be a killer features for the scores of users who have issues with VS Code filling their remote instance filesystems with gigabytes of .vscode files. Of course there are obvious UX downsides associated with having extensions run on a different filesystem than the project (especially for e.g. an LSP) but users need this option in my opinion.

[sandy081]

Here is the user doc for managing extensions in remote set up - https://code.visualstudio.com/docs/devcontainers/containers#_managing-extensions

[zachsiegel-capsida]

Here is the user doc for managing extensions in remote set up - https://code.visualstudio.com/docs/devcontainers/containers#_managing-extensions

Thanks for this response @sandy081. My issue was about the following behavior described this documentation you linked to:

Advanced: Forcing an extension to run locally or remotely
Extensions are typically designed and tested to either run locally or remotely, not both. However, if an extension supports it, you can force it to run in a particular location in your settings.json file.
For example, the setting below will force the Docker extension to run locally and Remote - SSH: Editing Configuration Files extension to run remotely instead of their defaults:

"remote.extensionKind": {
    "ms-azuretools.vscode-docker": [ "ui" ],
    "ms-vscode-remote.remote-ssh-edit": [ "workspace" ]
}

A value of "ui" instead of "workspace" will force the extension to run on the local UI/client side instead. Typically, this should only be used for testing unless otherwise noted in the extension's documentation since it can break extensions. See the section on preferred extension location for details.

My feature request is to provide a single settings option that configures VS Code to use "ui" for all extensions that can use it. Something like "preferredExtensionHost" : "ui".

Trying to figure out which extensions can run in "ui", figuring out their internal names (e.g. "ms-azuretools.vscode-docker" is not immediately obvious when you install the "Docker" extension), and building out this "remote.extensionKind" object is not so straightforward, and unfortunately the stakes are high for many users who are experiencing bloat of their .vscode directory, which can have a severe impact when working remotely on a minimal ec2 instance or Raspberry Pi. Of course users don't have to install extensions when working on these remotes, but in many cases running extensions on "ui" whenever possible will solve this issue and support the extensions that users are using VS Code for in the first place.

Thank you!

[vscodenpa]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[sandy081]

Updated the summary of the issue accordingly.

[vscodenpa]

We closed this issue because we don't plan to address it in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding, and happy coding!

[zachsiegel-capsida]

@sandy081 if you don't mind me asking, what's the argument against providing an option to prefer extensions to run on "ui" when possible?

[sandy081]

It is a user convenient feature and I do not see many users asking for this. One can achieve this already using the existing setting.