Uploading settings when working using VSCode remote misses remotely installed extensions
Closed this issue · 23 comments
🐛 Describe the bug
I use the new VSCode remote capabilities (https://github.com/Microsoft/vscode-remote-release) an awful lot. Predominantly for WSL but also SSH. Using this a lot of "active" extensions required for coding must be installed on the remote system, e.g. linting, execution, debugging, etc.
If I do an upload of settings sync when using the new vscode remote capabilities settings sync completely "ignores" the extensions installed remotely. So you end up with a gist that only contains the locally installed extensions. Thus doing a download of the settings sync on a different machine misses out all those remotely installed extensions (regardless ofc whether it's a purely local install or another remote install).
The only current solution is to not do an upload of settings while working in the remote environment. Instead to always ensure you are using vscode on the local system. Obviously this is not ideal 😄
🌴 Visual Studio Code Version : 1.37-insider (22/07/2019)
🌴 Code Settings Sync Version : 3.4.1
🌴 Standard or Insiders : Insiders
🌴 Portable or Installed : Installed
🌴 OSS or Official Build : Official
🌴 Operating System : Windows 10
🌴 Occurs On: Upload / Download
🌴 Proxy Enabled: No
🌴 Gist Id: df3941ff96418197723a2d01cc5513e8
📰 To Reproduce
See description
💪 Expected behavior
The preferred solution (for me at least!) would be for settings sync to a) recognise the entire list of extensions whether they are installed locally or remotely and b) make note of those that need to be installed remotely so they can be auto-installed upon a new remote connection. Of these (a) is obviously the most critical, (b) is a "nice to have".
I've no idea whether this is limited by currently API access. If so it seems it's worthwhile pursuing that with the appropriate repo, whether it's the vscode remote or vscode itself.
I've no idea whether this is limited by currently API access.
I think its limited by API. I suggest you to open issue on vscode repo to see their response.
I haven't got a change to use VSCode remote capabilities so it will take time for me to look into it or someone can send PR 😄
I have exactly same issue that all the remote extensions are not synced (even got removed if synced before). This will cause remote-development not working across consoles. Hope there will be a fix soon.
This is also causing issues for me.
Hey, just an update here.
The issue still exist. But I found an workaround.
Do "Upload/Update Settings" in a local workspace instead of a remote workspace will correctly sync all the extensions and settings.
Yeah, I liked to use automatic upload and download. That way my settings are always synced. When I started doing ssh development, it was super confusing for a bit as to why my extension keep disappearing. I turned off auto upload and only push from one work station now. I switch between local and ssh development on at least three different machines.
Any update on this? This is removing extensions when I am hopping between wsl and mac vscode.
I lost a lot of extensions... Sad that the sync plugin doesn't support history
Just to follow up my original posting - @shanalikhan suggested I open an issue on vscode, I did not do this. I feel this is something the extension developer should do, being intimately familiar with how/why the extension does what it does in the way it does it. And therefore what, if any, changes may be required to vscode itself.
Obviously it remains an issue and I suspect will become more so as vscode remote development becomes a more common work flow.
Just ran into this too... All my WSL extensions gone for no reason
Unfortunately, as long as this issue exist, code-settings-sync is of no use to most developers using VS Code with WSL these days.
I don't mean to spam, but I'm just commenting on this to reiterate that this issue makes the extension near-useless for everyone using VSC with WSL as a remote environment. That's going to be more and more people as WSL 2 nears general availability later this year (it's only available in Insider builds right now).
Not to imply that anyone's being lazy - we're all developers with lives here - but I think it'd be prudent to prioritize this issue as much as possible while the userbase affected is still relatively minor, especially so if API changes on Microsoft's side are required for this to work.
I don't mean to spam, but I'm just commenting on this to reiterate that this issue makes the extension near-useless for everyone using VSC with WSL as a remote environment. That's going to be more and more people as WSL 2 nears general availability later this year (it's only available in Insider builds right now).
Not to imply that anyone's being lazy - we're all developers with lives here - but I think it'd be prudent to prioritize this issue as much as possible while the userbase affected is still relatively minor, especially so if API changes on Microsoft's side are required for this to work.
aye, this has massively reduced the extension's use for me, unfortunately..
aye, this has massively reduced the extension's use for me, unfortunately..
same for me. It would be nice to also keep sync the wsl remote extensions
For me, the major issue is that I was sure it works. I've lost all extensions and so my time.
I wish for a big warning in an extension's description.
Relying on a broken save tool hurts more than an absence of a tool at all.
Just to follow this up because I don't know how many peeps are aware of it. There is a continuing effort to build sync directly into vscode (see https://code.visualstudio.com/docs/editor/settings-sync), as it notes it is currently functional in insiders. So I suspect we're better off following up any ongoing issues with the "official" implementation at the vscode repo.
For me, the major issue is that I was sure it works. I've lost all extensions and so my time.
I wish for a big warning in an extension's description.Relying on a broken save tool hurts more than an absence of a tool at all.
It was uninstalled/deactivated but it's not lost. You can still revert to your gist's history.
For now, disable sync.removeExtensions is work for me.
"sync.removeExtensions": false
Do "Upload/Update Settings" in a local workspace instead of a remote workspace will correctly sync all the extensions and settings.
@howar31 Deserves more credits for this comment! It wasn't perfect as, strangely, the process appears to only have installed a little over half my extensions. But hey I'll take it! Thanks.
I'm having the same issue🤯. Half of my extensions are transferred to WSL remote and those extensions are removed from gist. Now Gist only have local extensions. But for now I have applied this setting so no more chaos will happen. "sync.removeExtensions": false
Do "Upload/Update Settings" in a local workspace instead of a remote workspace will correctly sync all the extensions and settings.
@howar31 Applied this solution but it didn't work for me.
Waiting of it's fix. ⌚
Given sync is now a part of the base vscode (still only insiders but still) I'm going to close this issue - as I noted above we should be following up issues with that rather than this addon.
Hey, just an update here.
The issue still exist. But I found an workaround.
Do "Upload/Update Settings" in a local workspace instead of a remote workspace will correctly sync all the extensions and settings.
This doesn't work, unfortunately.
There may be extensions that are installed BOTH locally and remotely (this happens for example if you already have extension installed locally, and then when you open your Remote, VS Code proposes you to install it on Remote machine) . In this case, running sync from local machine will of obviously sync this extension (because it resides locally).
However, if you install extension from remote machine, it will be installed ONLY on remote, and won't be synced if you try to do it from local machine.
My extensions didn't sync completely seemly due to this problem. Only 13 out of 46 synced successfully. I think those extensions that didn't sync are installed after I started to use this remote WSL thing.