Udostępnij za pośrednictwem

Rozszerzenia i obsługa ekosystemu

  • Artykuł

Jednym z głównych celów programu Visual Studio Live Share jest umożliwienie deweloperom współpracy ze sobą, od komfortu swoich ulubionych i wysoce dostosowanych narzędzi. W ten sposób interakcje ad hoc mogą występować często, gdy pozostają wizualnie znane i bezproblemowe, niezależnie od tego, z czym pomagasz. Aby to osiągnąć, ważne jest, aby uczestnicy sesji współpracy mogli nadal korzystać z wszelkich rozszerzeń, które obsługują swoje osobiste preferencje i przepływy pracy (np. motywy kolorów/ikon, powiązania kluczowe, ulepszenia produktywności edytora).

Ponadto w celu jak najszybszego dołączenia do sesji współpracy, przy jednoczesnym zachowaniu wysokiej produktywności, celem programu Visual Studio Live Share jest umożliwienie gościom automatycznego korzystania z narzędzi specyficznych dla projektu, które udostępnił ich host. W ten sposób możesz po prostu kliknąć link, uruchomić wybrane narzędzie i rozpocząć współpracę bez konieczności dodatkowej konfiguracji. Aby to osiągnąć, ważne jest, aby rozszerzenia, które zasilają podstawowy przepływ pracy edycji, kompilowania i debugowania, są w sposób przezroczysty "zdalny" od hosta do gościa, dzięki czemu takie elementy jak automatyczne uzupełnianie, przechodzenie do definicji i debugowanie "po prostu działają".

W tym dokumencie opisano obecny znany stan rozległego ekosystemu rozszerzenia, a także "kartę wyników" dla wyżej wymienionych celów. Jeśli napotkasz rozszerzenie, które nie spełnia tych kryteriów i ma kluczowe znaczenie dla twojego osobistego przepływu pracy, poinformuj nas o tym!

Rozszerzenia specyficzne dla użytkownika

Rozszerzenia obsługujące dostosowania specyficzne dla użytkownika muszą działać dla hosta i powinny działać dla wszystkich gości. Jeśli rozszerzenie nie działa prawidłowo dla hosta, oznacza to regresję i prawdopodobnie jest to usterka w programie Visual Studio Live Share (zgłoś problem , jeśli go widzisz!). Jeśli rozszerzenie nie działa zgodnie z oczekiwaniami dla gościa, może wymagać zmian w samym rozszerzeniu i będziemy współpracować z ekosystemem, aby rozwiązać/poprawić te scenariusze.

Visual Studio Code

Kategoria Przykłady Obsługiwane przez gościa? Współpracy?
Motywy kolorów Jeden ciemny pro, colorizer wyjściowy, tęczowy ciąg, kolorowe regiony, wcięte wyróżnianie bloków, wyróżnienie do wykonania, kolorowanie pary nawiasów ✅ Nie dotyczy
Zestawy ikon ikony vscode, klasyczne ikony programu Visual Studio ✅ Nie dotyczy
Powiązania kluczy Vim, IntelliJ IDEA Keybindings, Emacs Friendly Keymap ✅ Nie dotyczy
Fragmenty kodu Fragmenty kodu Angular v5, fragmenty kodu HTML, ikony SVG, nagłówek pliku ✅ N/A 1
Organizacja Synchronizacja ustawień, Project Manager, Timeit, Checkpoints, TODO Parser, Favorites (), Bookmarks (❌❌) ✅2 N/A 3
Produktywność GitLens, tag automatycznego zmieniania nazwy, konspekt kodu, wyróżnienie kolorów, zaznaczenie przyrostowe, nawiasy kwadratowe, podgląd obrazu, pomocnik JSON (Hover), selektor kolorów, kopiowanie wyrazów w kursorze, metryki kodu (CodeLens), współautorzy git, JavaScript Booster (CodeActions), Turbo Console, Goto Next/Previous Member, Auto-scroll, NPM Importowanie wersji (❌), koszt importu (❌) ✅2 ❌3
RepLs (REPLs) Klient REST, moduł uruchamiający kod, Quokka.js, R ✅4 ❌3
Menedżerowie zasobów mssql, ftp-simple, Azure Functions, Docker, Brew Services ✅5 ❌3

