Vite+: Achieving 7.7x Faster Builds — Why You Should Wait Before Adopting It

Introduction

Vite+ is an "integrated toolchain" that consolidates the essential tools required for Web development into one.

This article is written for engineers who have used Vite before or are interested in frontend build tools. I assume the reader is at an intermediate level or higher, with experience in setting up development environments by combining individual tools like ESLint, Prettier, and Vitest.

I will provide the information necessary to judge "whether you should adopt Vite+," balancing the benefits with the drawbacks and precautions. While the massive performance improvements offered by Rust-based tools are compelling, the risks associated with the alpha stage cannot be ignored. By the end of this article, my goal is for you to be able to make an informed decision about its adoption in your own projects.

What is Vite+?

In conclusion, Vite+ is a "JavaScript/TypeScript integrated toolchain centered around Vite" developed by VoidZero Inc.

Why was Vite+ born?

In modern JavaScript development, the fragmentation of tools has become a serious issue.

A development server (Vite), testing (Jest), linting (ESLint), formatting (Prettier), type checking (tsc)—the effort to select these tools for each project, write configuration files, and manage version compatibility is overhead unrelated to actual application development.

Vite+ is a project that aims to solve this "tool fragmentation problem" head-on.

The relationship between VoidZero Inc. and Vite

Vite+ is being developed by VoidZero Inc., founded by Evan You, the creator of Vite. In October 2025, the company raised $12.5M in Series A funding, with Accel leading the round.

An important point is that Vite+ is a superset of Vite. It can be dropped into existing Vite projects, and existing Vite configurations and plugins will work as is. Since Vite itself continues as an independent project under the MIT license, you can continue to use Vite even if you do not adopt Vite+.

The evolution of the license

The licensing of Vite+ has had a winding path.

When announced at ViteConf in October 2025, it was presented as "source-available," with plans for enterprise-oriented paid plans. However, following criticism from the community that "source-available is not open source," it transitioned to a full MIT license with the alpha release in March 2026.

Evan You commented, "I'm tired of debating which features should be paid," and "the mission of improving developer productivity for JavaScript developers can only be achieved when Vite+ is truly free and open source."

Fig: Vite+ Integrated Toolchain Architecture

Tools Integrated into Vite+

Vite+ integrates six tools into a single CLI. Each plays a role in replacing traditional individual tools.

Fig: Traditional Tools vs. Vite+ Integrated Tools Table

Vite + Rolldown (Dev Server & Bundler)

From Vite 8, the production bundler has been consolidated from the dual architecture of esbuild + Rollup into the Rust-based Rolldown. Because Rolldown provides a Rollup-compatible API, most existing Rollup plugins will work as is.

By using the same bundler for both the development server and production builds, the issue where "it works in the dev environment but breaks when built" is fundamentally resolved.

Vitest (Test Runner)

This is a test runner that provides a Jest-compatible API. Since it can share Vite's configuration as is, no separate configuration for testing is required. It also supports browser mode, sharding (parallel execution), and visual regression testing.

Oxlint (Linter)

A Rust-based linter equipped with over 600 ESLint-compatible rules. An alpha version of the JavaScript plugin system was released on March 11, 2026, making it possible to run existing ESLint plugins without modification.

Compatibility is steadily improving, with a 100% test pass rate for ESLint built-in rules and the React hooks plugin. However, the 600+ rules cover ESLint built-in rules and major plugins, and do not cover every single ESLint plugin. I will touch on the compatibility of custom plugins in the drawbacks section.

Oxfmt (Formatter)

This is a Rust-based formatter. It aims for compatibility with Prettier and has achieved a 100% pass rate in Prettier compliance tests for JavaScript/TypeScript (as of February 2026). However, this is compatibility with the formatting rules of the Prettier core, and a small number of formatting differences remain outside the test suite. Additionally, Prettier plugins are not supported. Furthermore, there are setting differences, such as the default printWidth being 100 compared to Prettier's 80 (I will explain this in detail in the drawbacks section).

It also features built-in support for import sorting and Tailwind CSS class sorting, which are not present in Prettier (though both are disabled by default and must be enabled in settings).

tsdown (Library Bundler)

