Support for remote development scenarios

[jrieken]

Remote development describes a setup in which VS Code is used to edit files that reside on a different computer which file system cannot be mounted. A server that only offers FTP is an example of such a setup.

The following features should be supported for good dev experience

• see resources in the explorer, either as separate view or inline with the open folder/folders
• open (text) files, modify, save, and revert them. Lots of thoughts about this have been written down in Editable TextDocumentContentProvider for extensions #10547 (comment) and Unify our various places where resources are being saved #29025
• support file events from the remote source being reflected in the editor, e.g. update explorer, close editors, invalidate search caches etc.
• allow to search for files by their name in the same way we do it today using Cmd+P
• allow to search inside files, again merging with the existing search experience.
• think about language services/servers which today usually rely on having disk-access to files

The goal is to enable remote development via extensions, so new provider APIs are required to allow 3rd parties to integrate into more pieces of our system. Similar to #29025 we start with assessing how many assumptions are backed into our system and how we can make it aware of having multiple sources of truth, e.g. multiple search result providers, etc, etc.

[felixfbecker]

For language servers, this would require new ways for the language server to get text documents over LSP from the client instead from the disk - what do you think about https://github.com/sourcegraph/language-server-protocol/blob/master/extension-files.md?

[Chillee]

Is this going to be similar to Nuclide's remote dev support?

https://nuclide.io/docs/features/remote/

[codeflows]

Re: #10547

I also have a use case for editable/saveable TextDocumentProviders, or similar functionality by some other means. I've written a plugin that decrypts data to a virtual document. This is useful by itself, but it would be nice to allow editing the plain text file and encrypting it back upon save. I could probably implement this by decrypting to a temporary file instead and letting the user edit that, but having the functionality in TextDocumentProvider would make my implementation cleaner for sure.

[jrieken]

FYI - For August we will explore to hook into our search infrastructure. That means support for searching for and in files. Work has started here: #32549. Everyone please join the discussion.

[paulchill]

is this being added, i use nuclide.io for remote dev but i want something good for the same with Angular 2 in VS code?

[siegebell]

@paulchill Eventually? #34218 is the next iteration of this idea, and you should follow the "remote" label if you want to track its progress.

[ARMATAV]

Is anything like this available in alpha? We're using Atom with Nuclide but tbh VSCode is where it's at, especially for frontend TypeScript development.

[ryansully]

I discovered this recently:
https://github.com/codercom/code-server

[wyntau]

I discovered this recently:
https://github.com/codercom/code-server

Will vscode officially support like this?

[ramontayag]

Been using mutagen.io. Not perfect, but it works pretty well.

[cloudhan]

@jrieken Any progress or official response? I find the code-server is quite usable, but the keybinding is annoying, e.g. Ctrl+Shift+P will open print dialog, etc.

During my practice of remote development, there are basically 2 types of scenarios.

1. Syncing remote and local workspace.
   • sshfs mount the remote directory, only useful for small project, the intellisense is useless due to extremely slow response.
   • sync local workspace to remote. You loss the git convenience, switching branch is a pain in the ass.
2. Server-Client mode
   • the code-server runs on server, editing is smoothing, intellisense is responsive. git repo status tracking and branching switching is as slick as local development scenario. The drawback is the client side, the keybinding is twisted... Maybe VsVim extension can help me.

Based on my experience, I'll stick to code-server for now.

Since Microsoft have invented Language Server Protocol and Debugger Adapter Protocol for good reason, maybe it is time to invent Editor Server Protocol :).

[MOZGIII]

I was some work being done on implementing network-based IPC. Haven't seen an official statement or tracking issue for it, but I guess we're getting there.

My personal problem with remote development is that I often have to run heavy things that eat up the battery very quickly (might run an occasional fork bomb even). For this reason, I'd like to have a way of running the editor, language servers, extensions and so on remotely (quite often a vs code glitches and and up as the fork bomb), and only the user-facing UI portions (like the editor window) to run locally.

