EditorConfig support as a "Generic" option for editor setup
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Quiet
- Domain
- cli, developer-experience, tooling
Research direction
Start by tracing the existing editor setup options for VS Code and Zed, then inspect the vp fmt and vp format entry points. Compare the current Oxfmt configuration with the requested .editorconfig behavior and define how conflicts should be reported or synchronized. Done means the scope and behavior of a Generic or EditorConfig option are implemented and verified.
Written by the indexing model from the issue text.
Description
Description
EditorConfig is a standard for configuring editors through one file (.editorconfig) instead of multiple (.vscode, .zed, .idea, etc)
A while ago, I suggested on the VoidZero Discord the idea of adding a generic option for editor setup, which would automatically create a .editorconfig file with as many formatting options that overlaps with Oxfmt.
I took a bit of a look at the specification, and admittedly it is quite small, so I'm not sure if this is something the team wants to take on and maintain. I'm willing to help if I can get some help in being pointed in the right direction to implement this.
Suggested solution
Like the image above tries to illustrate, there could be a new "Generic" or "EditorConfig" button that, when applied, creates a .editorconfig file that matches the default/current Oxfmt config (as much as possible).
When vp fmt/vp format is ran, it would check the EditorConfig file and the current Oxfmt file. If relevant configurations conflict from both .editorconfig and the Oxfmt config, there could be a printed warning that states that the configuration is not in sync and to run a command to sync the config? This part might be the fuzziest part of EditorConfig support to be honest.
Alternative
Selecting all the options in the menu, which is currently quite limited (as of writing, only contains VS Code and Zed)
Additional context
No response
Validations
- Read the Contributing Guidelines.
- Confirm this request is for Vite+ itself and not for Vite, Vitest, tsdown, Rolldown, or Oxc.
- Check that there isn't already an issue requesting the same feature.
- Dominant language
- Rust
- Stars
- 5.8k
- Forks
- 263
- Avg merge
- 1d 4h
- Merged PRs (30d)
- 148
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from voidzero-dev/vite-plus
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
voidzero-dev/vite-plus#2097 · 10 comments · 2 reactions ·
-
pending triage
Difficulty 5/5 Over a week Newbie friendliness 45/100
voidzero-dev/vite-plus#2781 · 2 reactions ·
-
enhancement
voidzero-dev/vite-plus#2766 · 4 comments · 1 reaction · 1 assignee ·
-
enhancement
voidzero-dev/vite-plus#2764 · 3 comments · 1 assignee ·
-
pending triage
Difficulty 3/5 1-2 days Newbie friendliness 68/100
voidzero-dev/vite-plus#2735 ·
All issues in voidzero-dev/vite-plus
Similar issues
-
Browser (wasm) relay client cannot connect to relays whose URL has a trailing-dot FQDN hostname Open
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
n0-computer/iroh#4550 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
paritytech/zombienet-sdk#591 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
farion1231/cc-switch#7638 · 1 comment ·
-
onnx-ir re-exports ModelProto and GraphProto but not NodeProto, AttributeProto and AttributeType Open
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100