voidzero-dev/vite-plus

Vite+ is worth a look if you maintain a Vite-based web project and are tired of coordinating separate configs, versions and commands for dev, test, lint, format and build. It is a young project, so treat the migration as an experiment rather than a default for critical repos.

The problem

A typical web project already has a dev server, a test runner, a linter, a formatter, a bundler for libraries, and a package manager. Each wants its own config file and its own version, and CI has to invoke them separately. Vite+ collapses those commands into one vp binary and one vite.config.ts, so a developer runs vp dev, vp check, vp test and vp build against a shared configuration. The result is fewer config files and one place to look when a check fails.

What's different

Vite+ is not a new bundler or linter; it is a packaging layer over existing VoidZero tools: Vite, Vitest, Oxlint, Oxfmt, Rolldown, tsdown and Vite Task. The interesting part is the seam between them. vp check runs formatting, linting and type checks in one command; vp run adds caching and dependency-aware scheduling for monorepo tasks; vp env manages Node.js and package-manager versions; and vp install wraps pnpm, npm, Yarn or Bun by reading packageManager and lockfiles.

The trade-off is coupling. Configuration for test, lint, fmt, run and staged files moves into a single vite.config.ts via defineConfig from vite-plus, and vp migrate merges existing .oxlintrc*, .oxfmtrc* and lint-staged config into it. That is convenient while you stay inside the ecosystem, but it means your project's tooling versions become tied to Vite+ releases. The README acknowledges this directly: manual migrations need package-manager overrides that alias vite to @voidzero-dev/vite-plus-core and pin vitest to the bundled version, otherwise two copies can run with separate mocks and runner state. Falling outside the supported framework or tooling set is the main reason this might not fit.

Who should try it

Good fit: a team with an existing Vite project or a monorepo whose scripts are a patchwork of separate tools and who wants one CLI and one config. The vp create and vp migrate paths make a trial cheap, and the GitHub Actions action plus version-update guidance support CI usage. Poor fit: a project on a non-Vite build system, or one deeply invested in custom ESLint/Prettier setups and per-tool version pinning, where consolidating configs would create more migration work than it saves. Manual migration is documented, so installing the global vp binary is not strictly required.

Requirements and limitations

The most important constraint is version alignment. Because Vite+ bundles its own Vite core and Vitest, manual installs must alias vite and pin vitest through overrides or workspace settings, or a dependency can pull a second Vitest copy. Upkeep means upgrading vp and checking vp toolchain after upgrades to confirm the bundled versions still match your overrides.

The second constraint is config consolidation: moving test, lint, fmt and task settings into vite.config.ts is what enables the single-command workflow, but it changes where those settings live. CI also needs the official action rather than the old v1 tag, which no longer receives updates. For organizations, custom template catalogs require publishing an @org/create package with a manifest, which is extra setup.

HotRepo's take

HotRepo has no daily-board history for this project; its only recorded signal is a monthly Rust board position of #16 with +675 stars on 2026-10-27. One dated observation is not enough to judge whether interest persists, so the repository's 599-day age says little about long-term maintenance. Before adopting, check the migration guide and confirm that your framework and package manager are covered by the aliasing and override path, since that is where integration friction is most likely to show up.

Project source and documentation