Recently we ran into a very strange issue while working on a large Next.js application with a custom server and markdown rendering based on react-markdown, remark, and rehype.

At first the error looked completely unrelated to our codebase:

ReferenceError: boolean is not defined

The stack trace pointed somewhere deep inside generated Next.js chunks and property-information, one of the dependencies used internally by the markdown ecosystem.

The interesting part was that our application code itself was completely valid and worked perfectly in production builds and when using Webpack.

The Symptom

The error appeared only in development mode when running Next.js with Turbopack enabled.

The stack trace looked similar to this:

allowFullScreen: boolean,
async: boolean,

The generated chunk referenced a variable named boolean, but the symbol was never imported or defined.

This resulted in:

ReferenceError: boolean is not defined

The problem happened during module evaluation before React rendering even started.

What Made This Confusing

Initially it looked like:

• a TypeScript issue,
• a browsers compatibility problem,
• or even a Safari transpilation issue.

We also experimented with browserslist configuration because the project needed Safari 13 support.

However, none of that was actually related to the root cause.

The same exact codebase:

• worked with Webpack,
• worked in production,
• failed only in Turbopack dev mode.

That narrowed the issue down significantly.

Root Cause

After investigating the generated chunks, it became clear that Turbopack was incorrectly handling part of the ESM dependency graph inside the markdown ecosystem.

The issue appeared somewhere in the chain:

react-markdown
  -> rehype
    -> property-information

A required symbol import was effectively lost during bundling, producing invalid runtime code.

In other words: the application code was fine, but the generated client chunk was broken.

Why This Matters

This type of issue is difficult to debug because:

• the runtime error appears far away from the real source,
• the generated chunk is heavily transformed,
• and the stack trace points into internal build artifacts.

If you are using:

• react-markdown,
• remark,
• rehype,
• hast-util-*,
• or other modern ESM-heavy libraries,

you may encounter similar problems with Turbopack, especially in complex projects or custom server setups.

The Fix

We decided to explicitly switch the project back to Webpack.

For builds:

- next build
+ next build --webpack

For the custom Next.js server:

const app = next({
  dev,

  /**
   * Disable Turbopack for Next.js custom server due to runtime
   * module resolution issues with the react-markdown/rehype ecosystem.
   * Turbopack produced invalid client chunks causing
   * ReferenceError: boolean is not defined during module evaluation,
   * while the same code worked correctly with Webpack.
   */
  webpack: process.env.NEXT_USE_TURBOPACK !== 'true',
})

This immediately resolved the issue.

Final Thoughts

Turbopack is extremely fast and promising, but it is still evolving. In our case the performance benefits were outweighed by unstable module processing in a real-world dependency graph.

Webpack may be slower, but right now it is still significantly more battle-tested for large production applications with diverse ecosystems and legacy compatibility requirements.

If you encounter strange runtime errors inside generated chunks, especially with markdown or ESM-heavy libraries, try switching back to Webpack before spending hours debugging your own code.