So far, based on my lurking in the vscode code base, it's already build with that kind of isolation in mind, so what's left is just addressing the use case: making things work over the network and implementing interfaces for the editor to allow connecting to remotely executing instances.

PS: all my use cases do not involve any kind of cloud, and it'd be very limiting it the resulting solution were implemented with some closed-source backend (I'm looking at you Azure). Added this remark cause Microsoft is big corporation that's biased to force their other services is such a way.

[aleksey-mashanov]

I find the code-server is quite usable, but the keybinding is annoying, e.g. Ctrl+Shift+P will open print dialog, etc.

@cloudhan, to solve this just open code-server in Chrome as an application in a separate window (requires Chrome >= 73): "three-dots menu" in the upper-right corner -> More tools -> Add to desktop, set "Open in window".

[ARMATAV]

I don't really want to use Chrome for development - I'm more interested in something like Nuclide but officially supported and developed by the VSCode team if it exists.

[aleksey-mashanov]

@ARMATAV, for an end user there are no visible differences between something run in a separate Chrome window and a separate local application like vscode. You never see what you are working in browser.

The one thing why code-server is better for me than some client-server API inside vscode is what the way it works is very similar to the way vim works on a remote server: vim over ssh inside terminal vs vscode over https inside browser.

[OneCyrus]

i guess there will be a new alternative to code-server pretty soon 😎

[benlindsay]

@OneCyrus Can you expand on that? What will the alternative be?

[ARMATAV]

@aleksey-mashanov there are clear and obvious differences between a local application and a Chrome tab - isolation, distraction and performance are a few.

Also it's pretty scuffed to run the application inside of Chrome, to be honest with you, it's a hacky workaround for to make do since we don't have a built-in officially supported solution.

I was inquiring if there was a Nuclide for VSCode, a lot of big companies and startups use remote development - but there is not, so we've learned.

[OneCyrus]

@OneCyrus Can you expand on that? What will the alternative be?

#71830

first paragraph and git commit history should tell you a lot. should be announced at build next week.

[jrieken]

[FabianKoestring]

Is there a nightly build or something?

[smhc]

I hope it is more than WSL support and will run everything via SSH to a remote system, especially file access and the LSP, e.g clangd. WSL isn't exactly remote development.

I assume extensions would need to be deployed on the remote system somehow, otherwise both the LSP extension and vscode would need to be 'remote-aware'. Which is also possible - but then we'd be waiting for someone to write a 'remote clangd LSP' extension.

[OneCyrus]

i'm confident in the vscode devs. they are doing great work!

it looks like the handling of remote extensions is already baked in:
https://github.com/Microsoft/vscode/blob/296fa84d8de6d63edc8417f9a3af2824118cc797/src/vs/workbench/contrib/extensions/node/extensionsWorkbenchService.ts#L555-L560

[egamma]

Closing 🚀 pls see https://code.visualstudio.com/blogs/2019/05/02/remote-development, please give it a try.

[benlindsay]

Wow, this looks very comprehensive and a potential game-changer for a lot of people! I expect you'll see a step change in VSCode usage as a result. Thanks VSCode devs!

[rportugal]

This is implemented beautifully. Great work everyone!

[ARMATAV]

Finally 🙏

[smhc]

Works very well so far. The suggested extension for C++ code in this scenario should perhaps be vscode-clangd rather than the MS cpp extension. Although that may be subjective/political so only a minor comment.
Otherwise an awesome enhancement - there is no other IDE offering this functionality properly.

[FabianKoestring]

😞 Alpine Linux not supported......

[jiajudu]

When will the remote development be available in stable versions?

[nickcorona]

Yes, when will it be released? Not really a closed issue for vscode if it isn't available.

Insider builds don't count.

[FabianKoestring]

Are there any plans to support Alpine-Linux?