eclipse-wildwebdeveloper / eclipse-wildwebdeveloper/wildwebdeveloper

Improve preference sharing

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

Nobody has claimed this yet.

Dominant language
Java
Stars
201
Forks
76
Avg merge
4d 7h
Merged PRs (30d)
21

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

Contributor guide

Open the contributing guide

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.

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.

Assessment

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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.