Extensions et support de l’écosystème
L’un des objectifs principaux de Visual Studio Live Share est de permettre aux développeurs de collaborer entre eux, tout en profitant du confort de leurs outils préférés et hautement personnalisés. De cette façon, les interactions ad hoc peuvent se produire fréquemment, tout en restant visuellement familières et ergonomiques, peu importe sur quoi vous aidez. Pour y parvenir, il est essentiel que les participants à une session de collaboration puissent continuer à utiliser toutes les extensions qui prennent en charge leurs préférences personnelles et flux de travail (par exemple, thèmes de couleur/icônes, raccourcis clavier, améliorateurs de productivité de l’éditeur).
De plus, afin de rendre l’acte de rejoindre une session de collaboration aussi instantané que possible, tout en restant très productif, l’objectif de Visual Studio Live Share est de permettre aux invités de tirer automatiquement parti des outils spécifiques au projet que leur hôte a partagés. Ainsi, vous pouvez simplement cliquer sur un lien, lancer votre outil préféré et commencer à collaborer, sans configuration supplémentaire. Pour y parvenir, il est essentiel que les extensions qui alimentent le flux de travail d’édition, de build et de débogage soient « transférées à distance » de manière transparente de l’hôte à l’invité, afin que des fonctionnalités comme l’auto-complétion, l’accès à la définition et le débogage « fonctionnent tout simplement ».
Ce document couvre l’état actuel connu pour le vaste écosystème d’extensions, ainsi qu’une « fiche de score » pour les objectifs susmentionnés. Si vous rencontrez une extension qui ne répond pas à ces critères et qui est essentielle à votre flux de travail personnel, veuillez nous le faire savoir !
Extensions spécifiques à l’utilisateur
Les extensions qui prennent en charge des personnalisations spécifiques à l’utilisateur doivent fonctionner pour l’hôte, et devraient fonctionner pour tous les invités. Si une extension ne fonctionne pas correctement pour l’hôte, ce serait une régression, et c’est probablement un bug dans Visual Studio Live Share (veuillez soumettre un problème si vous en voyez un !). Si une extension ne se comporte pas comme prévu pour un invité, elle peut nécessiter des modifications dans l’extension elle-même, et nous travaillerons avec l’écosystème pour résoudre/améliorer ces scénarios.
Visual Studio Code
1 Sauf si un utilisateur connaissait déjà un extrait, il ne s’attendrait pas à ce qu’il soit disponible, et par conséquent, les rendre partagés n’a pas nécessairement de sens.
2 Ces catégories d’extensions sont si diverses qu’il est impossible de dire qu’elles fonctionnent toutes. Cependant, en théorie, elles devraient fonctionner, et nous suivrons celles qui ne fonctionnent pas.
3 Ces catégories d’extensions peuvent bénéficier d’expériences collaboratives, et donc nous avons besoin des retours des utilisateurs finaux pour le savoir !
4 Celles-ci nécessitent que l’invité ait installé les outils d’exécution (par exemple, Node.js) et fonctionnent en exécutant du code localement.
5 Celles-ci fonctionnent en se connectant à un serveur quelconque et peuvent fonctionner avec des serveurs centralisés ou des serveurs que l’invité a partagés.
Extensions spécifiques au projet
Les extensions installées par l’hôte, qui prennent en charge l’édition, le build et le débogage d’une application, et qui sont spécifiques à un langage/plateforme/bibliothèque/SDK, devraient être automatiquement disponibles pour les invités, sans qu’ils aient besoin d’installer quoi que ce soit. Ainsi, les hôtes peuvent configurer leur environnement pour prendre en charge un développement productif du projet, et permettre à leurs invités de les rejoindre instantanément, sans prérequis supplémentaires. Comme les extensions spécifiques au projet ne sont subjectives ou personnelles d’aucune manière, elles peuvent être partagées de manière déterministe de l’hôte à l’invité, sans affecter l’environnement familier de quiconque.
De plus, pour prendre en charge les extensions spécifiques au projet qu’un invité a installées, mais que l’hôte n’a pas, elles devraient idéalement offrir une expérience dégradée mais fonctionnelle (par exemple, obtenir IntelliSense pour un seul fichier, pouvoir formater un document).
| Catégorie | Exemple(s) | Partagées ? | Supportée par l’invité ? |
|---|---|---|---|
| Grammaires / Mise en évidence de la syntaxe | Fish Shell, Nginx, Vetur, DotEnv, ES6 String HTML, Todo+, Rainbow CSV | ❌ | ✅ |
| Services de langage | YAML, Path Intellisense, ARM | ✅1 | ✅2 |
| Schémas JSON | Azure Functions | ✅ | ✅ |
| Linters | ESLint, Markdownlint, Code Spell Checker, PHPCS | ✅ | ✅2 |
| Formateurs | Prettier, Beautify | ✅ | ✅2 |
| Débogueurs | Python, Debugger for Chrome | ✅3 | ❌4 |
| Exécuteurs de tests | Java Test Runner, Mocha Sidebar, Jest Runner, Neptune | ❌5 | ✅2 |
| Aperçus de fichiers personnalisés | SVG Preview, GraphViz, Markdown Image Size | ❌ | ✅ |
| Générateurs de fichiers/projets | Azure Functions, C/C++ Project Generator | ❌ | ❌6 |
| Fournisseurs de contrôle de source | SVN, Hg | ❌ | ❌ |
1 Actuellement, uniquement C# et JavaScript/TypeScript.
2 Ne prendrait en charge que le document actif actuel, car les invités n’ont pas accès aux fichiers locaux.
3 L’expérience de débogage principale est partagée, cependant, tous les serveurs lancés ne sont pas automatiquement redirigés.
4 Les invités n’ont pas de copie locale de l’application, et par conséquent, l’application en cours d’exécution et toutes les sessions de débogage doivent démarrer sur la machine de l’hôte.
5 Les résultats d’une exécution de test nécessiteraient que tous les terminaux résultants, les volets de sortie et les erreurs soient également partagés avec les invités.
6 Presque toutes utiliseraient le module Node.js fs directement pour créer des fichiers, ce qui ne fonctionnerait pas.
Problèmes connus
Les extensions suivantes sont des problèmes connus, qui pourraient les empêcher de fonctionner pour les invités dans le cadre d’une session de collaboration (ainsi que leurs solutions de contournement), et donc, pourraient impacter leur flux de travail :
Visual Studio Code
| Problème | Motif | Solution de contournement |
|---|---|---|
Utilisation du module Node.js fs pour détecter/lire des fichiers (par exemple, un fichier de configuration) ou énumérer des répertoires (et vous n’êtes pas un service de langage). |
Les invités n’ont pas accès aux fichiers locaux. | 1. Dégradez gracieusement l’expérience utilisateur (si possible). 2. Utilisez les API openTextDocument et findFiles du workspace pour lire et énumérer les fichiers. |
Utilisation du module Node.js fs pour créer ou écrire des fichiers |
Identique à ce qui précède | N/A Vous pouvez utiliser l’API openTextDocument(Uri) pour créer un fichier untitled, mais vous ne pouvez pas l’enregistrer directement dans le système de fichiers, à un chemin spécifique. |
| Dépendance à une bibliothèque ou un outil inclus dans le projet | Identique à ce qui précède | 1. Regroupez une version de secours de la dépendance avec l’extension 2. Prenez en charge l’installation globale pour débloquer les invités s’ils choisissent de l’installer explicitement. 3. Déléguez l’état/l’action si possible, car l’hôte disposerait des bonnes dépendances. |
Utilisation du module Node.js fs pour créer un répertoire |
Identique à ce qui précède | N/A |
Restriction de la fonctionnalité aux documents utilisant le schéma file. |
Les fichiers du côté de l’invité utilisent le schéma vsls. |
Ajoutez la prise en charge des documents vsls (exemple) |
Utilisation de la méthode Uri.file et/ou des membres Uri.fsPath/TextDocument.fileName pour sérialiser/analyser les URI |
Identique à ce qui précède | Utilisez Uri.parse et Url.toString() à la place, qui maintiennent et respectent les schémas de fichiers (exemple) |
Utilisation de la méthode workspace.openTextDocument avec un chemin de fichier au lieu d’un Uri |
Identique à ce qui précède | Fournissez une instance Uri au lieu d’une simple chaîne de chemin de fichier brut (exemple) |
Utilisation de la propriété workspace.rootPath pour détecter la présence d’un workspace |
La propriété workspace.rootPath appelle Uri.fsPath sur le premier workspaceFolder dans le workspace, ce qui pose le même problème mentionné ci-dessus |
Utilisez plutôt la propriété workspace.workspaceFolders pour détecter la présence d’un workspace, et si nécessaire, examinez chaque Uri.scheme de workspaceFolder pour déterminer s’il est local ou non |
Ne pas spécifier un schéma de document lors de l’enregistrement des services linguistiques (soit via un LanguageClient, soit les méthodes languages.register*) |
Les invités reçoivent les résultats des services linguistiques à la fois de leurs extensions locales et de l’hôte, et donc, si les deux participants ont installé la même extension de service linguistique, les invités verront des entrées en double pour certaines choses (par exemple, auto-complétion, actions de code) | Restreignez les services linguistiques uniquement aux schémas file et untitled (exemple) |
Ne pas vérifier le schéma Uri.scheme d’un document avant de peupler un DiagnosticCollection pour celui-ci |
Identique à ce qui précède | Générez uniquement un Diagnostics pour les documents dont le Uri.scheme === file (exemple) |
Ne pas vérifier le schéma du workspace lors du retour de Tasks à partir d’un TaskProvider personnalisé |
Les invités affichent toutes les tâches distantes et locales, et donc, ils afficheraient des doublons si les deux participants avaient installé la même extension | Retournez uniquement Tasks pour les WorkspaceFolder dont le Uri.scheme === file (exemple) |
Voir aussi
- Prise en charge de langues et de plateformes
- Exigences de connectivité pour Live Share
- Fonctionnalités de sécurité de Live Share
- Tous les bogues majeurs, toutes les demandes de fonctionnalités et toutes les limitations
- Toutes les demandes de fonctionnalités et limitations
Vous rencontrez des problèmes ? Voir la section dépannage ou fournir des commentaires.