Поделиться через

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

  • Статья

Одной из основных целей 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/A 1
Организация Синхронизация параметров, project Manager, Timeit, контрольные точки, средство синтаксического анализа TODO, избранное (❌), закладки (❌) ✅2 N/A 3
Продуктивность 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, 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 схемы (например)
Не проверяя документ Uri.scheme перед заполнением DiagnosticCollection для него То же, что и выше Только для Diagnostics создания, для которого Uri.schemefile === (пример)documents
Не проверяется схема рабочей области при возврате Tasks из пользовательского TaskProvider Гости отображают все удаленные и локальные задачи и, следовательно, будут отображать дубликаты, если оба участника установили одно и то же расширение. Возвращается только для s, (Uri.scheme === fileпример)WorkspaceFolderTasks

См. также

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