The filesystem cache is available in beta on Next 16.0, and we're hoping to ship it as stable and on-by-default very soon (we've been working on it for over a year!). nextjs.org/blog/next-16...

Regarding compilation upon navigation: It should be better in Next 16, but we are working on a couple things to address this:
- A file-system cache that persists across restarts of `next dev`.
- An alternate bundling mode that shares more work across pages, at the cost of a slower first page load.

@runofthemillgeek.com Happy to help dig in, especially with traces, if that document doesn't solve it for you. My DMs are open.

Local microfrontends support is a big deal!

You can try it out both of these features today in the latest Next.js canary:
npm install next@canary

If you run into any issues, let me know so we can fix it before Next.js 16 goes out!

In addition to this automatic configuration of Babel, we added a new 'condition' field for controlling when manually-configured webpack loaders run in Turbopack.

It builds on top of internal functionality that we didn't cleanly expose until now.

Fortunately, the breaking changes planned for 16 should be pretty minor for most people.

Did you try the codemods that Next 15 shipped with?

Yikes. One major difference between Turbopack and webpack is that Turbopack uses a stricter parser (lightningcss) that errors on broken css that would be silently ignored in webpack.

The new behavior is better, but the migration can be painful.

I'd love to hear if you figure out the issue here.

You're right. We don't recommend it for anything mission-critical yet, but we also want to get some feedback from early adopters. We've been using it for internal tools where client performance or SEO isn't critical.

Turbopack for Dev workflows is stable, and we do recommend that you try that out!