A bundler intended for library authors. It is based on Rolldown and supports high-speed DTS (declaration file) generation. It is positioned as a replacement for tsup or tsc.

Vite Task (Task Runner)

A task runner for monorepos. It features automatic input inference, dependency awareness, and caching, and can be used as a replacement for Turborepo.

These six tools can be operated from a unified CLI. In the next chapter, we will look at their command architecture.

Vite+ Command Architecture

The Vite+ CLI is unified under the vp command. Tasks that were previously executed individually across multiple tools can now be managed with a consistent interface.

Figure: Before/After — Integration of development tool execution commands

Main Command List

Command	Role	Traditional Equivalent
vp create	Project creation (app, package, monorepo)	npm create vite
vp install	Install dependencies	npm install
vp dev	Start development server	npx vite
vp check	Run lint + format + type check together	eslint && prettier && tsc
vp test	Run tests	npx vitest
vp build	Production build	npx vite build
vp run	Run custom scripts/tasks	npm run
vp pack	Packaging	npm pack
vp env	Display environment info	—

Notable Mention: vp check

vp check does not simply run lint, format, and type checking in sequence. It uses a mechanism called unified path to execute these three processes in parallel and with optimization. It runs twice as fast as executing them individually.

Unified Configuration File

In traditional projects, multiple configuration files such as eslint.config.js, prettier.config.js, vitest.config.ts, and vite.config.ts were required. In Vite+, these are unified into a single vite.config.ts file.

// vite.config.ts
import { defineConfig } from 'vite-plus'

export default defineConfig({
  // Build settings (traditional vite.config.ts)
  build: {
    target: 'es2022',
  },
  // Lint settings (traditional eslint.config.js)
  lint: {
    rules: {
      'no-console': 'warn',
    },
  },
  // Format settings (traditional prettier.config.js)
  fmt: {
    singleQuote: true,
    tabWidth: 2,
  },
  // Test settings (traditional vitest.config.ts)
  test: {
    environment: 'jsdom',
  },
})

We have now reviewed the architecture and command system of Vite+. Next, I will organize the specific benefits provided by this integration.

Benefits — Why Adopt Vite+

Significant Performance Gains

The biggest advantage of Vite+ is the overwhelming performance improvement driven by its Rust-based toolchain.

Looking at production-grade results, the impact is clear:

• Linear: Build time reduced from 46s to 6s (approx. 7.7x faster)
• Ramp: Build time reduced by 57%
• Mercedes-Benz.io: Up to 38% faster
• Beehiiv: Build time reduced by 64%

The speed improvements in linting and formatting are even more remarkable. Oxlint operates 50–100x faster than ESLint in large projects, while Oxfmt operates over 30x faster than Prettier (up to 36x faster depending on conditions).

Figure: Vite+ Performance Benchmark Comparison

Simplification of Configuration

As introduced in the previous chapter, multiple configuration files are consolidated into vite.config.ts. Centralizing configuration also structurally resolves contradictions between tools (such as rule conflicts between ESLint and Prettier).

Improved Developer Experience (DX)

Since all operations can be performed with a consistent CLI called vp, you no longer need to spend time looking up "what the command was for this tool." You are also freed from managing dependencies and version compatibility between tools.

Compatibility with the Ecosystem

Vite+ supports major frameworks such as React, Vue, Svelte, TanStack Start, and SvelteKit. Over 1,200 plugins are registered in the Vite plugin registry, and many of them work as-is.

Ease of Migration

You can start migrating from existing Vite projects with the vp migrate command. Due to its design as a superset of Vite, there is no need to make major changes to your existing configurations.

Disadvantages and Considerations — What You Need to Know Before Adopting

While the benefits may seem attractive, Vite+ comes with several significant risks and constraints. In this chapter, I will provide a frank explanation from eight perspectives. This is the most critical chapter for those considering a production rollout.

First, here is an overview of the eight points of caution:

