eslint-plugin-vite Blog https://nick2bad4u.github.io/eslint-plugin-vite/blog eslint-plugin-vite Blog Sat, 21 Mar 2026 00:00:00 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed en <![CDATA[Why eslint-plugin-vite centers config safety and Vitest workspaces]]> https://nick2bad4u.github.io/eslint-plugin-vite/blog/config-safety-and-workspaces https://nick2bad4u.github.io/eslint-plugin-vite/blog/config-safety-and-workspaces Sat, 21 Mar 2026 00:00:00 GMT When Vite projects go wrong, the problem is often not a generic syntax issue. It is usually a mismatch with one of Vite's runtime contracts:

  • 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.

]]> architecture vite vitest <![CDATA[Establishing the eslint-plugin-vite baseline]]> https://nick2bad4u.github.io/eslint-plugin-vite/blog/vite-baseline https://nick2bad4u.github.io/eslint-plugin-vite/blog/vite-baseline Sat, 21 Mar 2026 00:00:00 GMT eslint-plugin-vite now has a clearer baseline for the things maintainers and users touch first: branding assets, docs navigation, ADRs, charts, and repository-wide validation.

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.

]]> announcement docs branding