Set extensionKind in package.json to support Remote Development

[mjbvz]

Hi, I'm on the VS Code team. We recently released support for Remote Development and I noticed that your may extension need a small change to ensure users have a good experience when using it remote workspaces.

What is the issue?

To make remote development as transparent as possible to users, VS Code distinguishes two classes of extensions:

• UI Extensions: These extensions make contributions to the VS Code user interface and are always run on the user's local machine. UI Extensions cannot directly access files in the workspace, or run scripts/tools installed in that workspace or on the machine. Example UI Extensions include: themes, snippets, language grammars, and keymaps.

• Workspace Extensions: These extensions are run on the same machine as where the workspace is located. When in a local workspace, Workspace Extensions are run on the local machine. When in a remote workspace, Workspace Extensions are run on the remote machine. Workspace Extensions can access files in the workspace to provide rich, multi-file language services, debugger support, or perform complex operations on multiple files in workspace (either themselves or by invoking scripts/tools).

You can find more details about this architecture here.

VS Code currently infers that your extension is a Workspace Extension. This means that users who have your extension installed must also install it to the remote in order to use it in remote workspaces. I believe that your extension should probably be a UI extension instead. That way your extension will always be enabled for users who install it, even if they open a remote workspace.

How do I fix this?

To tell VS Code that your extension is a UI extension, just add "extensionKind": "ui" to your extension's package.json.

UI Extensions always run on the user's local machine, even when they open a remote workspace.

I'll submit a PR that does this. Please let me know if you have any questions or concerns about the issue. We've also put together a guide to help you test your extension in remote workspaces

PS: As a temporary workaround for a few popular extensions, we've automatically added your extension to an internal whitelist so that is always treated as a UI extension

[shanalikhan]

Thanks.
I will release this fix in the upcoming version.

Feel free to send PR where you think it can be improved. :)

[brysgo]

@shanalikhan - thanks for this extension, I'm using it to do development on WSL using the remote WSL extension, but all my extensions that run in WSL don't get synced because they are installed on the remote. What is the remediation for this?

[jraviotta]

Adding this issue here as it is likely a WSL compatibility issue.

I am using code-insiders to take advantage of remote development. When I install settings sync in WSL, settings sync fails to sync with Cannot read property 'ignoreUploadFolders' of undefined.

I tried resetting the defaults, uninstalling/reinstalling the extension, but get the same error.

FYI: I copied contents of %APPDATA%/Code/User/syncLocalSettings.json to %APPDATA%/Code - Insiders/User/syncLocalSettings.json and had the same issue.

[shanalikhan]

@brysgo and @jraviotta

I would suggest you to create new issue regarding WSL compatibility with your real time detail senarios with the bugs ( logs or image attached ) rather than description. This issue is fixed and will be release in upcoming release.

[Dreomite]

@shanalikhan - thanks for this extension, I'm using it to do development on WSL using the remote WSL extension, but all my extensions that run in WSL don't get synced because they are installed on the remote. What is the remediation for this?

It's still not supported by this extension. I came up with 2 workarounds:

1. Install all the extensions locally then open WSL session and use recently introduced feature to automatically install all appropriate extensions in WSL.

   Pros:

   • Very easy to do.

   Cons:

   • Deleted extensions won't be synchronized and will have to be deleted manually on all machines.
   • Possibly unwanted extensions installed locally.

2. Paste this to your remote settings and then reload VSCode:

   "sync.gist": "your_separate_settings_gist_id_here234233523",
   "remote.extensionKind": {
     "shan.code-settings-sync": "workspace"
   },
   

   After this, when you're connected to WSL, Settings Sync will be considered a remote extension. Install it on WSL and reload VSCode again. Now just provide Settings Sync with your GitHub token and you're good to go. When connected to WSL, it will sync your WSL extension list, in local sessions, regular things will be synchronized.

   Pros:

   • Avoid bloating your local client with unwanted extensions.
   • Separate configs for different purpose WSLs.

   Cons:

   • Synced data is usable only for WSL (and, probably, any other code-server implementations).
   • The only thing that is synchronized is extensions list. Any other things, including settings, are not.

Warning: When using the second method, don't try to load settings from your main gist to WSL. It will fuck up your code-server installation.

There was an issue opened for remote server support in this extension (#913), but @shanalikhan probably misinterpreted it and closed it. Perhaps it should be reopened.