What This Repository Does

This is a bug report and reproduction case for a crash in Next.js's Turbopack bundler. When you try to build a Next.js app with certain module configurations, the build fails with a cryptic error message about JavaScript proxies. The bug doesn't happen with Webpack (the previous default bundler), only with Turbopack, which became the default in Next.js 16.

The Problem in Everyday Terms

Imagine you have three files: one that marks code to run only in the browser ("use client"), one that runs only on the server, and a third file that re-exports things from both. When a server component tries to look at all the exports from that third file (by using the spread operator {...aggregate}), Turbopack crashes. It's like asking a container "what's inside you?" and the container giving contradictory answers about its contents, which JavaScript's rules don't allow.

Why It Matters

This bug started appearing in Next.js 16 because that version switched to using Turbopack for builds by default. Any project that combines server and client code with wildcard re-exports (export * from) could hit this crash during the build step, making it impossible to deploy. The person who reported it found that Webpack handles the same code fine, which narrows down the problem to Turbopack specifically.

The Technical Root Cause (Simplified)

Under the hood, Turbopack has two different ways of handling module exports. One way locks the exports in place (makes them unchangeable), and the other way tries to add extra exports dynamically. When both happen to the same module, they fight each other—one says "the exports are sealed," the other says "I'm adding more exports," and JavaScript throws an error because that's contradictory. The workaround is simple: instead of using export * from "./client", use export { ClientThing } from "./client" to explicitly name what you're re-exporting, which avoids triggering both mechanisms at once.