Vite+ review: one CLI for runtime, package manager and frontend toolchain

The problem Vite+ targets: toolchain sprawl around Vite

A typical Vite project carries a dev server, a test runner, a linter, a formatter, a library bundler and a task runner, each with its own config file and its own release cadence. Vite+ collapses that set into one dependency. The README describes it as "the unified entry point for local web development" and lists what it combines: Vite, Vitest, Oxlint, Oxfmt, Rolldown, tsdown and Vite Task. On top of the frontend tools, it also takes over runtime and package manager workflows.

The audience is narrower than the tagline suggests. This is for teams that have already chosen Vite and now want the surrounding tools to move together, and for monorepos that want dependency-aware task scheduling without adding a separate task runner. It is not a general-purpose build system, and it does not try to support bundlers outside the Vite ecosystem. If your build is Webpack or your tests are Jest, most of the value proposition disappears before you start.

How vp wires runtime, package manager and toolchain together

Vite+ ships as a CLI named vp. Subcommands are grouped in the README: vp env manages Node.js globally and per project, vp install installs dependencies with automatic package manager detection, and the develop group covers vp dev, vp check, vp lint, vp fmt and vp test. The execute group adds vp run for monorepo tasks, vp exec, vp node and vp dlx. The build group adds vp build, vp pack and vp preview.

The package manager story is a wrapper, not a replacement. The README states that Vite+ "automatically wraps your package manager (pnpm, npm, Yarn, or Bun) based on packageManager and lockfiles", and the manage group exposes add, remove, update, dedupe, outdated, list, why, info, link, unlink, rebuild and pm. So your lockfile stays authoritative; vp is a front end over it, and vp pm forwards an arbitrary command through.

Configuration is centralized in one vite.config.ts at the project root. The README's example imports defineConfig from vite-plus and nests test, lint, fmt and run blocks alongside standard Vite config. vp migrate merges tool-specific files such as .oxlintrc*, .oxfmtrc* and lint-staged config into that single file. The repository itself is a Rust workspace (Cargo.toml, crates/, rust-toolchain.toml) with a pnpm workspace on top, so the CLI is a native binary rather than a Node script.

Installing Vite+ and running a first check

The README gives a shell installer for Linux and macOS, and a PowerShell installer for Windows. Both install vp globally.

curl -fsSL https://vite.plus | bash

On Windows the README uses:

irm https://viteplus.dev/install.ps1 | iex

After that, vp create scaffolds a project, and running it inside an existing project adds new apps or libraries rather than starting from scratch. To see which versions you actually got, the README documents vp toolchain, which shows "the versions of Vite+, Vite, Rolldown, Oxc, and other tools". That output matters more than it looks, because the migration instructions below depend on it.

The configuration surface is one file. The README's example:

import { defineConfig } from 'vite-plus';

export default defineConfig({
  plugins: [],
  test: {
    include: ['src/**/*.test.ts'],
  },
  lint: {
    ignorePatterns: ['dist/**'],
  },
  fmt: {
    semi: true,
    singleQuote: true,
  },
});

For CI, the README points at the official setup-vp action and is explicit about the version field: set <setup-vp-version> to an exact version from the releases page or a commit SHA, and do not use the v1 tag, which no longer receives updates.

- uses: voidzero-dev/setup-vp@<setup-vp-version>
  with:
    node-version: '22'
    cache: true

Migration is the part the README warns about

vp migrate is the documented path for existing projects, but the README also documents a manual route with more moving parts. You install vite-plus as a dev dependency with vp install -D vite-plus, then add package-manager overrides. Two details are stated plainly: alias vite to @voidzero-dev/vite-plus-core, and pin vitest to the version printed by vp toolchain vitest.

The reasoning given is that the project and vp test then use the same Vitest copy. The README states that without the pin, "a dependency or works..." (the sentence is truncated in the source). That is enough to know the pin is not cosmetic. If a transitive dependency pulls a second Vitest, vp test and your own test imports can diverge. This is the single most likely source of confusing failures during adoption, and it is a consequence of bundling a test runner rather than resolving it from the registry like any other dependency.

