How to Use Vite+ 0.3.1 for a Modern Web Project

Vite+ 0.3.1, released on September 8, 2026, makes one part of web development noticeably simpler: keeping Node.js and your package manager on the versions a project actually expects. The release also changes how Vite+ handles Corepack, so this is a useful point to learn the workflow rather than simply upgrading an existing installation and hoping nothing changes.

This Vite+ tutorial walks through installing the tool, creating a project, pinning its runtime and package-manager versions, and using the same vp commands for development, checking, testing, and production builds.

Why Vite+ changes the usual web setup

A typical Vite project is not just Vite. A developer may have Node.js installed separately, a package manager such as npm or pnpm, a test runner, a linter, a formatter, and a production bundler. Each tool can have its own version and configuration, which becomes especially noticeable when a project is shared between several developers or built in continuous integration.

Vite+ puts those pieces behind a single command-line interface called vp. Its stack combines Vite for development and application builds, Vitest for testing, Oxlint for linting, Oxfmt for formatting, Rolldown for bundling, tsdown for package builds, and Vite Task for running project tasks. The important part is not that these tools have been renamed; it is that Vite+ gives the project one workflow for coordinating them.

The September 8 release, version 0.3.1, pushes that idea further. Its vp env command can manage Node.js and package-manager versions together, while Vite+ replaces the Corepack-based setup with its own managed package-manager commands. That makes environment setup part of the same project workflow instead of another prerequisite you have to remember separately.

Install Vite+ before creating the project

Vite+ is currently in beta, so it is worth treating the version as a real dependency of your development environment rather than assuming every future release will behave identically. The official installer provides the global vp command, while individual projects use the local vite-plus package behind that command.

On macOS or Linux, open a terminal and run:

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

On Windows PowerShell, use:

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

Close and reopen the terminal after installation, then check that the command is available:

vp help

If the command prints its help information, the global part is ready. You do not need to install Vite, Vitest, or the other bundled tools globally just to start using the Vite+ workflow.

Create a project with Vite+

With vp available, the next step is to create a normal Vite-based project. Vite+ supports projects across the Vite ecosystem, so the workflow is not tied to one frontend framework.

Start the project creation flow with:

vp create

Choose the framework and template you want when prompted. If you prefer to initialize the project with Git as part of the process, the current release also supports:

vp create --git

Once the project exists, move into its directory and install the dependencies:

cd my-app
vp install

The useful result is that you can use the same project-level command regardless of whether the project ultimately uses npm, pnpm, Yarn, or Bun. Vite+ handles the package-manager workflow rather than making you remember a different command for every repository.

Pin Node.js and the package manager to the project

This is where Vite+ 0.3.1 is most different from older releases. The new vp env workflow can keep Node.js and package-manager versions under the same tool. A project can therefore declare the versions it expects instead of relying entirely on whatever happens to be installed globally on a developer's machine.

First, initialize the managed environment:

vp env setup

You can inspect the available environment information with:

vp env list

For Node.js, a default version can be selected with a command such as:

vp env default 22.19.0

For a project-specific Node.js version, pin the version explicitly:

vp env pin node@22.19.0

Package managers can be managed in the same way. For example:

vp env default pnpm@10.15.0

Or pin the package-manager version for the current project:

vp env pin pnpm@10.15.0

The exact version you choose should match the requirements of your application and its dependencies. The point of the commands is reproducibility, not choosing one particular Node.js or pnpm release for every project.

Replace the old Corepack setup

If you have used Corepack before, this is the part of the 0.3.1 upgrade that deserves attention. Vite+ now replaces the old Corepack shim and legacy global package-manager installation approach with managed commands of its own.

An older setup might have used:

corepack enable

With Vite+ 0.3.1, the corresponding setup is:

vp env setup

Likewise, a global package-manager installation such as:

vp install -g pnpm@10.15.0

should become a managed default:

vp env default pnpm@10.15.0

