Sdílet prostřednictvím

Podpora rozšíření a ekosystému

  • Článek

Jedním z hlavních cílů sady Visual Studio Live Share je umožnit vývojářům spolupracovat mezi sebou, od pohodlí oblíbených a vysoce přizpůsobených nástrojů. Díky tomu se ad hoc interakce můžou vyskytovat často, zatímco zůstávají vizuálně známé a ergonomické, bez ohledu na to, s čím pomáháte. Aby toho bylo dosaženo, je důležité, aby účastníci v rámci relace spolupráce mohli dál používat všechna rozšíření, která podporují své osobní předvolby a pracovní postupy (např. motivy barev/ikon, klíčové vazby, vylepšení produktivity editoru).

Pokud chcete, aby se relace spolupráce co nejrychleji připojila, i když zůstává vysoce produktivní, je cílem služby Visual Studio Live Share umožnit hostům automaticky využívat nástroje specifické pro projekt, které sdílí jejich hostitel. Tímto způsobem můžete jednoduše kliknout na odkaz, spustit nástroj podle výběru a začít spolupracovat bez jakéhokoli dalšího nastavení. Aby toho bylo dosaženo, je důležité, aby rozšíření, která podporují základní úpravy, sestavování a ladění pracovního postupu, byla transparentně vzdálená od hostitele k hostu, takže věci jako automatické dokončování, přechod k definici a ladění "prostě fungují".

Tento dokument popisuje aktuální známý stav rozsáhlého ekosystému rozšíření a také přehled výkonnostních metrik pro výše uvedené cíle. Pokud narazíte na rozšíření, které nesplňuje tato kritéria a je pro váš osobní pracovní postup důležité, dejte nám prosím vědět!

Uživatelsky specifická rozšíření

Rozšíření, která podporují vlastní nastavení specifická pro uživatele, musí fungovat pro hostitele a měla by fungovat pro všechny hosty. Pokud rozšíření nefunguje správně pro hostitele, jedná se o regresi a pravděpodobně se jedná o chybu v sadě Visual Studio Live Share (pokud se zobrazí nějaký problém ). Pokud se rozšíření pro hosta nechová podle očekávání, může vyžadovat změny samotného rozšíření a budeme pracovat s ekosystémem, abychom tyto scénáře vyřešili nebo vylepšili.

Visual Studio Code

Kategorie Příklady Podporuje se host? Spolupráci?
Barevné motivy One Dark Pro, Output Colorizer, Rainbow String, Colored Regions, Indented Block Highlighting, Todo Highlight, Bracket Pair Colorizer ✅ –
Sady ikon vscode-icons, Visual Studio Classic Icons ✅ –
Klíčové vazby Vim, IntelliJ IDEA Keybindings, Emacs Friendly Keymap ✅ –
Fragmenty kódu Fragmenty kódu Angular v5, fragmenty kódu HTML, ikony SVG, hlavička souboru ✅ Není k dispozici1
Organizace Nastavení Sync, Project Manager, Timeit, Checkpoints, TODO Parser, Favorites (❌), Bookmarks (❌) ✅2 Není k dispozici3
Produktivita GitLens, značka automatického přejmenování, obrys kódu, zvýraznění barvy, zvýšení výběru, závorka, náhled obrázku, pomocník JSON (najetí), výběr barvy, kopírování wordu v kurzoru, codemetrics (CodeLens), spoluautoři Gitu, JavaScript Booster (CodeActions), turbo konzolový protokol, Goto Next/Previous Member, autosousoubor, NPM Import verze (❌), náklady na import (❌) ✅2 ❌3
Seznamy REPLs REST Client, Code Runner, Quokka.js, R ✅4 ❌3
Správci zdrojů mssql, ftp-simple, Azure Functions, Docker, Brew Services ✅5 ❌3

1Pokud už uživatel nebyl obeznámen s fragmentem kódu, neočekával by, že bude k dispozici, a proto jejich sdílení nemusí nutně dávat smysl.

2Tyto kategorie rozšíření jsou tak různorodé, že není možné říci, že všechny fungují. Teoreticky by ale měli a my budeme sledovat ty klíčové, které ne.

3Tyto kategorie rozšíření mohou těžit z prostředí pro spolupráci, a proto potřebujeme zpětnou vazbu koncových uživatelů, abychom to věděli!

4Vyžadují, aby host měl nainstalované moduly runtime (např. Node.js) a fungovaly místně spuštěním kódu.

5Tato práce funguje připojením k serveru nějakého druhu a může pracovat s centralizovanými servery, servery, které host sdílí.

Rozšíření specifická pro projekt

Rozšíření nainstalovaná hostitelem, která podporují základní úpravy, sestavování a ladění aplikace a jsou specifická pro jazyk, platformu, knihovnu nebo sadu SDK, by měla být automaticky dostupná hostům, aniž by museli instalovat cokoli. Díky tomu můžou hostitelé nastavit své prostředí tak, aby podporovaly produktivní vývoj projektu, a umožnit svým hostům okamžité připojení bez dalších požadavků. Vzhledem k tomu, že rozšíření specifická pro projekty nejsou žádným způsobem subjektivní ani osobní, dají se deterministicky sdílet z hostitele na hosta, aniž by to mělo vliv na známé prostředí každého.

Kromě toho, aby bylo možné podporovat rozšíření specifická pro projekty, která host nainstaloval, ale hostitel ne, v ideálním případě by poskytoval snížený výkon, ale funkční prostředí (např. získání funkce IntelliSense s jedním souborem, schopnost formátovat dokument).

