Vite+ is the missing project hygiene around Vite
Vite already made frontend projects much faster to start. The problem is that a real project needs more than a dev server and a build command. It needs linting, formatters, checks, scripts, and defaults that keep the repository usable after the first afternoon.
That is the useful part of Vite+. It packages more of that setup around the Vite workflow we already know. For extension projects, this matters because the baseline is already busy: popup, options page, content script, background service worker, manifest, permissions, reload behavior, and production packaging.
If the starter also brings checks and formatting with it, a new extension project starts closer to the shape a team can actually keep using.
What landed in CRXJS
PR #1217 adds a dedicated playgrounds/vite-plus app to crxjs/chrome-extension-tools. It uses the Vite+ beta command surface and gives the repository a place to validate those project-level commands against extension-specific behavior.
Real MV3 shape
The playground includes a popup and a content script instead of only proving that a package installs.
Visible browser check
The content script injects a CRXJS button and a visible panel into matching pages.
Project checks
The validation path covers the Vite+ commands that matter before a project leaves the starter stage.
Repo-local loop
The root script pnpm play:vite-plus makes the beta path easy to run from the repo.
That is deliberately small. Small is good here. The point is not to pretend that every extension architecture is solved. The point is to check whether this fuller Vite+ starter still works when the project is a real Manifest V3 extension.
The value is not novelty, it is less setup
This is not about pretending that Vite+ is a revolution. It is about removing the dull setup that every serious project needs anyway. If linting, checks, formatting, test commands, and a real extension shape are present from the beginning, developers can spend less time arranging the repo and more time building the extension.
That is the point of putting this in CRXJS now. A starter is only useful if it survives the first real project. If people try side panels, multiple content scripts, options pages, service-worker imports, shared UI, and CI packaging, we will see which parts of the Vite+ flow help and which parts still need work.
The interesting part is what people do next
The next phase is not about celebrating a green build. It is about seeing whether this extra tooling changes the first hour of a browser extension project. Do teams get to a working popup and content script faster? Do they keep linting and checks on from day one? Do they stop copying the same setup from the previous repo?
Those are the questions worth testing now. The playground gives us a place to ask them without pretending we already know every answer.
What we want to see
- New extension projects started directly on the Vite+ beta flow.
- Reports that show which lint, check, format, test, and build commands people actually keep.
- Examples showing how quickly a fresh project becomes a loaded Chromium extension.
- CI examples that prove the final dist can load in Chromium.
- Feedback on whether Vite+ removes setup work or only moves it somewhere else.
If this works, the win is not a fancy new abstraction. The win is boring and useful: fewer setup decisions before a developer can build a real extension.
Sources
Want a browser extension project with the setup already handled?
We build browser extensions and the CI checks around them, including final-dist smoke tests that catch problems before users do.
