Improve preference sharing

Aberta
  • Algo errado?
#1,335 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
25/100
Tipo de issue
Funcionalidade
Clareza
Precisa de esclarecimento
Status de atividade
Estagnada
Stack de tecnologia
css, html, javascript, sass, typescript, vscode
Domínio
developer-experience, tooling

Direção de pesquisa

Comece com a PoC de implementação do Vue e com as implementações de preferências que ela orientou, comparando como as preferências de HTML, CSS, JS/TS e Vue são tratadas atualmente. Revise o modelo package.json/settings.json do VS Code e os pontos de integração do LSP4E mencionados na issue; em seguida, estabeleça um escopo acordado para adapters, padrões, aliases e quaisquer configurações de workspace ou projeto antes da implementação.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

For now is nighmare, especially sharing between servers

  1. There are HTML, CSS, JS/TS preferences. Each one implemented manuly
  2. HTML server read CSS preferences but completely ignore these from JS/TS
  3. Vue could use HTML, LESS, JS, TS, SASS, CSS and others but each time have to implement manually
  4. Same problems appear in case when we introduce some global preferences (format on save, insert mode, word matching settings)
  5. There is no support for aliasing, for example typescript server embeded in HTML LS require different names

I think this can and should be simplified by:

  1. Ability to use some informations directly from vscode package.json + some standard UI editors
  2. Extensions that allow to register configuration sections adapters + default settings store (like settings.json in vscode)
  3. Maybe in future support for settings scope (workspace and project level)

I don't know where this code should be store. I did some PoC during Vue implementation and can clean this for wildwebdeveloper.common, and/or should be prepared for LSP4E directly

Linguagem predominante
Java
Estrelas
203
Forks
76
Merge médio
1d 5h
PRs com merge (30d)
30

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de eclipse-wildwebdeveloper/wildwebdeveloper

Todas as issues de eclipse-wildwebdeveloper/wildwebdeveloper

Issues semelhantes

Mais issues de Java

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.