Preparing workbox fork, a new modular PWA package and new versions for meta frameworks integration

[userquin]

We have been working hard over the last 6 months, and now that Vite 8 and Rolldown 1 are stable, we are happy to announce we're finishing the following:

• Workbox Fork: A radical modernization of the underlying build engine. We have applied a massive code cleanup, dropping the legacy dependency footprint from 340+ internal dependencies down to just ~20+ lean, maintainable native dependencies. It introduces a brand new buildSW strategy that relies on modern, native bundling powered directly by Vite 8 or Rolldown 1. Looking ahead, this new modular architecture opens the door to providing dedicated build plugins for other bundlers like Webpack and Rspack.
• Vite PWA Evolution (@vite-pwa/core): The current single-plugin architecture is evolving into a fully modular core ecosystem. The project will be split into @vite-pwa/core, which will expose individual, granular plugins for advanced modular orchestrations, alongside an all-in-one plugin tailored for standard Vite applications (highly compatible with the existing setup).

Note

Next Steps & Roadmap: While the underlying architecture and core compilation engines are fully complete and verified, we still have a significant amount of work ahead of us before the first public release. Over the coming weeks, we will be migrating the codebase from our private monorepo to the official @vite-pwa/workbox repository (which is already living under the Vite PWA organization on GitHub), establishing the new @vite-pwa/core project infrastructure, restructuring the testing suites, and orchestrating the initial packages distribution. Please note that meta-framework integrations will be updated last, once both @vite-pwa/workbox and @vite-pwa/core are fully synchronized and available.

Note

Compatibility, EOL, and Ecosystem Transition:

• Full Vite Backward Compatibility & Rolldown Requirement: The new architecture retains full backward support for legacy Vite versions (Vite 3 through Vite 7) via dedicated legacy build pipelines. However, because the modernized core unifies its Service Worker generation and dependency graphing, consumers running any Vite version below Vite 8 will be required to install rolldown as a direct dependency in their projects to power the underlying engine.
• vite-plugin-pwa & Google Workbox Status: The existing vite-plugin-pwa package will remain frozen in maintenance mode, receiving only critical fixes, while all next-gen features and modular plugins will live exclusively in the new packages. Beware that Google Workbox will be discontinued and will link directly to the new @vite-pwa/workbox repository. At some point in the near future, the legacy vite-plugin-pwa package will be formally marked as obsolete.

---

🚀 Deep Dive into the New Architecture

📦 The Modernized Workbox Fork (Powered by Rolldown Everywhere)

The legacy Workbox build system was designed in a different era of the web. By forking and rewriting its core internals, we've gotten rid of massive amounts of technical debt (like magicast manipulations and complex configuration layers).

• Native Bundler Performance: The new buildSW engine hooks directly into Vite 8 or Rolldown 1's native dependency graphs.
• Service Worker Code-Splitting Support: While the current vite-plugin-pwa forces the Service Worker to be built as a single monolith, the new version introduces full code-splitting support. The new engine checks if inlineWorkboxRuntime is disabled; if so, it automatically breaks down the monolith, computes the resulting dependency graphs, tracks internal synchronous imports, and guarantees that chunks are correctly structured and resolved whenever a Classic Service Worker build is targeted (either as a standalone choice or as part of the Dual Build strategy).
• Advanced Custom Chunks & Visual Graphing (Experimental): Alongside standard code-splitting, we are introducing highly experimental support for user-defined customChunks via granular configuration callbacks. The engine will dynamically map these custom allocations, resolve complex internal dependencies, and orchestrate them seamlessly. To guarantee total safety, the engine features a built-in contention layer that blocks deployment errors (such as preventing a Service Worker or its internal synchronous runtime dependencies from accidentally precaching themselves) and intercepts circular graph conflicts before they can pollute your production environments.
• Next-Gen ESM Service Worker Support: Since 2026, all major browsers natively support Service Worker registration with { type: 'module' }. The new buildSW engine embraces this fully, offering native ESM Service Worker generation alongside an automated Dual Build strategy—allowing you to compile a modern ESM Service Worker and a legacy Classic Service Worker simultaneously from the same source. Note that this strategy requires your source code to be written using strict ESM syntax (import/export); the engine will then automatically handle the down-leveling and inject the required internal orchestration whenever the Classic asset target is compiled.
• Automatic Feature Detection: We are introducing @vite-pwa/workbox-window, which exposes a lightweight esm-sw-detector runtime utility based on verified CanIUse baseline specifications. This module determines browser capabilities on the fly to orchestrate modern asset loading.
• Bundler Agnostic Future: The separation of concerns makes the core engine completely agnostic. We will expose dedicated standalone plugins for Webpack and Rspack via unplugin. At the buildEnd phase of those bundlers, the plugin will seamlessly invoke Rolldown internally to bundle, resolve, and generate the final Service Worker.