This matters most in shell profiles, continuous-integration jobs, and Dockerfiles. If an existing project still contains Corepack setup commands, do not blindly delete them; replace the environment setup deliberately and test the project's installation and build process afterward.

Run development, checks, and tests through one CLI

Once the project is installed, the everyday workflow becomes straightforward. Start the development server with:

vp dev

That runs the Vite development server and its fast hot-module replacement workflow. When you save source files, the browser can update without rebuilding the entire application.

Before committing changes, use:

vp check

The check command brings formatting, linting, and type-checking into one step. This is useful because the developer no longer needs to remember a sequence such as running a formatter, then a linter, then a separate type-check command.

Tests run through the bundled Vitest setup:

vp test

And the production build is:

vp build

These commands are more than aliases for convenience. Vite+ is designed to keep the versions of the tools it bundles aligned, reducing one class of problems where a project uses one copy of a tool locally and another copy somewhere else in the dependency tree.

Check what Vite+ is actually using

When debugging a build, knowing the tool versions matters. Vite+ provides a command for inspecting its bundled toolchain:

vp toolchain

The current 0.3.1 release bundles Vite 8.2.2, Rolldown 1.2.7, tsdown 0.23.0, Vitest 4.1.11, Oxlint 1.81.0, and Oxfmt 0.66.0. Those versions are useful when reproducing a problem because a report that simply says “Vite failed” is much less precise than one that identifies the actual toolchain.

Vite+ also provides JSON output for environment inspection. For automation that reads the result, note that vp env current --json now separates Node.js and package-manager information, while the list commands expose package managers as their own group. Scripts that depended on the older JSON shape need to be updated rather than assuming the old fields are still present.

Migrate an existing Vite project carefully

You do not have to start a new application to try Vite+. An existing Vite project can be migrated with:

vp migrate

The migration command can update supported configuration and project scripts, but it should not be treated as a guarantee that every custom setup will translate perfectly. The current release specifically includes fixes for stale Vitest aliases and can repair configurations that previously prevented the Vite+ command from starting.

After migration, inspect the changes before committing them. Then install dependencies and run the full development and production workflow:

vp install
vp check
vp test
vp build

If the project publishes packages rather than only building a web application, pay particular attention to vp pack. Version 0.3.1 moved that workflow to tsdown 0.23, which includes configuration changes from earlier versions. A migration can handle supported static configurations, but dynamic configuration may still require manual edits.

Use the same workflow in CI

A local workflow only solves half the consistency problem if continuous integration uses a different environment. Vite+ provides an official setup action for GitHub Actions, allowing CI to install the toolchain and use the same vp commands as a developer's machine.

A minimal workflow step looks like this:

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

Pin the setup action to a specific supported version or commit rather than relying on a floating tag. Once Vite+ is installed, the actual project steps can stay simple:

- run: vp install
- run: vp check
- run: vp test
- run: vp build

That is the practical advantage of the unified approach: local development and CI can speak the same command language. It does not remove the need to understand your project's dependencies, but it reduces the number of separate environment-management decisions you have to reproduce.

Know where Vite+ still needs caution

Vite+ is in beta, even though its maintainers describe the beta as stable enough for production adoption. That distinction matters. The tool is usable today, but the road to 1.0 is not finished, so teams with highly customized build systems should test migration in a branch before changing their main development environment.

The strongest reason to try Vite+ is not that it replaces several familiar tools with a fashionable new command. It is that runtime versions, package-manager versions, frontend tooling, checks, tests, and builds can be treated as one development system. Version 0.3.1 makes that especially visible by bringing Node.js and package-manager management into vp env.

For a new Vite application, the sensible test is small: install Vite+, create one project, pin its environment, run vp check, vp test, and vp build, then repeat the build in CI. If those steps fit your project without special cases, Vite+ has earned a place in the workflow. If they expose assumptions your current setup depends on, that information is useful too — it tells you exactly what needs to be solved before a wider migration.