Vite+ — Chapter 3: Vite+ in Practice

In the previous chapter, we looked at what Vite+ is made of.

We saw that Vite+ brings together tools such as:

• Vite
• Vitest
• Rolldown
• tsdown
• Oxlint
• Oxfmt
• Vite Task

But knowing what these tools are is only half the story.

The more interesting question is:

What does developing a real project with Vite+ actually look like?

That's what we'll explore in this chapter.

We'll create a project, start the development server, run checks and tests, and finally create a production build.

1. Installing Vite+

Vite+ provides a vp command-line interface.

The official beta installation method is different depending on your operating system.

macOS / Linux

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

Windows

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

After installation, you can check that the command is available:

vp --version

You should now have access to the vp command.

Think of vp as the main doorway into your JavaScript project.

Instead of remembering which tool should handle each part of your workflow, you can use the same command-line interface.

2. Creating a New Project

Let's create our first Vite+ project.

Run:

# Interactive mode
vp create

Vite+ ships with these built-in templates:

vp vite:monorepo #creates a new monorepo
vp vite:application #creates a new application
vp vite:library #creates a new library

For more examples and options

Vite+ will guide you through creating a project from a template.

Once the project has been created, move into it:

cd my-project

The exact project name depends on what you choose during the creation process.

At this point, you have a project that can use the Vite+ workflow.

3. Installing Dependencies

Normally, JavaScript developers might use:

npm/pnpm/yarn/bun install

Vite+ provides its own entry point for this:

vp install # this command will be executed automatically by vp

Vite+ can work with different package managers and can detect the package-manager setup used by the project.

This is one of the ideas behind Vite+:

You don't necessarily need to change the underlying tools. Vite+ provides a consistent interface over them.

So the goal isn't:

"Everyone must stop using npm."

The goal is closer to:

"Developers shouldn't need to care which command is responsible for every individual part of the workflow."

4. Starting the Development Server

Now let's start developing.

Run:

vp dev

Under the hood, this uses Vite's development server.

You'll get the familiar Vite development experience, including fast module updates when you change your source code.

By default the project comes with a counter componenent

apps/website/src
├── counter.ts
├── main.tsx
└── styles.css

Edit main.tsx:
change "Get started" by "Welcome Vite+" and save the file

Your browser updates without requiring you to manually rebuild the whole application.

That's the Vite experience you already know.

Vite+ doesn't try to replace that experience.

It gives you a consistent command for accessing it:vp dev

5. Checking Your Code

Now let's say you've written some code.

Before committing it, you usually want to check:

1. Is the code formatted?
2. Are there lint errors?
3. Are there type errors?

Traditionally, you might have several commands:

npm run format
npm run lint
npm run typecheck

With Vite+, these checks can be combined:

vp check

The current Vite+ workflow combines formatting, linting, and type checking.

So instead of remembering three different commands, your workflow can become:

vp check

That's a small difference for a small project.

But imagine a team with:

• 10 developers
• 20 repositories
• several applications
• shared packages
• CI pipelines
• multiple environments

A consistent command becomes much more useful.

More info vp check

6. Running Tests

Let's say we have a test:

import { describe, expect, it } from 'vitest'

describe('addition', () => {
  it('adds two numbers', () => {
    expect(1 + 2).toBe(3)
  })
})

Normally, you might run Vitest directly:

vitest

With Vite+:

vp test

Vite+ runs the tests through Vitest.

Again, notice the pattern:

Development → vp dev
Checks       → vp check
Tests        → vp test

You don't need to memorize which underlying tool powers each command.

You just learn the Vite+ workflow. more info vp test

7. Building for Production

When your application is ready to deploy, you need a production build.

With Vite+, run:

vp build

The application is built for production using Vite and Rolldown.

The important distinction is:

vp dev
   ↓
Development environment

vp build
   ↓
Production build

During development, you want speed and fast feedback.

During production, you want optimized output that can be deployed.

Vite+ gives you a consistent interface for both.

8. Previewing the Production Build

After building the application, you can preview the result with:

vp preview

This lets you check the production build locally before deploying it.

A simple workflow could therefore look like:

vp dev

Develop your application.

Then:

vp check

Check the code.

