DEV Community

Cover image for Vite+ — Chapter 1: Why Do We Need Another JavaScript Tool?
Othmane Nemli
Othmane Nemli

Posted on

Vite+ — Chapter 1: Why Do We Need Another JavaScript Tool?

#viteplus #javascript #frontend #webdev

If you've worked with modern JavaScript projects, you've probably seen a package.json that looks something like this:

{
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "test": "vitest",
    "lint": "oxlint",
    "format": "oxfmt",
    "typecheck": "tsc --noEmit"
  }
}
Enter fullscreen mode Exit fullscreen mode

At first, this doesn't look complicated.

You have a command for development, one for building, one for testing, and a few for keeping the code clean.

But there's something hiding behind these commands.

Your project is now depending on several different tools, configurations, versions, and conventions.

And that's the problem Vite+ is trying to address.

The JavaScript toolchain keeps growing

Let's say you're starting a new TypeScript application.

You might begin with:

TypeScript
Vite
Enter fullscreen mode Exit fullscreen mode

Then you want tests:

TypeScript
Vite
Vitest
Enter fullscreen mode Exit fullscreen mode

You add linting:

TypeScript
Vite
Vitest
Oxlint
Enter fullscreen mode Exit fullscreen mode

Then formatting:

TypeScript
Vite
Vitest
Oxlint
Oxfmt
Enter fullscreen mode Exit fullscreen mode

Then perhaps you have a monorepo:

apps/
  web/
  admin/

packages/
  ui/
  utils/
Enter fullscreen mode Exit fullscreen mode

Now you also need to think about:

  • How should packages depend on each other?
  • Which tasks need to run first?
  • Can some tasks run in parallel?
  • Can completed tasks be cached?
  • What should CI run?
  • Which Node.js version should everyone use?
  • Which package manager should the repository use?

None of these problems are particularly new.

But together, they create something we don't always talk about:

toolchain complexity.

The tools aren't the problem

This is important.

Vite isn't the problem.

Vitest isn't the problem.

Oxlint isn't the problem.

Your package manager isn't the problem.

In fact, these tools exist because they solve real problems.

The issue is that we have to connect them ourselves.

Think about a typical development workflow:

Development
    ↓
Vite

Testing
    ↓
Vitest

Linting
    ↓
Oxlint

Formatting
    ↓
Oxfmt

Building
    ↓
Vite / Rolldown

Library packaging
    ↓
tsdown

Tasks
    ↓
Task runner

Runtime + packages
    ↓
Node + npm/pnpm/Yarn/Bun
Enter fullscreen mode Exit fullscreen mode

Each piece makes sense on its own.

But someone has to make the whole thing work together.

That "someone" is usually the development team.

What happens when the project grows?

Imagine a small team with five developers.

The project is simple.

Everyone knows:

npm run dev
npm run test
npm run lint
Enter fullscreen mode Exit fullscreen mode

No big deal.

Now the team grows.

The project becomes a monorepo.

You have multiple applications and shared packages:

my-company/
├── apps/
│   ├── web/
│   └── admin/
│
└── packages/
    ├── ui/
    ├── auth/
    └── utils/
Enter fullscreen mode Exit fullscreen mode

Now running everything becomes more complicated.

Maybe web depends on ui.

ui
 ↓
web
Enter fullscreen mode Exit fullscreen mode

If ui changes, web may need to be rebuilt.

But if auth didn't change, why should everything related to auth run again?

Now you're thinking about:

task dependencies
caching
parallel execution
CI performance
Enter fullscreen mode Exit fullscreen mode

This is where the development toolchain starts becoming a project of its own.

And then there's CI

Your local machine might run:

npm run test
npm run lint
npm run build
Enter fullscreen mode Exit fullscreen mode

But your CI pipeline needs to do the same thing.

So now you have another layer of configuration.

Your repository might contain:

package.json
vite.config.ts
vitest.config.ts
eslint.config.js
prettier.config.js
.github/workflows/...
Enter fullscreen mode Exit fullscreen mode

Again, this is perfectly normal.

But every additional configuration file is another thing developers need to understand and maintain.

And sometimes your local environment and CI don't behave exactly the same.

Maybe:

Local:
Node 22

CI:
Node 20
Enter fullscreen mode Exit fullscreen mode

Or perhaps developers use pnpm while another repository uses npm.

The tools themselves aren't necessarily difficult.

The integration is.

So, what is Vite+?

This is where Vite+ comes in.

Vite+ is designed as a unified toolchain for web development.

Instead of assembling your development environment piece by piece, Vite+ brings several tools together behind a single vp command.

For example:

vp dev
Enter fullscreen mode Exit fullscreen mode

starts development.

vp test
Enter fullscreen mode Exit fullscreen mode

runs tests.

vp check
Enter fullscreen mode Exit fullscreen mode

runs formatting, linting, and type checking.

vp build
Enter fullscreen mode Exit fullscreen mode

builds the project.

And:

vp run
Enter fullscreen mode Exit fullscreen mode

handles project tasks, including dependency-aware execution and caching.

The goal is not simply to give you shorter commands.

The bigger idea is:

Give developers one consistent workflow for the things they do every day.

Is Vite+ just a new Vite?

No.

This is probably the most important thing to understand before continuing.

Vite and Vite+ are different things.

