Share via

Extensions and Ecosystem Support

  • Article

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!

User-Specific Extensions

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

Category Example(s) Guest-Supported? Collaborative?
Color Themes One Dark Pro, Output Colorizer, Rainbow String, Colored Regions, Indented Block Highlighting, Todo Highlight, Bracket Pair Colorizer ✅ N/A
Icon Sets vscode-icons, Visual Studio Classic Icons ✅ N/A
Key bindings Vim, IntelliJ IDEA Keybindings, Emacs Friendly Keymap ✅ N/A
Snippets Angular v5 Snippets, HTML Snippets, SVG Icons, File Header ✅ N/A 1
Organization Settings Sync, Project Manager, Timeit, Checkpoints, TODO Parser, Favorites (❌), Bookmarks (❌) ✅ 2 N/A 3
Productivity GitLens, Auto-Rename Tag, Code Outline, Color Highlight, Increment Selection, Bracketeer, Image Preview, JSON Helper (Hover), Color Picker, Copy Word in Cursor, CodeMetrics (CodeLens), Git Co-Authors, JavaScript Booster (CodeActions), Turbo Console Log, Goto Next/Previous Member, Auto-scroll, NPM Import Version (❌), Import Cost (❌) ✅ 2 ❌ 3
REPLs REST Client, Code Runner, Quokka.js, R ✅ 4 ❌ 3
Resource Managers mssql, ftp-simple, Azure Functions, Docker, Brew Services ✅ 5 ❌ 3

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.

Project-Specific Extensions

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).

Category Example(s) Shared? Guest-Supported?
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, 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 ❌ ❌

1 Currently only C# and JavaScript/TypeScript.

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.

Known Issues

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

Issue Reason Workaround
Using the Node.js fs module to detect/read files (e.g. a config file), or enumerate directories (and you aren't a language service). Guests don't have local file access. 1. Gracefully degrade the user-experience (if possible).

2. Use the openTextDocument and findFiles workspace APIs to read and enumerate files.
Using the Node.js fs module to create or write files Same as above N/A You can use the openTextDocument(Uri) API to create an untitled file, but you can't save it directly to the file system, at a specific path.
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 fs module to create a directory Same as above N/A
Restricting functionality to documents that use the file scheme. Files on the guest's side use the vsls scheme. Add support for vsls documents (example)
Using the Uri.file method and/or Uri.fsPath/TextDocument.fileName members to serialize/parse URIs Same as above Use Uri.parse and Url.toString() instead, which maintain and respect file schemes (example)
Using the workspace.openTextDocument method with a file path instead of a Uri Same as above Provide a Uri instance instead of a raw file path string (example)
Using the workspace.rootPath property to detect the presence of a workspace The workspace.rootPath property calls Uri.fsPath on the first workspaceFolder in the workspace, which has the same issue mentioned above Use the workspace.workspaceFolders property to detect the presence of a workspace instead, and if needed, look at each workspaceFolder's Uri.scheme to determine if it's local or not
Not specifying a document scheme when registering language services (either via a LanguageClient, or the languages.register* methods) 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 file and untitled schemes (example)
Not checking a document's Uri.scheme before populating a DiagnosticCollection for it Same as above Only generate Diagnostics for documents whose Uri.scheme === file (example)
Not checking for workspace scheme when returning Tasks from a custom TaskProvider Guests display all remote and local tasks, and therefore, would display duplicates if both participants had the same extension installed Only return Tasks for WorkspaceFolders whose Uri.scheme === file (example)

See also

Having problems? See troubleshooting or provide feedback.