Improve preference sharing

Open
#1,335 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Tech stack
css, html, javascript, sass, typescript, vscode

Research direction

Begin with the Vue implementation PoC and the preference implementations it informed, comparing how HTML, CSS, JS/TS and Vue preferences are currently handled. Review the VS Code package.json/settings.json model and the LSP4E integration points mentioned in the issue, then establish an agreed scope for adapters, defaults, aliases, and any workspace or project settings before implementation.

Written by the indexing model from the issue text.

Description

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

Dominant language
Java
Stars
203
Forks
76
Avg merge
1d 5h
Merged PRs (30d)
30

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from eclipse-wildwebdeveloper/wildwebdeveloper

All issues in eclipse-wildwebdeveloper/wildwebdeveloper

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.