Table of Contents
1. Why Vite 8 mattered
CRXJS sits right where browser extension semantics meet Vite internals: manifest parsing, content script emission, dev-server loading, HMR, and production output. When Vite 8 moved the bundling story forward with Rolldown, that was exactly the kind of change that can expose every weak assumption in an extension plugin.
The Extension.js docs captured one visible failure mode: [crx:manifest-post] Content script fileName is undefined. That error was a useful signal, because it pointed at the real integration boundary: CRXJS needed to keep extension-specific output reliable while Vite changed underneath it.
That is the kind of maintenance worth showing off: concrete, public, and measurable. The team did not just update a version range. The upgrade became CI jobs, compatibility fixtures, E2E regressions, HMR fixes, and local tooling that makes the next Vite change easier to handle.
2. What shipped
As of June 19, 2026, the published package is @crxjs/vite-plugin@2.7.0. Its peer dependency accepts vite@^3.0.0 || ^4.0.0 || ^5.0.0 || ^6.0.0 || ^7.0.0 || ^8.0.0. The current CI workflow backs that up with compatibility and E2E jobs for Vite 3, 6, 7, and 8 on Ubuntu and Windows.
Published support
The current npm package explicitly includes Vite 8 in its peer dependency range.
CI matrix
The current workflow runs compatibility and E2E jobs across Vite 3, 6, 7, and 8 on Ubuntu and Windows.
E2E coverage
The matrix exercises browser extension behavior, not just package installation or type checks.
Maintainer workflow
A local matrix runner lets maintainers reproduce the same Vite-major paths before release.
This is what a real upgrade looks like in an open-source build tool: release metadata, a CI matrix, browser-level E2E tests, and enough local tooling that maintainers can reproduce the same compatibility paths before publishing.
3. The upgrade story
The best part of this work is that it is all visible. You can follow the story pull request by pull request: first make the matrix possible, then add the new Vite major, then let CI expose the weird cases, then turn those cases into tests.
Consolidated Vite version tests into matrix-based CI
Collapsed separate compatibility test packages into one matrix flow for Vite 3, 6, and 7 on Ubuntu and Windows.
Added Vite 8 beta support and CI testing
Added Vite 8.0.0 beta coverage before the stable release and expanded the peer dependency range.
Tested the plugin across Vite 3, 6, 7, and 8
Ran E2E and compatibility tests across Vite 3, 6, 7, and 8 on Ubuntu and Windows.
Allowed extension origins in dev CORS
Handled stricter Vite dev-server CORS defaults for chrome-extension:// and moz-extension:// origins.
Sped up the Vite E2E runner
Removed fixed waits, warmed Chromium profiles, and reported a 31.9% reduction on a measured fixture.
Added a local Vite matrix test runner
Made the CI compatibility matrix reproducible locally without manually editing dependency versions.
Added MAIN world content script HMR
Added HMR for manifest-declared MAIN-world content scripts with an E2E regression test.
Coalesced file-writer readiness waits
Fixed readiness recomputation and late HMR waits with targeted unit and E2E coverage.
Handled React Refresh self imports in content script HMR
Fixed a Vite 8 and React plugin 5.2.0 edge case where generated self imports could block HMR payload forwarding.
That is the pattern worth bragging about: each PR moved uncertainty into automation. A CORS regression became unit coverage. MAIN-world content script HMR became an E2E regression. React Refresh self imports became a focused Vite 8 test. The next maintainer does not need to remember the incident. CI remembers it.
4. Why the E2E tests matter
Extension tooling bugs rarely show up as clean unit-test failures. They show up as a popup stuck on a loading page, a content script that did not reload, a service worker importing from a blocked origin, or a browser profile paying startup cost on every fixture.
That is why the Vite plugin workflow matters: it does not stop at linting and unit tests. The current CI runs compatibility tests and E2E tests across Vite 3, 6, 7, and 8 on Ubuntu and Windows. The E2E runner launches Chromium under XVFB on Linux and validates actual extension behavior.
The speed work was not cosmetic
PR #1177 removed a redundant fixed wait, warmed an empty Chromium profile, and reported a 31.9% reduction on a measured fixture. Faster E2E tests change project behavior: maintainers run them more often, regressions are cheaper to catch, and compatibility work stops feeling like a special ceremony.
That is the real development acceleration. Not a slogan. A shorter loop from "Vite changed something" to "there is a reproducer, a fix, and a regression test."
5. What the OS matrix proves
The current CRXJS Vite plugin workflow lists Ubuntu and Windows for unit/output, compatibility, and E2E jobs. That matrix is worth being proud of because Windows is where extension tooling often gets punished by path handling, file copying, line endings, and file-system timing.
PR #1008, the big Windows enablement PR, explicitly discussed macOS as a possible 1:1 match with the Vite project workflow. The decision at that time was pragmatic: macOS behaved like Ubuntu for the relevant cases, while Windows had real path, file-copying, snapshot, and HMR differences that needed first-class coverage.
So the precise version is also the stronger version: CRXJS currently proves the Vite 3/6/7/8 matrix on Ubuntu and Windows, including browser-level E2E jobs. That is the hard cross-platform work that made the project more reliable for real teams.
6. Public receipts
The work is public, which is exactly how open-source infrastructure should be. If you want to judge the state of CRXJS on Vite 8, start with the release metadata, the CI workflow, and the merged pull requests.
Need extension tooling that survives upgrades?
We build browser extensions and the CI pipelines around them. When Vite, Chrome, or Manifest V3 changes underneath you, we know where to look and how to lock the fix into tests.