1 Jeśli użytkownik nie był już zaznajomiony z fragmentem kodu, nie spodziewałby się, że będzie dostępny, a zatem udostępnienie ich niekoniecznie ma sens.

2 Te kategorie rozszerzeń są tak zróżnicowane, że nie można powiedzieć, że wszystkie działają. Jednak teoretycznie powinni i prześledzimy kluczowe, które nie.

3 Te kategorie rozszerzeń mogą korzystać z środowisk współpracy, dlatego potrzebujemy opinii użytkowników końcowych, aby wiedzieć, że!

4 Wymagają one, aby gość miał zainstalowane narzędzia środowiska uruchomieniowego (np. Node.js) i pracować, uruchamiając kod lokalnie.

5 Te działania działają przez nawiązanie połączenia z serwerem pewnego rodzaju i może współpracować z serwerami scentralizowanymi, serwerami udostępnionymi przez gościa.

Rozszerzenia specyficzne dla projektu

Rozszerzenia zainstalowane przez hosta, które obsługują podstawową edycję, kompilowanie i debugowanie aplikacji oraz są specyficzne dla języka/platformy/biblioteki/zestawu SDK, powinny być automatycznie dostępne dla gości bez konieczności instalowania niczego. Dzięki temu hosty mogą skonfigurować swoje środowisko w celu zapewnienia wydajnego rozwoju projektu i umożliwić gościom natychmiastowe dołączenie do nich bez dodatkowych wymagań wstępnych. Ponieważ rozszerzenia specyficzne dla projektu nie są subiektywne ani osobiste w żaden sposób, mogą być deterministyczne udostępniane od hosta do gościa, bez wpływu na znane środowisko użytkownika.

Ponadto w celu obsługi rozszerzeń specyficznych dla projektu, które zainstalowano gościa, ale host nie, najlepiej zapewnić obniżoną wydajność, ale funkcjonalność (np. uzyskanie pojedynczego pliku intellisense, możliwość formatowania dokumentu).

Kategoria Przykłady Udostępnionych? Obsługiwane przez gościa?
Gramatyka/wyróżnianie składni Fish Shell, Nginx, Vetur, DotEnv, ES6 String HTML, Todo+, Rainbow CSV ❌ ✅
Usługi językowe YAML, Path Intellisense, ARM ✅1 ✅2
Schematy JSON Azure Functions ✅ ✅
Linters ESLint, Markdownlint, Code Spell Checker, PHPCS ✅ ✅2
Formatters Ładniejszy, Beautify ✅ ✅2
Debugery Python, Debugger for Chrome ✅3 ❌4
Moduły uruchamiacze testów Java Test Runner, Mocha Sidebar, Jest Runner, Neptune ❌5 ✅2
Podgląd plików niestandardowych Podgląd SVG, GraphViz, Rozmiar obrazu markdown ❌ ✅
Generatory plików/projektów Azure Functions, C/C++ Project Generator ❌ ❌6
Dostawcy kontroli źródła SVN, Hg ❌ ❌

1 Obecnie tylko języki C# i JavaScript/TypeScript.

2 Obsługiwałby tylko bieżący aktywny dokument, ponieważ goście nie mają dostępu do plików lokalnych.

3 Podstawowe środowisko debugowania jest współużytkowane, jednak wszystkie uruchomione serwery nie są automatycznie przekazywane.

4 Goście nie mają lokalnej kopii aplikacji, dlatego uruchomiona aplikacja i wszystkie sesje debugowania muszą rozpocząć się na maszynie hosta.

5 Dane wyjściowe przebiegu testu wymagają, aby wszystkie wynikowe terminale, okienka danych wyjściowych i błędy były również udostępniane gościom.

6 Prawie wszystkie te elementy używają modułu Node.js fs bezpośrednio do tworzenia plików, co nie zadziałałoby.

Znane problemy