Then:

vp test

Run the tests.

Finally:

vp build
vp preview

Build and preview the production version.

9. The Workflow Starts to Look Different

At this point, we can summarize the basic workflow:

This is where the idea behind Vite+ becomes easier to understand.

It isn't about replacing every individual tool.

It's about creating a consistent interface for the development workflow.

10. What About Existing Projects?

You might be thinking:

"This sounds nice, but I already have a project."

That's an important use case.

Vite+ provides:

vp migrate

This is intended to help migrate an existing project to the Vite+ workflow.

For example, imagine an existing project already has:

my-app/
├── package.json
├── vite.config.ts
├── vitest.config.ts
├── eslint.config.js
├── prettier.config.js
└── src/

Instead of creating everything again, you can run:

vp migrate

Vite+ can bring parts of the existing configuration into its unified setup.

The current migration process shows what it plans to change, but complex projects may still require manual follow-up. The official documentation recommends reviewing the migration guide before using it on a production project.

So migration should not be thought of as:

"Run one command and everything magically changes."

It's better to think of it as:

"Vite+ helps you move an existing project toward the unified workflow."

11. One Configuration File

Another interesting part of Vite+ is configuration.

A Vite+ project can use vite.config.ts as the central configuration point.

For example:

import { defineConfig } from 'vite-plus'

export default defineConfig({
  plugins: [],

  test: {
    include: ['src/**/*.test.ts'],
  },

  lint: {
    ignorePatterns: ['dist/**'],
  },

  fmt: {
    semi: true,
    singleQuote: true,
  },
})

Notice what is happening here.

The same configuration can contain settings for different parts of the development workflow:

vite.config.ts
      │
      ├── Vite
      ├── Vitest
      ├── Oxlint
      ├── Oxfmt
      └── Vite Task

The goal is to reduce the number of separate configuration files you need to understand and maintain. The Vite+ repository documents this unified configuration approach.

For me, I prefer to use separate files, for readability and quick access.

12. And Then There's vp run

So far, we've looked at the obvious commands.

But one command becomes especially interesting when a project grows:

vp run

vp run can execute package.json scripts and Vite Task workflows, including dependency-aware task execution and caching.

Imagine a monorepo:

my-company/
├── apps/
│   ├── web/
│   └── admin/
│
└── packages/
    ├── ui/
    ├── utils/
    └── config/

Now imagine:

web
 ↓
ui
 ↓
utils

If utils changes, some tasks need to run again.

But if nothing relevant changed, running everything again wastes time.

This is where task caching becomes useful.

For example:

vp run build

Vite+ can understand task relationships and reuse cached results where appropriate.

That's much more interesting in large repositories than in a tiny demo application.

And that leads directly into the next stage of our series.

Note:

vpr is available as a standalone shorthand for vp run.

13. A Realistic Daily Workflow

After everything we've seen, a developer's day might look something like this:

Start working

vp dev

Make changes

Write your application code.

Check everything

vp check

Run tests

vp test

Build before deployment

vp build

Preview the result

vp preview

The commands are simple.

That's intentional.

The complexity is moved away from remembering dozens of unrelated commands and toward having one consistent toolchain.

14. The Bigger Picture

Let's step back for a moment.

Without a unified workflow, you might have something like:

npm
 │
 ├── Vite
 ├── Vitest
 ├── ESLint
 ├── Prettier
 ├── TypeScript
 ├── task runner
 └── package scripts

With Vite+:

                 Vite+
                   │
       ┌───────────┼───────────┐
       │           │           │
     Build       Test        Check
       │           │           │
     Vite       Vitest     Oxlint/Oxfmt
       │
    Rolldown

The underlying technologies are still there.

What's different is the way you interact with them.

Instead of thinking:

"Which tool handles this?"

you can increasingly think:

"Which vp command handles this?"

That's the central idea of Vite+ in practice.

What's Next?

In Chapter 4, we'll move beyond a single application.

We'll look at Vite+ at scale:

• Monorepos
• Task dependencies
• Caching
• Parallel execution
• CI/CD
• Shared configuration
• Why vp run becomes much more valuable as a repository grows

That's where Vite+ starts solving problems that are difficult to see in a small project.