Extensões e suporte ao ecossistema
Um dos principais objetivos do Visual Studio Live Share é permitir que os desenvolvedores colaborem entre si, no conforto de suas ferramentas favoritas e altamente personalizadas. Dessa forma, as interações ad hoc podem ocorrer com frequência, permanecendo visualmente familiares e ergonômicas, independentemente do que você esteja ajudando. Para conseguir isso, é essencial que os participantes de uma sessão de colaboração possam continuar usando quaisquer extensões que suportem suas preferências e fluxos de trabalho pessoais (por exemplo, temas de cores/ícones, atalhos de teclado, aprimoradores de produtividade do editor).
Além disso, para tornar o ato de entrar em uma sessão de colaboração o mais instantâneo possível, mas permanecendo altamente produtivo, o objetivo do Visual Studio Live Share é permitir que os convidados aproveitem automaticamente as ferramentas específicas do projeto que o anfitrião compartilhou. Assim, você pode simplesmente clicar em um link, iniciar a ferramenta de sua escolha e começar a colaborar, sem nenhuma configuração adicional. Para conseguir isso, é essencial que as extensões, que alimentam o fluxo de trabalho principal de edição, criação e depuração, sejam "remotas" de forma transparente do anfitrião para o convidado, para que recursos como preenchimento automático, ir para a definição e depuração funcionem perfeitamente.
Este documento abrange o estado atual conhecido do vasto ecossistema de extensão, bem como um "scorecard" para os objetivos mencionados acima. Se você encontrar uma extensão que não atenda a esses critérios e seja fundamental para seu fluxo de trabalho pessoal, informe-nos!
Extensões específicas do usuário
As extensões que oferecem suporte a personalizações específicas do usuário devem funcionar para o anfitrião e para todos os convidados. Se uma extensão não funcionar corretamente para o anfitrião, isso seria uma regressão e provavelmente um bug no Visual Studio Live Share (registre um problema se encontrar um!). Se uma extensão não se comportar conforme o esperado para um convidado, ela poderá exigir alterações na própria extensão, e trabalharemos com o ecossistema para abordar/melhorar esses cenários.
Visual Studio Code
1 A menos que um usuário já estivesse familiarizado com um snippet, ele não esperaria que estivesse disponível e, portanto, compartilhá-lo não faz necessariamente sentido.
2 Essas categorias de extensão são tão diversificadas que é impossível afirmar que todas funcionam. No entanto, em teoria, deveriam funcionar, e nós acompanharemos as principais que não funcionam.
3 Essas categorias de extensão podem se beneficiar de experiências colaborativas e, por isso, precisamos do feedback do usuário final para saber disso!
4 Requer que o convidado tenha as ferramentas de tempo de execução instaladas (por exemplo, Node.js) e funcionem executando o código localmente.
5 Funcionam conectando-se a um servidor de algum tipo e podem trabalhar com servidores centralizados ou compartilhados pelo convidado.
Extensões específicas do projeto
Extensões instaladas pelo anfitrião, que oferecem suporte à edição, criação e depuração de um aplicativo e são específicas para uma linguagem/plataforma/biblioteca/SDK, devem estar automaticamente disponíveis para os convidados, sem exigir que instalem nada. Assim, os anfitriões podem configurar seu ambiente para apoiar o desenvolvimento produtivo de um projeto e permitir que seus convidados participem instantaneamente, sem pré-requisitos adicionais. Como as extensões específicas do projeto não são subjetivas ou pessoais de forma alguma, elas podem ser compartilhadas de forma determinística do anfitrião para o convidado, sem afetar o ambiente conhecido de ninguém.
Além disso, para oferecer suporte a extensões específicas do projeto que um convidado instalou, mas o anfitrião não, o ideal seria fornecer uma experiência degradada, mas funcional (por exemplo, obter o IntelliSense de arquivo único, ser capaz de formatar um documento).
| Categoria | Exemplo(s) | Compartilhado? | Suporte para convidado? |
|---|---|---|---|
| Destaque de sintaxe/gramáticas | Fish Shell, Nginx, Vetur, DotEnv, ES6 String HTML, Todo+, Rainbow CSV | ❌ | ✅ |
| Serviços de linguagem | YAML, Path Intellisense, ARM | ✅1 | ✅2 |
| Esquemas JSON | Azure Functions | ✅ | ✅ |
| Linters | ESLint, Markdownlint, Code Spell Checker, PHPCS | ✅ | ✅2 |
| Formatadores | Prettier, Beautify | ✅ | ✅2 |
| Depuradores | Python, Debugger for Chrome | ✅3 | ❌4 |
| Executores de teste | Java Test Runner, Mocha Sidebar, Jest Runner, Neptune | ❌5 | ✅2 |
| Pré-visualizadores de arquivos personalizados | SVG Preview, GraphViz, Markdown Image Size | ❌ | ✅ |
| Geradores de arquivo/projeto | Azure Functions, C/C++ Project Generator | ❌ | ❌6 |
| Provedores de controle do código-fonte | SVN, Hg | ❌ | ❌ |
1 Atualmente apenas C# e JavaScript/TypeScript.
2 Suportaria apenas o documento ativo atual, já que os convidados não têm acesso ao arquivo local.
3 A experiência de depuração principal é compartilhada, mas todos os servidores iniciados não são encaminhados automaticamente.
4 Os convidados não têm uma cópia local do aplicativo e, por isso, o aplicativo em execução e todas as sessões de depuração precisam ser iniciadas no computador do anfitrião.
5 A saída de uma execução de teste exigiria que todos os terminais, painéis de saída e erros resultantes também fossem compartilhados com os convidados.
6 Quase todos eles usariam o módulo Node.js fs diretamente para criar arquivos, o que não funcionaria.
Problemas conhecidos
Veja a seguir alguns problemas de extensão atualmente conhecidos que podem impedi-los de funcionar para convidados no contexto de uma sessão de colaboração (junto com suas soluções alternativas) e, portanto, podem afetar seu fluxo de trabalho:
Visual Studio Code
| Problema | Motivo | Solução alternativa |
|---|---|---|
Usar o módulo fs Node.js para detectar/ler arquivos (por exemplo, um arquivo de configuração) ou enumerar diretórios (e você não é um serviço de linguagem). |
Os convidados não têm acesso a arquivos locais. | 1. Degrade de forma suave a experiência do usuário (se possível). 2. Use as APIs do workspace openTextDocument e findFiles para ler e enumerar arquivos. |
Usar o módulo fs Node.js para criar ou gravar arquivos |
O mesmo que o descrito acima | N/D Você pode usar a API openTextDocument(Uri) para criar um arquivo untitled, mas não pode salvá-lo diretamente no sistema de arquivos, em um caminho específico. |
| Dependendo de uma biblioteca ou ferramenta integrada ao projeto | O mesmo que o descrito acima | 1. Agrupe uma versão de fallback da dependência com a extensão 2. Ofereça suporte à instalação global para desbloquear convidados se eles optarem por instalá-lo explicitamente. 3. Se possível, remova o estado/ação, pois o anfitrião terá as dependências corretas disponíveis. |
Usar o módulo fs Node.js para criar um diretório |
O mesmo que o descrito acima | N/A |
Restringir a funcionalidade a documentos que usam o esquema file. |
Os arquivos do lado do convidado usam o esquema vsls. |
Adicionar suporte para documentos vsls (exemplo) |
Usar o método Uri.file e/ou membros Uri.fsPath/TextDocument.fileName para serializar/analisar URIs |
O mesmo que o descrito acima | Use Uri.parse e Url.toString() , em vez disso, que mantêm e respeitam os esquemas de arquivos (exemplo) |
Usar o método workspace.openTextDocument com um caminho de arquivo em vez de um Uri |
O mesmo que o descrito acima | Forneça uma instância Uri em vez de uma cadeia de caracteres de caminho de arquivo bruto (exemplo) |
Usar a propriedade workspace.rootPath para detectar a presença de um workspace |
A propriedade workspace.rootPath chama Uri.fsPath no primeiro workspaceFolder no workspace, que tem o mesmo problema mencionado acima |
Em vez disso, use a propriedade workspace.workspaceFolders para detectar a presença de um workspace e, se necessário, analise cada workspaceFolder Uri.scheme para determinar se é local ou não |
Não especificar um esquema de documento ao registrar serviços de linguagem (por meio de um LanguageClient ou dos métodos languages.register*) |
Os convidados recebem os resultados do serviço de linguagem de suas extensões locais e do anfitrião. Portanto, se os dois participantes tiverem a mesma extensão de serviço de linguagem instalada, os convidados verão entradas duplicadas para certas coisas (por exemplo, preenchimento automático, ações de código) | Restringir os serviços de linguagem apenas a esquemas file e untitled (exemplo) |
Não verificar um Uri.scheme do documento antes de preencher um DiagnosticCollection para ele |
O mesmo que o descrito acima | Gerar apenas Diagnostics para documents cujo Uri.scheme === file (exemplo) |
Não verificar o esquema do workspace ao retornar Tasks de um TaskProvider personalizado |
Os convidados exibem todas as tarefas remotas e locais e, portanto, exibiriam duplicatas se os dois participantes tivessem a mesma extensão instalada | Retorna apenas Tasks para WorkspaceFolder cujo Uri.scheme === file (exemplo) |
Confira também
- Suporte de linguagem e plataforma
- Requisitos de conectividade do Live Share
- Funcionalidades de segurança do Live Share
- Todos os bugs, solicitações de recursos e limitações importantes
- Todas as solicitações de recursos e limitações
Está tendo problemas? Confira Solução de problemas ou envie comentários.