Расширения и поддержка экосистемы

  • Статья

Одной из основных целей Visual Studio Live Share является предоставление разработчикам возможности сотрудничать друг с другом, от комфорта своих любимых и высоконастройных инструментов. Таким образом, нерегламентированное взаимодействие может происходить часто, оставаясь визуально знакомым и эргономическим, независимо от того, с чем вы помогаете. Для этого важно, чтобы участники сеанса совместной работы могли продолжать использовать любые расширения, поддерживающие свои личные предпочтения и рабочие процессы (например, темы цвета и значки, ключевые привязки, улучшения производительности редактора).

Кроме того, чтобы сделать процесс присоединения к сеансу совместной работы как можно скорее, в то время как остается высокопроизводительным, цель Visual Studio Live Share — позволить гостям автоматически использовать средства, относящиеся к проекту, к которым предоставлен общий доступ. Таким образом, вы можете просто щелкнуть ссылку, запустить выбранный инструмент и начать совместную работу без дополнительной настройки. Для этого важно, чтобы расширения, которые обеспечивают основное редактирование, сборку и отладку рабочего процесса, прозрачно "удалены" от узла к гостею, чтобы такие вещи, как автозавершение, переход к определению и отладка "просто работает".

В этом документе рассматривается текущее известное состояние для обширной экосистемы расширений, а также "оценка карта" для указанных выше упоминание целей. Если вы столкнулись с расширением, которое не соответствует этим критериям, и имеет решающее значение для вашего личного рабочего процесса, пожалуйста , сообщите нам об этом!

Расширения для конкретных пользователей

Расширения, поддерживающие пользовательские настройки , должны работать для узла и должны работать для всех гостей. Если расширение не работает должным образом для узла, это будет регрессия и, скорее всего, ошибка в Visual Studio Live Share ( при появлении одной проблемы ). Если расширение не ведет себя должным образом для гостя, это может потребовать изменений в самом расширении, и мы будем работать с экосистемой для решения и улучшения этих сценариев.

Visual Studio Code

Категория Пример(ы) Гостевая поддержка? Совместных?
Цветовая тема One Dark Pro, Output Colorizer, Rainbow String, Colored Regions, Indented Block Highlighting, Todo Highlight, Bracket Pair Colorizer ✅ Н/Д
Наборы значков vscode-значки, классические значки Visual Studio ✅ Н/Д
Сочетания клавиш Vim, IntelliJ IDEA Keybindings, Emacs Friendly Keymap ✅ Н/Д
Фрагменты Фрагменты кода Angular версии 5, фрагменты HTML, значки SVG, заголовок файла ✅ N/A1
Организация Параметры синхронизации, диспетчера проектов, таймита, контрольных точек, средства анализа TODO, избранного (❌), закладки (❌) ✅2 N/A3
Продуктивность GitLens, тег автоматического переименования, структура кода, выделение цвета, добавочный выбор, скобка, предварительный просмотр изображения, вспомогательный элемент JSON (наведение), средство выбора цветов, копирование Word в курсоре, codeMetrics (CodeLens), Git Co-Authors, JavaScript Booster (CodeActions), Turbo Console Log, Goto Next/Previous Member, Auto-scroll, NPM Версия импорта (), стоимость импорта (❌❌) ✅2 ❌3
URL-адреса REST Client, Runner кода, Quokka.js, R ✅4 ❌3
Диспетчеры ресурсов mssql, ftp-simple, Функции Azure, Docker, Brew Services ✅5 ❌3

1Если пользователь уже не был знаком с фрагментом кода, он не ожидал, что он будет доступен, и поэтому, делая их общими, не обязательно имеет смысла.

2Эти категории расширений настолько разнообразны, что невозможно сказать, что все они работают. Тем не менее, в теории, они должны, и мы будем отслеживать ключевые, которые не делают.

3Эти категории расширений могут воспользоваться преимуществами совместной работы, поэтому нам нужна обратная связь конечных пользователей, чтобы знать это!

4Для этого требуется, чтобы гостевой гость устанавливал средства выполнения (например, Node.js) и работал с помощью локального выполнения кода.

5Эти действия выполняются путем подключения к серверу определенного типа и могут работать с отдельными централизованными серверами, серверами, которыми предоставил гость.

Расширения для конкретного проекта

Установленные на узле расширения, поддерживающие основное редактирование, сборку и отладку приложения, а также относящиеся к языку, платформе или библиотеке или пакету SDK, должны быть автоматически доступны гостям без необходимости устанавливать какие-либо компоненты. Таким образом, узлы могут настроить свою среду для поддержки продуктивной разработки проекта и позволить своим гостям мгновенно присоединиться к ним без дополнительных предварительных требований. Так как расширения, относящиеся к проекту, не являются субъективными или личными, они могут быть детерминированными общими для хост-гостей, не влияя на знакомую среду кого-либо.

Кроме того, для поддержки расширений для конкретных проектов, установленных гостем, но узел не делает этого, они в идеале обеспечивают деградирующую работу, но функциональный интерфейс (например, получение intellisense одного файла, возможность форматирования документа).

