Extensions and Ecosystem Support
One of the primary goals of Visual Studio Live Share is to enable developers to collaborate with each other, from the comfort of their favorite, and highly-customized tools. This way, ad-hoc interactions can occur frequently, while remaining visually familiar and ergonomic, regardless what you're helping with. To achieve this, it's critical that participants within a collaboration session are able to continue using any extensions which support their personal preferences and workflows (e.g. color/icons themes, key bindings, editor productivity enhancers).
Additionally, to make the act of joining a collaboration session as instant as possible, while remaining highly-productive, the goal of Visual Studio Live Share is to enable guests to automatically leverage the project-specific tooling their host has shared. This way, you can simply click a link, launch your tool of choice, and begin collaborating, without any extra setup. To achieve this, it is critical that extensions, which power the core edit, build and debug workflow, are transparently "remoted" from the host to the guest, so that things like auto-completion, go-to-definition, and debugging "just work".
This document covers the current known state for the vast extension ecosystem, as well as a "scorecard" for the aforementioned goals. If you encounter an extension that doesn't meet this criteria, and is critical to your personal workflow, then please let us know!
Extensions that support user-specific customizations must work for the host, and should work for all guests. If an extension doesn't work properly for the host, that would be a regression, and is likely a bug in Visual Studio Live Share (please file an issue if you see one!). If an extension doesn't behave as expected for a guest, it may require changes in the extension itself, and we'll work with the ecosystem to address/improve these scenarios.
Visual Studio Code
1 Unless a user was already familiar with a snippet, they wouldn't expect it to be available, and therefore, making them shared doesn't necessarily make sense.
2 These extension categories are so diverse, that it's impossible to say they all work. However, in theory, they should, and we'll track the key ones that don't.
3 These extension categories may benefit from collaborative experiences, and so we need end-user feedback to know that!
4 These require the guest to have the runtime tools installed (e.g. Node.js), and work by running code locally.
5 These work by connecting to a server of some kind, and can work with either centralized servers, servers that the guest has shared.
Host-installed extensions, which support the core editing, building and debugging of an application, and are specific to a language/platform/library/SDK, should be automatically available to guests, without requiring them to install anything. This way, hosts can setup their environment to support productive development of a project, and allow their guests to instantly join them, without additional pre-requisites. Because project-specific extensions aren't subjective or personal in any way, they can be deterministically shared from host-to-guest, without impacting anyone's familiar environment.
Additionally, in order to support project-specific extensions that a guest has installed, but the host doesn't, they would ideally provide a degraded, yet functional experience (e.g. getting single file intellisense, being able to format a document).
|Grammars / Syntax highlighting||Fish Shell, Nginx, Vetur, DotEnv, ES6 String HTML, Todo+, Rainbow CSV||❌||✅|
|Language Services||YAML, Path Intellisense, ARM||✅ 1||✅ 2|
|JSON Schemas||Azure Functions||✅||✅|
|Linters||ESLint, Markdownlint, Code Spell Checker, PHPCS||✅||✅ 2|
|Formatters||Prettier, Beautify||✅||✅ 2|
|Debuggers||Python, Debugger for Chrome||✅ 3||❌ 4|
|Test Runners||Java Test Runner, Mocha Sidebar, Postman Runner, Jest Runner, Neptune||❌ 5||✅ 2|
|Custom File Previewers||SVG Preview, GraphViz, Markdown Image Size||❌||✅|
|File/Project Generators||Azure Functions, C/C++ Project Generator||❌||❌6|
|Source control providers||SVN, Hg||❌||❌|
2 Would only support the current active document, since guests don't have local file access.
3 The core debugging experience is shared, however, any launched servers aren't automatically forwarded.
4 Guests don't have a local copy of the app, and therefore, the running app and any debug sessions need to start on the host's machine.
5 The output of a test run would require that any resulting terminals, output panes and errors were also shared with guests.
6 Almost all of these would use the Node.js
fs module directly to create files, which wouldn't work.
The following are currently known extension issues, that could prevent them from working for guests within the context of a collaboration session (along with their workarounds), and therefore, could impact their workflow:
Visual Studio Code
|Using the Node.js
||Guests don't have local file access.||1. Gracefully degrade the user-experience (if possible).
2. Use the
|Using the Node.js
||Same as above||N/A You can use the
|Depending on a project-bundled library or tool||Same as above||1. Bundle a fallback version of the dependency with the extension
2. Support global installation to unblock guests if they choose to explicitly install it.
3. Remote the state/action if possible, since the host would have the right dependencies available.
|Using the Node.js
||Same as above||N/A|
|Restricting functionality to documents that use the
||Files on the guest's side use the
||Add support for
||Same as above||Use
||Same as above||Provide a
|Not specifying a document scheme when registering language services (either via a
||Guests receive the language service results from both their local extensions, and the host, and therefore, if both participants have the same language service extension installed, guests will see duplicate entries for certain things (e.g. auto-completion, code actions)||Restrict the language services to only
|Not checking a document's
||Same as above||Only generate
|Not checking for workspace scheme when returning
||Guests display all remote and local tasks, and therefore, would display duplicates if both participants had the same extension installed||Only return
- Language and platform support
- Connectivity requirements for Live Share
- Security features of Live Share
- All major bugs, feature requests, and limitations
- All feature requests and limitations
We'd love to hear your thoughts. Choose the type you'd like to provide:
Our feedback system is built on GitHub Issues. Read more on our blog.