🧩 The @vite-pwa/core Unplugin Ecosystem & Meta-Frameworks

The new architecture shifts the responsibility away from rigid configurations toward an extensible, programmatic pipeline where integrations and meta-frameworks know exactly what to do.

• Granular and Modular: Instead of forcing you into a single monolithic config, you can now compose your PWA layer using low-level plugin pieces or stick to the simple application-level wrapper.
• Next-Gen Meta-Framework Logic: Meta-framework integrations (Nuxt, SvelteKit, Astro, VitePress, etc.) are getting a massive logic simplification. The underlying core plugins will handle the orchestration natively without complex boilerplate hacks.
• Vite Environment API Ready: The new core is built looking forward. It comes with out-of-the-box support for Vite 8 and features on-demand activation for the new Vite Environment API (introduced at Vite 6). The underlying framework integrations will automatically tap into these environments when required—only when activated under demand—meaning zero dead weight for standard builds.
• Smart Dual-Registration & Zero-Overhead DCE: When Dual Build is active, the generated virtual modules utilize the esm-sw-detector to dynamically register the ESM or Classic variant depending on browser capabilities. However, if the consumer configures a single baseline build (pure Classic or pure ESM), the compiler applies aggressive Tree-Shaking / Dead Code Elimination (DCE) to entirely purge the esm-sw-detector logic from the resulting virtual chunk, guaranteeing zero overhead for standard applications.
• Native TrustedScriptURL & CSP Compliance: Legacy virtual modules lacked flexibility when strict Content Security Policies were enforced during Service Worker registration. The new architecture introduces first-class support for TrustedScriptURL, including a highly flexible, custom callback option to safely resolve and sanitize the script URL before registration kicks in.

---

🛠️ Current Status & High Experimental Notice

We are in the final stages of refining the synchronous code-splitting re-mapping pipelines, telemetry collectors, and unified error handling logs.

Warning

Some next-gen capabilities—especially advanced custom chunks relations or edge-case graphs handling—will be released under a strict @experimental flag. Consumers will be heavily encouraged to thoroughly review and inspect their local or staging dist asset outputs before deploying to production.

Stay tuned! We can't wait to share this with you all very soon. 🍿

[userquin]

📸 Next-Gen Features in Action: Live Previews

To give you a taste of what’s coming, here are a few live captures of the new engine running under the hood. The speed of Rolldown (written in Rust) driving these complex graphs in parallel is absolutely mind-blowing.

---

1. Natively Driven ESM Service Workers (Chrome & Firefox)

Here is the automated Dual Build strategy working seamlessly in parallel. The engine outputs a modern ESM Service Worker (type: 'module') for modern baselines and a legacy Classic Service Worker from the exact same source code.

Dual Service Worker builds run in parallel

Chrome ESM Service Worker

Firefox ESM Service Worker

---

2. Advanced Service Worker Code-Splitting & Custom Chunks

Breaking the legacy Workbox monolith. Here is how the new engine behaves when inlineWorkboxRuntime is disabled and custom allocations are requested via configuration callbacks.

Resulting Output Build Graph

---

3. Centralized Circular Dependency Control & Telemetry Logs

No more raw, messy native warnings flooding the terminal mid-build. The new asynchronous pipeline captures conflicts, validates safety guards (preventing assets from precaching themselves), and reports everything in a structured, zero-overhead summary right at the end of the build.

Terminal Warning Summary Reporting

Why this changes everything?

Seeing Rolldown compile both targets in milliseconds while orchestrating asynchronous chunks and tracking circularities locally proves that the future of PWAs is modular, safe, and blindingly fast. 🚀