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 described not as a framework, package manager, or replacement for Vite itself, but as a unified development toolchain.
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 have not yet migrated one of my Astro projects to Vite+ in earnest, so how much configuration can actually be removed is something I still want to test.
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+
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
Comments