1. Alpha-stage maturity — v0.1.x, potential for breaking changes
2. Oxfmt beta status — No Prettier plugin support, configuration discrepancies
3. Lock-in concerns — Difficulty in replacing individual tools due to tight integration
4. Learning curve — Adaptation to the new CLI and rule system
5. ESLint plugin compatibility limits — Approx. 80% coverage; the remaining 20% requires adjustment
6. Rolldown compatibility issues — Three major challenges surrounding CJS, manualChunks, and esbuild
7. Community concerns and credibility — Opaque monetization, "JavaScript fatigue"
8. Lack of large-scale project track record — Unproven as a unified toolchain

I will go into detail on each below.

1. Alpha-Stage Maturity

This is the most important point of caution.

Vite+ just released its alpha version (v0.1.11) on March 13, 2026. "Alpha" means a stage where "basic features work, but APIs and specifications are subject to significant changes."

Specific risks include:

• Frequency of breaking changes: We are at the v0.1.x stage, and the road to a stable version (v1.0) is still long.
• Residual bugs: Despite 62 releases, there is a possibility that issues remain in edge cases.
• Incomplete documentation: The GitHub README does not clearly state known limitations or warnings.

The official team also recommends pinning to an exact version when using pre-releases. Using a caret designation like ^0.1.11 in package.json carries the risk of receiving unintended breaking changes.

2. Oxfmt Beta Status

Oxfmt, which is integrated into Vite+, is in the beta stage. Although it achieves 100% pass rates in Prettier compatibility tests for JavaScript/TypeScript, a small number of formatting differences remain outside the test suite. In addition, there are several points to keep in mind:

• Prettier plugin support is unavailable: If you depend on the Prettier plugin ecosystem, a direct migration is not possible. However, Tailwind CSS class sorting is provided as a built-in feature.
• Default configuration differences: The default printWidth for Oxfmt is 100, while Prettier's default is 80. A reformatting of the entire codebase may occur during migration.
• Limited supported configuration options: While major options like singleQuote, trailingComma, tabWidth, semi, and printWidth are supported, it does not cover all of Prettier's options.

3. Lock-in Concerns

Integrated toolchains carry the risk of structural lock-in.