Kategorie Příklady Sdílené? Podporuje se host?
Gramatiky / zvýraznění syntaxe Rybí shell, Nginx, Vetur, DotEnv, ES6 String HTML, Todo+, Rainbow CSV ❌ ✅
Jazykové služby YAML, Path IntelliSense, ARM ✅1 ✅2
Schémata JSON Azure Functions ✅ ✅
Lintery ESLint, Markdownlint, Kontrola pravopisu kódu, PHPCS ✅ ✅2
Formatters Hezčí, Beautify ✅ ✅2
Debuggery Python, Ladicí program pro Chrome ✅3 ❌4
Test Runners Java Test Runner, Mocha Sidebar, Postman Runner, Jest Runner, Neptun ❌5 ✅2
Vlastní náhledy souborů Náhled SVG, GraphViz, Velikost obrázku Markdownu ❌ ✅
Generátory souborů/projektů Generátor projektů Azure Functions, C/C++ ❌ ❌6
Zprostředkovatelé správy zdrojového kódu SVN, Hg ❌ ❌

1V současné době pouze jazyk C# a JavaScript/TypeScript.

2Podporuje pouze aktuální aktivní dokument, protože hosté nemají přístup k místnímu souboru.

3Základní prostředí ladění je sdílené, ale všechny spuštěné servery se automaticky nepřesměrují.

4Hosté nemají místní kopii aplikace, a proto spuštěnou aplikaci a všechny ladicí relace musí spustit na počítači hostitele.

5Výstup testovacího běhu by vyžadoval, aby se s hosty sdílely také všechny výsledné terminály, výstupní podokna a chyby.

6Téměř všechny by používaly modul Node.js fs přímo k vytváření souborů, což by nefungovalo.

Známé problémy

V současné době jsou známé problémy s rozšířením, které by jim mohly bránit v práci pro hosty v kontextu relace spolupráce (spolu s jejich alternativními řešeními), a to může mít vliv na pracovní postup:

Visual Studio Code

Problém Důvod Alternativní řešení
Použití modulu Node.js fs k detekci a čtení souborů (např. konfiguračního souboru) nebo vytvoření výčtu adresářů (a nejste službou jazyka). Hosté nemají přístup k místním souborům. 1. Elegantně degradujte uživatelské prostředí (pokud je to možné).

2. Pomocí openTextDocument rozhraní API pracovního findFiles prostoru můžete číst a vypsat soubory.
Vytvoření nebo zápis souborů pomocí modulu Node.js fs Stejné jako výše uvedené Není k openTextDocument(Uri) dispozici rozhraní API k vytvoření untitled souboru, ale nemůžete ho uložit přímo do systému souborů v konkrétní cestě.
V závislosti na knihovně nebo nástroji v sadě projektů Stejné jako výše uvedené 1. Sbalte náhradní verzi závislosti s rozšířením.

2. Podpora globální instalace, aby odblokovali hosty, pokud se rozhodli explicitně nainstalovat.

3. Pokud je to možné, vzdálený stav nebo akci, protože hostitel by měl k dispozici správné závislosti.
Vytvoření adresáře pomocí modulu Node.js fs Stejné jako výše uvedené –
Omezení funkčnosti na dokumenty, které používají file schéma. Soubory na straně hosta používají vsls schéma. Přidání podpory dokumentů vsls (příklad)
Uri.file Použití metody a/nebo Uri.fsPath/TextDocument.fileName členů k serializaci/parsování identifikátorů URI Stejné jako výše uvedené Použití Uri.parse a Url.toString() místo toho, které udržují a respektují schémata souborů (příklad)
workspace.openTextDocument Použití metody s cestou k souboru místo cesty k souboruUri Stejné jako výše uvedené Uri Zadejte instanci místo řetězce cesty k nezpracovaným souborům (příklad).
workspace.rootPath Zjištění přítomnosti pracovního prostoru pomocí vlastnosti Vlastnost workspace.rootPath volá Uri.fsPath první workspaceFolder v objektu workspace, který má stejný problém uvedený výše. workspace.workspaceFolders Tuto vlastnost použijte ke zjištění přítomnosti pracovního prostoru, a pokud je to potřeba, podívejte se na každou Uri.schemeworkspaceFolderz nich a zjistěte, jestli je místní nebo ne.
Nezadávejte schéma dokumentů při registraci jazykových služeb (buď prostřednictvím LanguageClientmetody , nebo languages.register* prostřednictvím metody). Hosté obdrží výsledky jazykové služby z místních rozšíření i hostitele, a proto pokud mají oba účastníci nainstalované stejné rozšíření jazykové služby, zobrazí se hostům duplicitní položky pro určité věci (např. automatické dokončování, akce kódu). Omezení jazykových služeb pouze file na schémata (untitledpříklad)
Kontrola dokumentu před naplněním DiagnosticCollection dokumentu Uri.scheme Stejné jako výše uvedené Vygenerujte Diagnostics pouze pro documents čí Uri.schemefile === (příklad)
Při návratu z vlastního schématu pracovního prostoru se nekontroluje Tasks schéma pracovního prostoru TaskProvider Hosté zobrazují všechny vzdálené a místní úlohy, a proto by se zobrazily duplicity, pokud by oba účastníci měli nainstalované stejné rozšíření. Vrátí se Tasks jenom pro WorkspaceFoldery, jejichžfile === Uri.scheme (příklad)

Viz také

Máte potíže? Podívejte se na článek o odstraňování potíží nebo nám pošlete svůj názor.