Webpack Migration 2026: Vite, Rspack or Turbopack

People usually pitch a webpack migration as a speed upgrade. That is the weakest reason to do it. Moreover, the benchmark most often quoted in support does not measure what people think it measures. There is a real argument for moving, but it lies elsewhere.

Webpack is not collapsing.

Start by discarding the premise. Webpack’s npm downloads are growing: 107.8 million in September 2023, 110.6 million in 2024, 139.0 million in 2025, and 204.1 million in the thirty days to 21 September 2026.

The project ships too. The current stable is 5.111.1, from 18 September 2026. Furthermore, seven minor releases landed between February and September, carrying new features rather than only fixes. No webpack 6 exists.

Furthermore, webpack remains a first-class option inside Next.js 16.3 through next dev --webpack and next build --webpack, with no removal timeline published. Anyone telling you webpack is abandoned has not checked.

The actual risk is concentration.

Here is the number that should drive the decision. Of the 100 commits to webpack in the ninety days to 22 September 2026, 78 came from a single author, across six distinct contributors in total.

The maintainers are candid about why. Their roadmap states plainly that volunteers run the project, with no full-time engineering team. Contributor time therefore tracks donation income directly. That income runs to roughly 180,000 US dollars a year from 3,005 backers. Meanwhile, the package it supports is pulled over 200 million times a month.

So the honest framing isn’t that webpack is slow. It is that webpack carries an enormous share of the ecosystem on very few people. That is a legitimate reason to plan a migration. It’s also a reason to plan calmly, not urgently.

Rspack: the compatible path, and what does not port

Rspack reimplements webpack’s API in Rust. That makes it the lowest-friction destination for an existing config. The current stable is 2.2.7, released 23 September 2026, with a roughly weekly patch cadence.

Compatibility is good but not total, and the gaps are specific. The community plugin table tracks 56 webpack plugins: 28 work as-is, 12 need swapping for a named alternative, and 5 are superseded by built-in functionality.

Two failures are worth knowing before you start. First, Rspack does not implement resolve.plugins at all, so any resolver plugin breaks. The docs name tsconfig-paths-webpack-plugin and point to the built-in resolve.tsConfig instead. Second, the CLI flags --progress, --color, --bail and --output-pathinfo fail with an unknown-option error before Rspack evaluates your config. As a result, the first run looks worse than it is.

Note also that Rspack 2.0, from 22 April 2026, requires Node 20.19 or 22.12 and above. As a result, Node 18 no longer works.

Vite 8: a different architecture underneath

Vite 8 shipped stable on 12 March 2026 and replaced the old two-bundler split — esbuild for dev, Rollup for production — with Rolldown as a single Rust bundler, using Oxc for transforms.

That change brings its own migration work, even for existing Vite users. build.rollupOptions became build.rolldownOptions. Additionally, CommonJS default-import interop now applies the same rules in dev and production, and the migration guide warns plainly that this can break working code. Oxc also cannot lower native decorators, so codebases using them need a Babel or SWC plugin.

Finally, esbuild is no longer a direct dependency, and transformWithOxc now replaces transformWithEsbuild.

A timeline worth knowing about Rolldown

One detail deserves attention. Rolldown reached 1.0 stable on 7 May 2026 — two months after Vite 8 had already made it the default bundler for every Vite user.

That 1.0 also locks less than it sounds. The guarantee covers option names, types, and plugin hook signatures. However, output behavior and option defaults remain explicitly open to change. That includes dead-code elimination, chunking, and inlining heuristics.

Rolldown’s own documentation does not recommend using it directly for application builds. Instead, it routes applications to Vite. Rolldown also leaves several Rollup hooks unimplemented, and drops the system and amd output formats. None of this disqualifies it. Nevertheless, it is worth knowing you are early.

Turbopack is a Next.js decision, not a bundler decision

Turbopack is the default bundler in Next.js 16, and it carries no official support for other frameworks. So if you are not on Next.js, it does not belong on your list.

If you are, one status point matters. The Next.js documentation tracks dev as stable from 15.0 and build as beta from 15.5. Notably, it never states that the production build reached stable. Webpack meanwhile stays available as an opt-out, which is the sensible reading of that gap.

The benchmark everyone quotes does not exist.

This section is why you should be skeptical of migration pitches generally.

Vercel’s headline figures promise “2 to 5 times faster production builds” and “up to 10 times faster Fast Refresh”—neither names a project size, a baseline webpack version, hardware, or what was measured. Furthermore, the workload widely circulated as their basis — an app of some 2,847 TypeScript files — appears in no Vercel source at all.

The “5.5 times faster” figure is real, but people misread it. Vercel measured Turbopack against Turbopack, cold cache versus warm, on their own sites. That gave 21 seconds down to 9.2 on nextjs.org, 66 to 46 on one property, and 30 to 5.5 on another. It compares nothing to webpack.

So no official, workload-defined Turbopack-versus-webpack benchmark currently exists. Vite’s “10 to 30 times faster than Rollup” claim is more credible, since it cites a public suite with fixtures pinned from 2,413 to 19,014 modules. Even so, that compares Rolldown with Rollup, not with webpack.

One further caution on cache-based gains: they live in, so a CI pipeline only benefits if that directory is restored between runs. Most containerized pipelines discard it.

A webpack migration framework

1. Measure your own build first. No published multiplier describes your repository, and on a warm build the bundler is often a minority of total build time.
2. If you are on Next.js, this is decided for you. Turbopack is the default; keep the webpack opt-out until you’ve proven your production builds.
3. If you want to keep your config, start with Rspack. Audit for resolver plugins and unsupported CLI flags before estimating.
4. If you are willing to rewrite the config, Vite is the larger ecosystem — but budget for the Rolldown transition alongside it.
5. Weigh the maintenance argument, not the speed one. Concentration risk is the durable reason to move.
6. Do it before you need to. Under time pressure is exactly when you discover the unsupported plugins.

How Pegotec helps

We scope build-tool migrations by auditing the plugin surface first, because that is where the estimate actually lives. We’ll also tell you when staying on webpack is the right answer for another year.

If you are weighing this on a codebase that ships daily, talk to us.

Read next

• When to Rewrite vs. Maintain — the same decision at application scale.
• The True Cost of Deferred Maintenance — what waiting costs.
• What Managed Maintenance Actually Involves — keeping dependencies current in practice.

FAQ