By adopting Vite+, your linting, formatting, testing, and building all become dependent on the Vite+ ecosystem. In the future, if you wish to replace only an individual tool (e.g., switching from Oxlint to Biome's linter), it becomes difficult to do so precisely because they are integrated.

There are lessons from the past. Rome (now Biome) also aimed for "Web development tool integration" but struggled due to funding issues and competition from fast alternatives like esbuild (written in Go) and SWC (written in Rust). Ultimately, Rome dissolved and restarted as the community fork, Biome.

In the community, there is a view that "the component tools (Vite, Rolldown, Oxc) are already complete, and the situation differs from Rome." While there is some truth to this, the fact remains that there is an inherent risk of lock-in with an integrated toolchain.

4. Learning Curve

Vite+ prioritizes compatibility with existing tools, but it is not perfectly compatible.

• Oxlint's unique rule system: Some rules have naming conventions different from ESLint rule names. While the @oxlint/migrate tool can automate conversions, manual effort is required for migrating custom rules.
• Setting integration: When integrating multiple configuration files into vite.config.ts, you need to understand how the settings for each tool correspond.
• Learning a new CLI: You must learn a new command structure, such as vp check and vp run. This also entails the cost of informing the entire team.

While it is not a complete "reset" of your knowledge of ESLint/Prettier/Jest, migration does require a certain investment in learning.

5. ESLint Plugin Compatibility Limits

Oxlint's JavaScript plugin system was just released as an alpha version on March 11, 2026. While the pass rate for ESLint built-in rules and React hooks plugins is 100%, not all ESLint plugins work.

Specific limitations include:

• Frontend framework-specific file formats: Support for unique file formats like Svelte, Vue, and Angular is limited (scheduled for later this year).
• Type-aware custom rules: Not currently supported.
• Estimated coverage: About 80% of ESLint users will find it "just works." The remaining 20% will need to adjust custom rules or consider alternative rules.

If your project relies heavily on custom ESLint plugins, verifying compatibility before migration is essential.

6. Rolldown Compatibility Issues

Rolldown was officially adopted in Vite 8, but there are three major compatibility challenges when migrating from existing Vite projects.

Changes to CommonJS Interop: The method for resolving default imports has changed. You can temporarily restore old behavior with legacy.inconsistentCjsInterop: true, but this is a deprecated option. During the beta period, issues have been reported where exports are not correctly exposed for CJS-dependent packages like vue-dompurify-html.

Deprecation of manualChunks: The object format for output.manualChunks is no longer supported, and the function format is also deprecated. You must rewrite these to use the Rolldown codeSplitting option. For projects that fine-tuned bundle size optimization using manualChunks, this change has a significant impact.

Discontinuation of esbuild Transformation: Oxc handles JavaScript transformations instead of esbuild. Support for configuration option mapping (such as esbuild.jsx → oxc.jsx) is provided, but native decorator transformation is not yet supported. You will need a workaround using Babel or SWC plugins.

7. Community Concerns and Credibility

Even after switching to MIT, the community reaction to Vite+ is not entirely positive.

• Fatigue from "another layer": Citing XKCD 927 ("We need to develop one universal standard... (15 standards later)"), there are concerns that Vite+ simply adds a new layer of complexity.
• JavaScript fatigue: The rapid pace of changes in frontend tools—the migration from ESLint 8 to 9, the debate over Prettier settings, and frequent breaking changes—creates a backdrop of exhaustion.
• Opaque monetization strategy: While the MIT license is well-received, questions remain about VoidZero's long-term sustainability. The $12.5M in VC funding is finite, and the success of the commercial product "Void" holds the key. The strategy appears similar to Vercel's "Next.js → Vercel Platform" model, but very few details about Void have been released.

8. Lack of Large-Scale Project Track Record

Because it has not been long since the alpha release, there is no long-term track record of operation in large-scale production as Vite+.

There is a track record for the underlying technology. Vite 8 + Rolldown is used by companies like Linear, Ramp, and Mercedes-Benz.io, and Oxlint is adopted by Midjourney, Preact, and PostHog. However, these are track records for individual tools, not for Vite+ as a unified toolchain.

Whether new issues arising from integration (bugs due to tool interactions, complexity of integrated settings, etc.) will manifest in actual production environments remains unknown.

Known issues on Windows have also been reported. Memory limit errors may occur with Oxlint, and the use of WSL is recommended.

Having covered the disadvantages, let's organize a comparison with traditional tools to clarify Vite+'s positioning.

Comparison with Traditional Vite / Other Tools

To accurately understand Vite+'s positioning, let's organize a comparison with related tools.

Figure: Vite+ vs Other Toolchains Comparison Table

Vite vs Vite+

The relationship between Vite and Vite+ is "subset and superset." Vite is a tool specializing in development servers and building, and it remains an independent project under the MIT license. Vite+ integrates linting, formatting, testing, and task execution in addition to all of Vite's functions.

If you are satisfied with Vite and have no issues with your ESLint/Prettier/Jest configuration, there is no need to switch to Vite+.

Vite+ vs webpack + Individual Tool Groups

In the webpack ecosystem, configuring loaders/plugins, setting up ESLint/Prettier/Jest individually, and managing version compatibility impose a heavy burden. Vite+ solves these all at once, but a direct migration from webpack is not possible. You must first migrate to Vite.

Vite+ vs Turbopack

Turbopack is a Rust-based bundler developed by Vercel and adopted in the Next.js development server. The approach is fundamentally different: Turbopack is specialized in bundling, whereas Vite+ integrates the entire development workflow. They are tools of different scopes rather than direct competitors.

Vite+ vs Biome (formerly Rome)

Biome is a Rust-based linter + formatter and is a mature tool with a stable release (v2.4.x). It uses a proprietary plugin system based on GritQL.

Aspect	Vite+	Biome
Scope	Full-stack (Build to Test to Lint to Format)	Specialized in Lint + Format
Maturity	Alpha (v0.1.x)	Stable (v2.4.x)
Plugins	ESLint-compatible (JS plugin system)	GritQL proprietary path
Bundler	Rolldown integration	Not implemented (future plan)
Test Runner	Vitest integration	None

If you only want to improve linting and formatting, Biome is a more mature and safer choice. If you seek integration that includes bundling, testing, and task execution, Vite+ is a candidate.

For those interested in Vite+, here is how to perform the introduction and migration.

Introduction and Migration Guide

For New Projects

Here are the steps from installing Vite+ to creating a new project.

# Linux/macOS
curl -fsSL https://vite.plus | bash

# Windows (PowerShell)
irm https://viteplus.dev/install.ps1 | iex

After installation, create a project and start the development server.

# Create project (select from app, package, or monorepo)
vp create my-app

# Install dependencies
vp install

# Start development server
vp dev

Migration from Existing Vite Projects

You can start the migration with the vp migrate command.

# Run migration command
vp migrate

This command detects existing configuration files (like .eslintrc and .prettierrc) and assists with integration into vite.config.ts.

Three Major Cautions During Migration

The three compatibility challenges mentioned in the disadvantages chapter are the most likely to cause issues during migration.

1. CommonJS Interop: Imports of CJS-dependent packages may change. You can temporarily handle this with legacy.inconsistentCjsInterop: true.
2. Deprecation of manualChunks: The object format will stop working, and the function format is deprecated. You must rewrite to Rolldown's codeSplitting.
3. esbuild Transformation: Replace esbuild options with oxc options. If you are using native decorators, you will need Babel/SWC plugins.

The mapping for automatic configuration conversion is as follows:

Old Configuration (esbuild)	New Configuration (oxc)
esbuild.jsx	oxc.jsx
esbuild.define	oxc.define
esbuild.jsxImportSource	oxc.jsx.importSource
esbuild.jsxFactory	oxc.jsx.pragma

Recommendation for Phased Migration

We recommend a phased approach rather than a full-scale migration. By confirming operations at each phase, it becomes easier to isolate issues.

Figure: Phased migration flow from existing Vite project to Vite+. Migrate sequentially in three phases: build, lint, and format/test, verifying compatibility at each stage.

What Kind of Projects is it Suitable for?

Recommended Cases

• New projects: You can introduce a unified toolchain from the beginning and prevent configuration file dispersion. Ideal for personal projects or prototypes where the risks of the alpha stage are acceptable.
• Monorepo structure: You can significantly reduce tool management overhead with task execution via Vite Task and unified configurations.
• Concerns about build speed: There is a proven record of production build acceleration using Rolldown, with a 7.7x improvement example at Linear.
• Trouble with bloated configuration files: Integrating multiple configuration files into one directly leads to lower maintenance costs.

Cases Requiring Careful Consideration

• Stability is top priority in production: You must evaluate the risk of deploying alpha-stage tools into production. The release date for a stable version is undecided.
• Deep reliance on custom ESLint plugins: While plugin compatibility for Oxlint is improving, 100% compatibility is not guaranteed. Compatibility verification before migration is mandatory.
• Thinking of direct migration from webpack: Since Vite+ is a superset of Vite, migration to Vite is a prerequisite. Two-stage migration involves significant effort.
• Legacy browser support is required: The default browser target for Vite 8 has been raised (Chrome 111+, Firefox 114+, Safari 16.4+). Additional settings are required if support for older browsers is necessary.

Summary

Vite+ is the most ambitious solution to the real problem of "fragmentation of JavaScript development tools."

The massive performance improvements (build up to 7.7x, lint up to 100x, format 30x faster) from Rust-based tools and the improved DX through centralized configuration address major pain points in frontend development directly. The fact that it is provided as a fully MIT open-source project is also commendable.

However, production adoption is premature at this point. There are several unavoidable risks, such as instability due to the alpha stage, limits in ESLint plugin compatibility, compatibility issues with Rolldown, and the opacity of VoidZero's monetization strategy.

As a realistic action plan, I recommend the following:

1. Immediately: Try Vite+ in a personal or side project to get a feel for how the tools work.
2. Observe: Keep track of the stable release of Oxfmt, progress in ESLint plugin compatibility, and the resolution of edge cases in Rolldown.
3. Do not rush the decision: It is wise to wait until at least the beta version, and preferably the stable release, for production deployment.

You can check the latest information on Vite+ on the official website or the GitHub repository.

Tool fragmentation in JavaScript development is a challenge felt by many engineers. I look forward to watching the process of Vite+ maturing as a solution with cautious optimism.