Vite+ 1.0 was officially released on September 28, 2026.
I had known it was in development for a while and had been looking forward to seeing where it would land. Now that it has reached 1.0, I finally took a closer look.
My first reaction was fairly simple: maybe Vite+ is becoming the thing I should consider first for a new JavaScript project.
I usually work with Astro + Bun + Vite and tend to prefer lightweight setups that do not accumulate too many dependencies or configuration files. In real projects, though, linting, formatting, testing, type checking, CI, and related tooling still add up little by little.
Vite+ is an attempt to bring those pieces back together into one development experience.
One entry point for the tools around Vite
In the Vite+ 1.0 announcement, Vite+ is positioned not as a framework or a replacement for a particular package manager, but as a unified development toolchain that includes Vite itself behind one entry point.
At its core are tools that would normally be installed and configured separately:
- Vite / Rolldown for the dev server and builds
- Vitest for testing
- Oxlint for linting
- Oxfmt for formatting
- tsdown for library builds
- Vite Task for task execution and caching
They are exposed through a single vite-plus package and the vp command.
For example, static checks can be run with:
vp check
That command can run formatting, linting, and type checking together.
According to the vp check documentation, formatting is handled by Oxfmt, linting by Oxlint, and type checking is handled by tsgo from the TypeScript Go toolchain, while tsgolint provides type-aware lint rules.
A setup that might otherwise grow into something like this:
ESLint
Prettier
TypeScript
Vitest
Vite
tool-specific config files
package.json scripts
can instead be treated as one coordinated toolchain.
I like being able to choose tools individually. What becomes tedious is making the same set of choices again every time I start a project.
The interesting part is choosing less
Vite+ is built around a number of fast, Rust-based tools.
The project naturally emphasizes the speed of Oxlint and Oxfmt, but what interests me more is reducing the number of decisions needed to assemble a development environment.
JavaScript tooling has improved a lot.
Vite is fast. Vitest is pleasant to use. Rust-based tools such as Oxlint and Oxfmt are increasingly capable.
At the same time, the list of early project decisions has grown:
"Which linter?"
"Which formatter?"
"What should handle tests?"
"Do I need a task runner?"
"How should Node versions be managed?"
"Which package manager?"
Vite+ reduces that initial decision load by providing a set of tools designed to work together behind one entry point.
That approach fits the way I like to work.
Bun and Vite+ can divide responsibilities
One of the first things I wanted to understand was how Vite+ fits with Bun, which I use regularly.
Bun already bundles a runtime, package manager, test runner, bundler, and more, so there is some conceptual overlap.
If Bun is mainly being used as the package manager, however, there is no need to give it up in order to use Vite+.
The Vite+ package management documentation explicitly supports Bun alongside pnpm, npm, and Yarn. Files such as bun.lock, bun.lockb, and bunfig.toml are also part of package-manager detection.
So a setup like this is perfectly reasonable:
Bun
└─ package manager
Vite+
├─ Vite / Rolldown
├─ Oxlint / Oxfmt
├─ Vitest
└─ Vite Task
A large part of why I use Bun is not that I want to replace Node.js at all costs. I use it because installs are fast, the CLI feels lightweight, and day-to-day operations stay simple.
From that perspective, keeping Bun as the package manager while moving linting, formatting, and related tooling toward Vite+ feels quite natural.
The global Vite+ CLI can also manage Node.js itself, while a project-local vite-plus package can run on top of an existing Node.js runtime and package manager.
That leaves room both for a more fully integrated Vite+ setup and for using it only where it makes sense.
Bun therefore seems easy enough to keep. The more interesting question is Astro, which already uses Vite internally.
With Astro, keep dev and build on the Astro side
Astro already depends heavily on Vite. Astro 7 uses Vite 8 with Rolldown, and Astro configuration can pass through Vite configuration as well.
That can make it look as if Astro could simply be replaced by Vite+ at the command level, but for now it makes more sense to keep dev and build under Astro itself.
The vp run documentation gives a useful example.
If a project has:
{
"scripts": {
"dev": "astro dev"
}
}
then:
vp run dev
runs astro dev.
By contrast:
vp dev
starts the Vite dev server built into Vite+.
For Astro, I would start with a split more like this:
Astro
└─ dev / build
Vite+
├─ check
├─ lint
├─ format
├─ test
└─ task runner
Astro has its own build pipeline, routing, and adapters. The fact that it uses Vite internally does not mean Astro itself can simply be replaced by Vite+.
I later tried Vite+ 1.0 in the actual happas.jp project, which already runs on Astro + Bun, using GitHub Actions.
The environment was Astro 7.3.x with Bun 1.4.2. Vite+ detected bun.lock automatically, and vp install --frozen-lockfile delegated directly to bun install. At least for package management, coexistence with Bun was straightforward.
I then moved the CI entry point over to setup-vp, followed by vp install, vp lint, and vp run check / test / build. The official setup-vp v1.21.1 documentation explains that package-manager management is enabled by default on CI and can manage Bun alongside the other supported package managers. In this project, packageManager: [email protected] resulted in Bun 1.4.2 being provisioned, and vp install delegated to bun install without a separate setup-bun step.
For the Astro CLI itself, the package scripts explicitly use bun run --bun astro ..., so the runtime is forced to Bun rather than merely inferred from the package manager. That makes for a clear division of responsibilities: Vite+ is the orchestration layer, while Bun remains both the package manager and the runtime used by the Astro CLI.
There was an important distinction on the task-runner side. Running vp run check, vp run test, and vp run build on the unmigrated project produced a "This project does not use vite-plus" warning. The actual work was still performed by the existing package.json scripts such as bun run --bun astro check, bun test, and bun run --bun astro build, with Vite Task orchestrating them.
So the fact that vp run works is useful evidence that Vite+ can sit on top of an existing project, but it does not mean the toolchain has already been replaced by Vite+. Wrapping existing scripts and actually moving linting, formatting, testing, and other responsibilities to Vite+ are separate stages.
I also tried the native tools. vp lint processed 60 JavaScript / TypeScript files in 27ms and reported nine warnings. It was indeed very fast, but several warnings came from vendored code, so a real setup would still need sensible exclusions.
vp fmt --check reported formatting differences in 34 of 61 files and printed "No config found, using defaults." Oxfmt is easy to run immediately, but an existing project still has migration work to do if its current formatting style differs from the Vite+ defaults.
For this experiment I left Astro files out of the native lint / format pass and continued to rely on astro check for Astro-specific diagnostics. That makes a gradual migration from the JavaScript / TypeScript side look more realistic than a wholesale replacement.
After trying it, my earlier split:
Astro
└─ dev / build
Vite+
├─ check
├─ lint
├─ format
├─ test
└─ task runner
was a little too neat.
For an existing Astro project, a more realistic starting point looks closer to:
Astro / Bun
├─ dev / build
├─ Astro-specific checks
└─ existing tests
Vite+
├─ vp run for existing scripts
├─ Oxlint
└─ Oxfmt
and then moving responsibilities over only where the migration is actually useful.
I later completed the migration to a project-local vite-plus package and vite.config.ts, then normalized the initial formatting differences. At that point the separate vp lint and vp fmt --check CI steps could be collapsed into vp check. The final split was simpler: Vite+ handles formatting, linting, and TypeScript type checking; Astro-specific diagnostics stay with astro check; and the existing tests stay on Bun.
Vite+
└─ vp check
├─ format
├─ lint
└─ TypeScript check
Astro / project
└─ Astro-specific checks
Bun
└─ tests
I also tested Vite Task caching rather than assuming it would help. Ordinary package.json scripts are not automatically cached through vp run, so I enabled caching explicitly and reran tasks inside the same CI job. bun test did hit the cache, but the saved time was only about 144ms. The heavier astro check did not produce stable hits because GitHub Actions changes environment variables between steps, and reusing task cache across CI runs would require additional persistence. In this project, that extra complexity was not worth the measured benefit, so I left task caching out of the final CI setup.
That experience changed my view slightly: Vite+ is more useful when I adopt the parts that clearly simplify an existing setup, such as vp check, rather than enabling every available feature just because it exists.
Astro and VoidZero are now closer under Cloudflare
Another interesting part of this story is Cloudflare.
The Astro Technology Company joined Cloudflare in January 2026.
VoidZero, the company behind Vite, Vitest, Rolldown, Oxc, and Vite+, then joined Cloudflare in June 2026.
The relationship now looks roughly like this:
Cloudflare
├─ Astro team
└─ VoidZero
├─ Vite
├─ Vitest
├─ Rolldown
├─ Oxc
└─ Vite+
I initially had a moment of wondering whether Vite+ had been a Cloudflare product from the start. More precisely, Vite+ originated at VoidZero, and VoidZero later joined Cloudflare.
That does not mean Astro is destined to adopt Vite+. Both projects say they intend to remain open source and vendor-neutral.
Still, having the Astro and Vite+ teams this close organizationally makes the future boundary between the two ecosystems more interesting to watch.
As someone who already uses Astro and Cloudflare Workers, I also find the continuity of the development effort easier to feel comfortable with than before.
A strong candidate for new projects
I do not feel any urgency to migrate existing projects immediately, but Vite+ looks like a very strong candidate for new ones.
For someone using Astro + Bun, a stack like this seems entirely plausible:
Framework Astro
Package Manager Bun
Toolchain Vite+ (gradual adoption)
Deploy Cloudflare
More than anything, I like the idea of not having to reconsider the linter, formatter, and surrounding toolchain from scratch every time I create a project.
What I am hoping Vite+ can provide is the reassurance of starting from a modern, fast set of best practices without having to assemble that stack manually every time.
Reference: Announcing Vite+ 1.0
Reference: Vite+ Documentation
Reference: Astro 7.0
Reference: Astro is joining Cloudflare
Reference: VoidZero is joining Cloudflare
