• a config file exports the wrong shape
• a client bundle relies on dynamic import.meta.env access
• a workspace mixes test and benchmark APIs in ways that make results harder to trust
• a server option disables a protection that Vite enables by default

That is why eslint-plugin-vite is intentionally centered on config safety and workspace correctness.

A focused scope keeps the plugin useful​

General-purpose ESLint stacks already cover broad style and correctness concerns. This plugin earns its place by catching issues that those broader stacks typically do not model.

That scope also shapes the presets​

The current presets are organized around practical Vite workflows rather than generic severity tiers alone:

• config-file hardening
• client runtime constraints
• Vitest workspace correctness
• benchmark/test separation

As the rule set grows, keeping that workflow-oriented focus is more important than chasing raw rule count.

That baseline work matters because the project is no longer a generic plugin template. The site, manifest, and docs structure need to communicate that this package is about Vite config safety, client-runtime correctness, and Vitest workspace discipline.

What changed in the baseline pass​

• Vite-branded icons and favicon assets were generated for the docs site.
• Docusaurus navigation now has dedicated maintainer-facing sections for ADRs and charts.
• Mermaid support is enabled so architectural notes can stay visual and close to the codebase.
• Template leftovers were trimmed so the public docs no longer read like a renamed scaffold.

Why this matters before adding more rules​

A wider rule catalog is only helpful when the surrounding repo stays understandable and trustworthy. Maintaining a clean baseline keeps future rule work easier to explain, easier to review, and easier to release.