Poniżej przedstawiono obecnie znane problemy z rozszerzeniem, które mogą uniemożliwić im pracę dla gości w kontekście sesji współpracy (wraz z ich obejściami), co może mieć wpływ na przepływ pracy:

Visual Studio Code

Problem Przyczyna Rozwiązanie
Używanie modułu Node.js fs do wykrywania/odczytywania plików (np. pliku konfiguracji) lub wyliczania katalogów (i nie jesteś usługą językową). Goście nie mają dostępu do plików lokalnych. 1. Bezpiecznie obniża wydajność środowiska użytkownika (jeśli jest to możliwe).

2. Użyj openTextDocument interfejsów API obszaru roboczego i findFiles , aby odczytywać i wyliczać pliki.
Tworzenie lub zapisywanie plików przy użyciu modułu Node.js fs Tak samo jak powyżej N/A Możesz użyć interfejsu openTextDocument(Uri) API do utworzenia untitled pliku, ale nie można zapisać go bezpośrednio w systemie plików w określonej ścieżce.
W zależności od biblioteki lub narzędzia dołączonego do projektu Tak samo jak powyżej 1. Utwórz pakiet rezerwowej wersji zależności z rozszerzeniem

2. Obsługa instalacji globalnej w celu odblokowania gości, jeśli zdecyduje się ją jawnie zainstalować.

3. Jeśli to możliwe, zdalnego stanu/akcji, ponieważ host będzie miał dostępne odpowiednie zależności.
Tworzenie katalogu przy użyciu modułu Node.js fs Tak samo jak powyżej Nie dotyczy
Ograniczanie funkcjonalności do dokumentów korzystających ze schematu file . Pliki po stronie gościa używają schematu vsls . Dodawanie obsługi vsls dokumentów (na przykład)
Uri.file Używanie metody i/lub Uri.fsPath/TextDocument.fileName elementów członkowskich do serializacji/analizowania identyfikatorów URI Tak samo jak powyżej Zamiast tego należy używać Uri.parse elementów i Url.toString() , które utrzymują i przestrzegają schematów plików (na przykład)
workspace.openTextDocument Używanie metody ze ścieżką pliku zamiastUri Tak samo jak powyżej Uri Podaj wystąpienie zamiast nieprzetworzonego ciągu ścieżki pliku (przykład)
workspace.rootPath Wykrywanie obecności obszaru roboczego przy użyciu właściwości Właściwość workspace.rootPath wywołuje Uri.fsPath element pierwszy workspaceFolder w obiekcie workspace, który ma ten sam problem wymieniony powyżej workspace.workspaceFolders Zamiast tego użyj właściwości , aby wykryć obecność obszaru roboczego i w razie potrzeby przyjrzyj się poszczególnym workspaceFolderUri.scheme elementom , aby określić, czy jest on lokalny, czy nie
Nie określa schematu dokumentów podczas rejestrowania usług językowych (za pomocą LanguageClientmetody lub languages.register* metody) Goście otrzymują wyniki usługi językowej zarówno z rozszerzeń lokalnych, jak i hosta, a w związku z tym, jeśli obaj uczestnicy mają zainstalowane to samo rozszerzenie usługi językowej, goście zobaczą zduplikowane wpisy dla niektórych elementów (np. automatyczne uzupełnianie, akcje kodu) Ograniczanie usług językowych tylko file do schematów i untitled (przykład)
Nie sprawdzaj dokumentów Uri.scheme przed wypełnieniem DiagnosticCollection elementu Tak samo jak powyżej Tylko wygeneruj Diagnostics dla documents których Uri.schemefile === (przykład)
Nie sprawdzaj schematu obszaru roboczego podczas powrotu Tasks z niestandardowego TaskProvider Goście wyświetlają wszystkie zadania zdalne i lokalne, a w związku z tym będą wyświetlać duplikaty, jeśli obaj uczestnicy mieli zainstalowane to samo rozszerzenie Zwracaj Tasks tylko dla WorkspaceFolders, którychfile === Uri.scheme (przykład)

Zobacz też

Masz problemy? Przejdź do strony rozwiązywania problemów lub przekaż opinię.