Vite is primarily a development server and build tool.

Vite+ is a broader toolchain that brings together several technologies, including:

Vite
Vitest
Rolldown
tsdown
Oxlint
Oxfmt
Vite Task
Enter fullscreen mode Exit fullscreen mode

It also manages runtime and package-manager workflows.

You can think about it like this:

Vite
  ↓
Development + application build


Vite+
  ↓
Development
Testing
Linting
Formatting
Building
Library packaging
Task execution
Caching
Runtime/package management
Enter fullscreen mode Exit fullscreen mode

So Vite+ isn't replacing Vite.

It is building a larger workflow around it.

Why not just keep using separate tools?

That's a completely reasonable question.

And honestly, you might not need Vite+.

If your project is small, stable, and your team is happy with its current setup, there may be little reason to change it.

The interesting question is what happens when you have to maintain this setup across many projects.

Imagine having:

Project A
  Vite
  Vitest
  ESLint
  Prettier

Project B
  Vite
  Jest
  ESLint
  Prettier

Project C
  Vite
  Vitest
  Oxlint
  Oxfmt
  Turborepo
Enter fullscreen mode Exit fullscreen mode

Now developers need to remember different commands and different conventions depending on the repository.

Vite+ is trying to reduce that variation.

Its documentation describes the goal as avoiding the need for developers to repeatedly assemble their toolchain by hand and giving teams a more consistent setup across projects.

A simple mental model

Here's the easiest way I currently think about Vite+:

Without Vite+:

        You
         |
   ----------------
   |   |   |   |  |
  Vite Vitest Lint Format ...
   |   |   |   |
   -----------+----
              |
         Your scripts
Enter fullscreen mode Exit fullscreen mode

With Vite+:

        You
         |
       vp
         |
   -----------------
   |   |   |   |   |
 Vite Test Lint Format
         |
      Tasks
Enter fullscreen mode Exit fullscreen mode

The tools are still there.

The difference is who is responsible for connecting them.

Why does this matter to a developer?

Because developers should ideally spend their time solving product problems, not repeatedly solving tooling problems.

You don't want your morning to start with:

"Why is the formatter using a different version on CI?"

Or:

"Which command do I need to run before opening a PR?"

Or:

"Why did this package rebuild when nothing changed?"

Or:

"How do I set up this repository on a new machine?"

These are small problems.

But small problems repeated across dozens of developers and hundreds of builds become expensive.

Vite+ is trying to make these workflows more predictable.

What does Vite+ actually change?

The easiest way to understand the difference is through commands.

A Vite+ project can have a workflow like:

vp dev
Enter fullscreen mode Exit fullscreen mode

Develop

vp check
Enter fullscreen mode Exit fullscreen mode

Check the code

vp test
Enter fullscreen mode Exit fullscreen mode

Run tests

vp build
Enter fullscreen mode Exit fullscreen mode

Build for production

vp run
Enter fullscreen mode Exit fullscreen mode

Run project tasks

vp pack
Enter fullscreen mode Exit fullscreen mode

Package a library

These commands are backed by different tools, but they share a common interface.

That consistency is the real feature.

But isn't this just hiding the complexity?

To some extent, yes.

And that's not necessarily a bad thing.

Think about Git.

You can use:

git commit
Enter fullscreen mode Exit fullscreen mode

without understanding every internal detail of Git's object database.

Or you can use Docker without understanding every detail of Linux namespaces.

Good developer tools often provide a simple interface while allowing you to go deeper when necessary.

Vite+ follows a similar idea.

A junior developer can start with:

vp dev
vp test
vp check
Enter fullscreen mode Exit fullscreen mode

while a senior developer can investigate what is actually happening underneath.

And that's exactly what the next articles in this series will do.

The bigger idea

The interesting thing about Vite+ isn't the vp command itself.

It's the philosophy behind it.

Modern web development has become incredibly powerful, but also increasingly fragmented.

We have excellent tools for almost everything:

Development → Vite
Testing → Vitest
Bundling → Rolldown
Libraries → tsdown
Linting → Oxlint
Formatting → Oxfmt
Tasks → Vite Task
Enter fullscreen mode Exit fullscreen mode

The challenge is making all of these tools behave like one development workflow.

That's what Vite+ is attempting to provide.

The official announcement describes it as a single entry point to web development, combining these tools into one tested stack while remaining compatible with the broader Vite ecosystem.

One important detail: Vite+ is still evolving

At the time of writing, Vite+ is in beta.

The project describes it as stable but not yet complete, with additional work planned toward 1.0, including remote caching, broader framework/plugin compatibility, more migration targets, and improvements to documentation and diagnostics.

So this series isn't about saying:

"Everyone should replace their current setup with Vite+."

Instead, the goal is to understand what it is, what problem it solves, and where it makes sense.

Once you understand that, you can decide whether it is useful for your project.

What's next?

Now that we understand why Vite+ exists, let's open the toolbox.

In the next chapter, we'll look at the individual pieces:

Vite
Vitest
Rolldown
tsdown
Oxlint
Oxfmt
Vite Task
Enter fullscreen mode Exit fullscreen mode

What does each one do?

Why do we need it?

And how does it fit into Vite+?

That's where things start getting more interesting.

Next chapter: Vite+ From the Inside — Understanding the Tools Behind vp

Top comments (0)