Категория Пример(ы) Общий? Гостевая поддержка?
Грамматики / выделение синтаксиса Fish Shell, Nginx, Vetur, DotEnv, ES6 String HTML, Todo+, Радуга CSV ❌ ✅
Языковые службы YAML, Путь Intellisense, ARM ✅1 ✅2
Схемы JSON Функции Azure ✅ ✅
Анализаторы кода ESLint, Markdownlint, средство проверки орфографии кода, PHPCS ✅ ✅2
Форматировщики Prettier, Beautify ✅ ✅2
Отладчики Python, отладчик для Chrome ✅3 ❌4
Тестовые средства выполнения Тестовый модуль Java, боковая панель Mocha, Postman Runner, Jest Runner, Нептуна ❌5 ✅2
Пользовательские средства предварительного просмотра файлов SvG Preview, GraphViz, Markdown Image Size ❌ ✅
Генераторы файлов и проектов Функции Azure, генератор проектов C/C++ ❌ ❌6
Поставщики системы управления версиями SVN, Hg ❌ ❌

1В настоящее время только C# и JavaScript/TypeScript.

2Поддерживает только текущий активный документ, так как у гостей нет локального доступа к файлам.

3Основные возможности отладки совместно используются, однако все запущенные серверы не перенаправляются автоматически.

4Гости не имеют локальной копии приложения, поэтому запущенное приложение и все сеансы отладки должны начинаться на компьютере узла.

5Выходные данные тестового запуска требуют, чтобы все полученные терминалы, области вывода и ошибки также были переданы гостям.

6Почти все из них будут использовать модуль Node.js fs непосредственно для создания файлов, которые не будут работать.

Известные проблемы

Ниже перечислены известные проблемы с расширением, которые могут препятствовать их работе для гостей в контексте сеанса совместной работы (вместе с их обходными решениями) и, следовательно, могут повлиять на их рабочий процесс:

Visual Studio Code

Проблема Причина Обходное решение
Использование модуля Node.js fs для обнаружения и чтения файлов (например, файла конфигурации) или перечисления каталогов (и вы не являетсяе языковой службой). У гостей нет локального доступа к файлам. 1. По возможности унизите взаимодействие с пользователем (если это возможно).

2. Используйте openTextDocument API рабочей findFiles области для чтения и перечисления файлов.
Использование модуля Node.js fs для создания или записи файлов То же, что и выше N/A Можно использовать openTextDocument(Uri) API для создания untitled файла, но его нельзя сохранить непосредственно в файловой системе в определенном пути.
В зависимости от библиотеки или средства с пакетом проекта То же, что и выше 1. Пакет резервной версии зависимости с расширением

2. Поддержка глобальной установки для разблокировки гостей, если они решили явно установить его.

3. При возможности удаленное состояние или действие, так как узел будет иметь правильные зависимости.
Создание каталога с помощью модуля Node.js fs То же, что и выше Н/Д
Ограничение функциональности документам, используюющим схему file . Файлы на стороне гостя используют схему vsls . Добавление поддержки документов vsls (пример)
Uri.file Использование метода и (или) Uri.fsPath/TextDocument.fileName элементов для сериализации и анализа URI То же, что и выше Используйте Uri.parse и Url.toString() вместо этого, которые поддерживают и уважают схемы файлов (пример)
workspace.openTextDocument Использование метода с путем к файлу вместо методаUri То же, что и выше Uri Укажите экземпляр вместо строки пути к необработанным файлам (например)
workspace.rootPath Использование свойства для обнаружения присутствия рабочей области Свойство workspace.rootPath вызывает Uri.fsPath первое workspaceFolder в , workspaceкоторое имеет ту же проблему, упоминание выше workspace.workspaceFolders Используйте свойство для обнаружения присутствия рабочей области и при необходимости просмотрите ихworkspaceFolderUri.scheme, чтобы определить, является ли он локальным или нет.
Не указывая схему документа при регистрации языковых служб (через методы или languages.register* методыLanguageClient) Гости получают результаты службы языка как от своих локальных расширений, так и узла, и, следовательно, если оба участника имеют одно и то же расширение языковой службы, гости увидят повторяющиеся записи для определенных вещей (например, автоматическое завершение, действия кода) Ограничить языковые службы только file и untitled схемы (например)
Не проверка перед заполнением DiagnosticCollection документа Uri.scheme То же, что и выше Только для Diagnostics создания, для которого Uri.schemefile === (пример)documents
Не проверка для схемы рабочей области при возврате Tasks из пользовательскогоTaskProvider Гости отображают все удаленные и локальные задачи и, следовательно, будут отображать дубликаты, если оба участника установили одно и то же расширение. Возвращается только для s, (Uri.scheme === fileпример)WorkspaceFolderTasks

См. также

Возникли проблемы? Ознакомьтесь с разделом по устранению неполадок или отправьте отзыв.