Next.js: Turbopack Gets Major Webpack Compatibility Boost

Transcript

Hey there, developers! Welcome back to another episode of the Next.js podcast. I'm your host, and wow, do we have an exciting episode for you today. March 19th brought us some absolutely fantastic updates to the Next.js ecosystem, and I'm genuinely excited to dive into what the team has been cooking up.

Let's jump right into the star of today's show - and honestly, this is one of those changes that made me do a little happy dance when I read through it. Tobias Koppers just merged a absolutely massive PR that adds full `importModule()` support to Turbopack's webpack loader compatibility layer. Now, I know that might sound a bit technical at first, but here's why this is such a big deal.

You know those webpack loaders you love - things like vanilla-extract, val-loader, or your custom loaders that need to dynamically import and execute modules during the build process? Well, they've been stuck in webpack-land because Turbopack couldn't handle their `this.importModule()` calls. But not anymore! This update brings a really elegant solution that lets these loaders work seamlessly with Turbopack.

The implementation is pretty clever too - it creates a request-response pattern between the Node.js loader runner and Rust-side Turbopack. When a loader calls `importModule()`, Turbopack resolves the module, builds a complete Node.js bundle with all dependencies, and evaluates it in-memory. The best part? It supports everything - TypeScript, CommonJS, ESM, JSON, even WebAssembly files. This is the kind of compatibility bridge that's going to unlock a whole ecosystem of tools for Turbopack users.

Speaking of fixes that make your day better, we got a crucial Pages Router fix from Henry that restores Content-Length and ETag headers for those `/_next/data/` JSON responses. This might sound small, but it was actually a regression that broke CDN compression for self-hosted deployments. One line change, huge impact - that's the kind of fix we love to see.

Zack Tanner also swooped in with a fix for RSC requests that were getting misclassified in deployed environments. The issue was with URL query parameters throwing off the response type detection, and his solution elegantly normalizes the URLs before processing. These are the kinds of edge cases that show how much care goes into making Next.js work smoothly in production.

Now let's talk about some really exciting infrastructure improvements. Will Binns-Smith enabled server-side HMR for app route handlers in Turbopack - this means your API routes now get that same lightning-fast hot reloading experience you love with pages. No more manual refreshes when you're tweaking your API logic!

The team also tackled some serious performance work under the hood. Luke Sandberg simplified the snapshotting logic in Turbopack's task system, making it more efficient by only encoding data that's actually been modified. Meanwhile, Tobias pushed through several optimizations for batch processing dirty tasks during aggregation updates. These aren't the flashy features that make headlines, but they're the foundation that makes everything else feel faster.

Security-wise, Denes Beck updated the vendored lodash to patch CVE-2025-13465 - always great to see the team staying on top of security updates. And JJ Kasper fixed an interesting edge case with encoded dynamic placeholders in app routes. These attention-to-detail fixes really show the maturity of the Next.js ecosystem.

One thing I really appreciate about this release is how it demonstrates the team's commitment to compatibility and developer experience. Whether it's making webpack loaders work with Turbopack, fixing caching headers for CDNs, or improving HMR for API routes - every change here is about making your development workflow smoother.

Today's focus should definitely be on exploring what this webpack loader compatibility unlocks for your projects. If you've been holding back on Turbopack because of specific loader dependencies, now might be the perfect time to give it another shot. The performance gains combined with this new compatibility could be a game-changer for your build times.

That's a wrap for today's episode! The Next.js team continues to impress with this balance of major feature work and careful attention to developer experience. Keep building amazing things, and we'll catch you next time with more updates from the Next.js world. Until then, happy coding!