Environment variables have also moved. The v0.2.8 release notes list "breaking VP_* environment variable renames" alongside monorepo target resolution and install fixes. If you are upgrading from an earlier 0.2.x, check your CI environment for VP_-prefixed variables before the upgrade lands, not after. The same release line, v0.2.9, added vp toolchain and vp hooks and fixed vp run inside Codex and Claude Code sandboxes, which tells you agent sandboxes were a real failure mode at that point.

Where Vite+ is the wrong tool

The versioning is the first constraint. The current line is 0.3.0, released 2026-08-24, and the three most recent releases all carry breaking or behavioural changes: XDG install layout and Bun 1.4 support in 0.3.0, new vp toolchain and vp hooks commands in 0.2.9, VP_* renames in 0.2.8. A pre-1.0 tool that renames environment variables and moves its install layout across three consecutive releases is a moving target. If you need a configuration surface that will not shift under you for a year, this is not that.

The second constraint is the install layout change in 0.3.0. Moving to an XDG layout means paths that scripts, container images or CI caches may have hardcoded will change. The README does not document a rollback path for that move, and the release title is the only note on it.

The third is scope. If your project's build is not Vite, or your tests are not Vitest, or your monorepo already has a task runner you are happy with, Vite+ asks you to replace working components to get the ones you want. The vp run caching and dependency-aware scheduling are only interesting if you actually have a monorepo with task dependencies. For a single-package app, vp dev, vp build and vp test are convenience aliases over tools you could install directly.

Vite+ versus running Vite, Vitest and a task runner separately

The honest alternative is not another unified toolchain. It is what most Vite projects do today: install vite, vitest, oxlint and a task runner as separate dev dependencies, each with its own config file, and let your package manager handle version resolution. The difference in approach is who owns the compatibility matrix. Separately, you do: you upgrade Vite, then Vitest, then the linter, and you resolve any mismatch yourself, but you can also hold one of them back while moving the others.

Vite+ inverts that. The bundled tools move together, versions are visible through vp toolchain, and the README's own migration instructions require you to pin vitest to whatever vp toolchain vitest reports so the project and the CLI agree. You gain a tested combination and lose the ability to upgrade one component independently. For a monorepo where task orchestration and caching are the actual pain, that trade is defensible. For a small app where the pain is just remembering four commands, it is a lot of machinery for a shorter command list.

The task-runner comparison is the sharper one. vp run handles package.json scripts and monorepo tasks with caching and dependency-aware scheduling, configured under a run.tasks block in vite.config.ts with per-task command and envs keys. A dedicated task runner does the same job and nothing else. Choosing Vite+ here means accepting that your task graph lives in the same file as your Vite plugins and your formatter settings.

Licence, maintenance and upgrade cost

Vite+ is MIT licensed, and the repository's package.json and Cargo.toml both carry "license": "MIT". MIT is permissive: it allows commercial use, modification and redistribution, and it requires the licence and copyright notice to be preserved. It provides no patent grant and no warranty, which is normal for this licence but worth knowing if your legal team asks. This is a description of the licence text, not legal advice.

On maintenance, the last push to the default branch was on 2026-08-24, and the repository is not archived. The release cadence across early August 2026 is roughly weekly, which is fast for a tool you would put in a build pipeline. The upgrade cost follows from that: each release can carry breaking changes, as 0.2.8 did with the VP_* variable renames and 0.3.0 did with the XDG install layout. Budget for reading release notes before upgrading vp itself, and note that vp upgrade updates the CLI while the bundled tool versions move with it.

The repository carries MAINTENANCE.md, CONTRIBUTING.md, AGENTS.md and CLAUDE.md at the top level, plus rfcs/ and ecosystem-ci/ directories. Those are signals about how the project is run, not guarantees about stability. The README does not document a rollback procedure for a failed vp migrate, which is the gap to plan around: keep the migration in its own commit so reverting is a single git revert.

Editorial conclusion

Adopt Vite+ if your project is already on Vite and you want dev, check, test, build and monorepo task caching driven from one vite.config.ts plus a Node.js version manager you no longer have to install separately. Do not adopt it if you depend on a bundler or test runner outside the Vite ecosystem, if you need a stable configuration surface, or if you cannot accept that vp install wraps your existing package manager rather than replacing it. Before committing, run vp toolchain to see the exact Vite, Rolldown, Oxc and Vitest versions you would inherit, and check whether the vitest pin it prints matches the one your project already resolves to.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes