Getting Started with Vite+

Vite+ is a unified developer toolchain from VoidZero — the company founded by Evan You, creator of Vite and Vue — that combines Vite, Vitest, Rolldown, Oxlint, Oxfmt, tsdown, and Vite Task behind a single CLI named vp. It was announced as an alpha release on March 13, 2026; the alpha tag was dropped with v0.1.21 on May 13, 2026, and the current release at the time of writing is v0.1.23 (May 29, 2026). The project remains pre-1.0, so treat it as early-stage software rather than a production-proven stack — but it is no longer alpha, and the core getting-started workflow is stable enough to use on real projects.

This guide walks through installing Vite+, scaffolding a project, running the dev server, executing checks and tests, producing a production build, and understanding how vp fits into a typical frontend workflow.

What Vite+ actually is

Vite+ is a CLI distribution that bundles a curated set of frontend tools behind a single entry point. Each component is an existing project, not a new invention: Vite 8 as the dev server, Rolldown as the Rust-based production bundler that is API-compatible with Rollup, Vitest as the test runner, Oxlint and Oxfmt as the linter and formatter built on the Oxc compiler infrastructure, tsdown for library bundling, and Vite Task for monorepo task orchestration and caching.

The performance gains across these tools are structural, not additive: Rolldown, Oxlint, and Oxfmt share Oxc — VoidZero’s Rust-based JavaScript compiler infrastructure — as a common parsing and transformation layer. The speed improvement comes from the underlying engine being fast once rather than each tool being independently optimized.

Vite+ complements Vite rather than replacing it. If you already use Vite, you can adopt Vite+ incrementally; if you don’t, Vite+ is not the entry point you want.

Prerequisites

Before installing, confirm your environment meets Vite 8’s runtime requirements. Vite 8 requires Node.js 20.19 or later, or Node.js 22.12 or later — Vite+ does not replace Node.js, it manages which Node.js version your project uses through vp env. Running Vite+ on an older Node.js will error before the dev server starts.

You also need a POSIX-compatible shell on macOS or Linux, or PowerShell on Windows.

Installing Vite+

Vite+ installs as a single binary called vp. On macOS or Linux:

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

On Windows PowerShell:

irm https://vite.plus/ps1 | iex

Restart your terminal, then verify the install:

vp --version
vp help

During install, Vite+ asks whether it should manage your global Node.js runtime. If you already use nvm, fnm, or asdf, you can decline managed mode and Vite+ will defer to your system Node.js. You can toggle this later with vp env on or vp env off.

Creating your first project

vp create scaffolds a new project from a Vite+ template, prompting interactively for framework, package manager, and TypeScript or JavaScript:

vp create

The interactive prompt lets you pick a template (Vite, Vue, Svelte, Nuxt, Next.js, React Router, or TanStack Start), a package manager (npm, pnpm, yarn, bun), and TypeScript or JavaScript. To skip the prompt, pass a template name:

vp create vue my-app
cd my-app
vp install

The scaffold produces a single vite.config.ts that will hold configuration for every tool in the chain — the linter, formatter, test runner, and staged-file hooks all read from this file.

Running the dev server with vp dev

vp dev boots the Vite 8 development server with default settings — no flags required for the common case:

vp dev

vp dev starts the Vite 8 development server directly. It does not execute the dev script from your package.json — that is a common point of confusion, and it is the inverse of how npm run dev behaves. If your project has a custom dev script (for example, one that runs a backend process concurrently with the frontend), invoke it explicitly:

vp run dev

The same rule applies to vp test and vp build: these are built-in commands that route through Vite+‘s integrated tools. vp run <script> is the escape hatch for arbitrary package.json scripts, and it also gains Vite Task’s input-aware caching when invoked with --cache.

The unified vite.config.ts

Vite+ collapses configuration for every tool it wraps — Vite, Vitest, Oxlint, Oxfmt, and staged-file hooks — into a single vite.config.ts at the project root. Instead of maintaining separate .eslintrc, .prettierrc, and vitest.config.ts files, you express everything through one typed defineConfig call.

A minimal configuration looks like this:

import { defineConfig } from 'vite-plus'

export default defineConfig({})

You can then add configuration for individual tools as your project grows:

import { defineConfig } from 'vite-plus'

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

Vite+ also supports staged-file checks through a staged configuration block:

import { defineConfig } from 'vite-plus'

export default defineConfig({
  fmt: { singleQuote: true, semi: false },
  lint: { ignorePatterns: ['dist/**'] },
  test: { include: ['src/**/*.test.ts'] },
  staged: {
    '*.{js,ts,tsx,vue,svelte}': 'vp check --fix',
  },
})

To enable commit-time checks, install the Git hooks:

vp config

After that, Vite+ automatically runs the configured staged-file tasks during commits via vp staged, without requiring separate Husky or lint-staged configuration.

As with the rest of Vite+, the configuration system is still evolving while the project remains pre-1.0. If you’re adopting new releases, it’s worth checking the official documentation and release notes for configuration changes before upgrading.

Running checks with vp check

vp check runs formatting, linting, and type-aware checks in one pass against the current project:

vp check

To auto-fix what can be fixed safely:

vp check --fix

--fix handles most formatting and many lint rules but cannot repair type errors or logic bugs. Treat it as an autofixer, not a substitute for review. The type checks are performed by tsgolint (a type-aware linter built on the TypeScript Go toolchain), not by a full tsc --noEmit compile — fast for catching common type errors, but not a substitute for tsc in CI if you require exhaustive type compilation. Because Oxlint, Oxfmt, and tsgolint share Oxc-aligned infrastructure, vp check runs noticeably faster than a comparable ESLint + Prettier + tsc --noEmit chain on the same codebase.

Running tests with vp test

vp test runs the Vitest suite a single time and exits — Vite+ inverts Vitest’s native default of staying in watch mode, so watch behavior is opt-in:

vp test                  # run once (Vite+ does not watch by default, unlike Vitest)
vp test watch            # enter watch mode
vp test run --coverage   # one-shot run with coverage

vp test invokes Vitest using the test block in vite.config.ts. Note that this inverts Vitest’s native default — running vp test alone exits after a single pass, where standalone vitest would stay in watch mode. Because Vitest already shares Vite’s transform pipeline, there is no separate vitest.config.ts to maintain — the same defineConfig covers both.

Producing a production build with vp build

vp build compiles a production bundle using Vite 8 and Rolldown, emitting to dist/ with the same conventions as vite build:

vp build

vp build compiles a production bundle using Vite 8 and Rolldown. Output goes to dist/ following the same conventions as vite build. Because Rolldown is designed to be API-compatible with Rollup, existing Rollup plugins are intended to continue working — though plugin authors are still landing fixes for edge cases, so verify any custom plugins on a branch before relying on vp build for releases.

To cache build inputs across runs in a monorepo:

vp run --cache build

Vite Task fingerprints the declared inputs and skips packages whose inputs are unchanged on subsequent runs. This is the same workflow concern Turborepo addresses, integrated into the toolchain rather than added on top.

A common production failure mode when switching bundlers is silent source map regression. Before deploying a vp build output, verify that stack traces in your error monitoring or session-replay tooling still resolve to original source files — this is one of the most frequent build-tool migration issues OpenReplay sees surface in real-world session data.

vp command reference

Reference current as of Vite+ v0.1.23 (May 29, 2026).

Wiring Vite+ into GitHub Actions

For CI, VoidZero publishes the voidzero-dev/setup-vp action, which installs the vp CLI and optionally caches dependencies. A minimal workflow:

name: CI
on: [push, pull_request]
jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: voidzero-dev/setup-vp@v1
        with:
          node-version: '22'
          cache: true
      - run: vp install
      - run: vp check
      - run: vp test
      - run: vp build

This replaces separate lint, format, type-check, and build steps with four vp invocations that read from the same vite.config.ts your developers use locally.

What to know before adopting

A few honest caveats for the current release:

• Oxfmt is still pre-1.0. Compare its output against your existing Prettier baseline on a branch before switching production codebases.
• Framework ecosystems still have their own conventions. While Vite+ can scaffold projects for frameworks such as Nuxt and TanStack Start, framework-specific configuration and workflows may continue to live outside Vite+‘s unified configuration model.
• Pre-1.0 means breaking changes are possible. Pin the vp version in CI and read the Vite+ changelog before upgrading.

Where to go next

Install Vite+ on a side project this week, run vp check once, and notice what your toolchain feels like when six tools answer to one command. If that experience holds up, try vp migrate on a non-critical Vite project and review the diff before merging — the migration is fast, but the review is where you catch the edge cases.

FAQs

Gain Debugging Superpowers

Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers. Check our GitHub repo and join the thousands of developers in our community.