Turbopack dev: imported binding left unrewritten (ReferenceError) when referenced after a for...of whose body ends in an unconditional return

[Onebu]

Link to the code that reproduces this issue

https://github.com/Onebu/turbopack-forof-return-repro

To Reproduce

1. pnpm install && pnpm dev (next 15.4.11, next dev --turbopack)
2. curl http://localhost:3000/api/repro

The route imports a named function and references it after a for...of loop whose body ends in an unconditional return:

import { beta } from '../../../lib/util'

export function GET(request: Request): Response {
  const url = new URL(request.url)
  const items: string[] = url.searchParams.get('items')?.split(',') ?? []
  for (const item of items) {
    if (item === 'ok') continue
    return Response.json({ bad: item })
  }
  return Response.json({ typeofBinding: typeof beta })
}

Current vs. Expected behavior

Current (15.4.11): response is {"typeofBinding":"undefined"}. In the compiled dev chunk (.next/server/chunks/*), references to the imported binding placed after the loop are left as the bare identifier instead of being rewritten to __TURBOPACK__imported__module__...["beta"] — so calling it throws ReferenceError: beta is not defined at runtime. References before the loop in the same function, and all references in sibling functions, are rewritten correctly.

Expected: {"typeofBinding":"function"} — which is what next 16.2.10 returns for the identical app, and what webpack dev/build produce on 15.4.11.

Notes from a larger app where we hit this in production code:

• Deterministic, survives recompiles/HMR; not a race.
• Positional, not name-based: aliasing the import (import { beta as b }) just moves the ReferenceError to the new name; importing directly from the source module instead of a barrel doesn't help either.
• The trigger is precisely the loop body being unable to complete normally via an unconditional tail return: making that return conditional (if (item !== '') return ...) fixes resolution; deleting it fixes it as well. Template literals, ?./??, and outer-scope writes near the loop were all ruled out.
• Real-world impact in our app: a route handler's server-side validation call after such a loop threw ReferenceError, was swallowed by a fail-open catch, and validation was silently skipped in dev only.

Since 16.x is fixed, this is presumably already known internally or fixed incidentally — filing mainly in case a 15.x backport is considered, and for searchability (the symptom is very hard to attribute: the ReferenceError carries the original identifier name and looks like a scoping bug in user code).

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin 25.5.0
  Available memory (MB): 32768
  Available CPU cores: 10
Binaries:
  Node: 22.22.2
  npm: 10.9.7
  pnpm: 10.33.0
Relevant Packages:
  next: 15.4.11
  react: 19.2.7
  react-dom: 19.2.7
  typescript: 6.0.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Turbopack

Which stage(s) are affected? (Select all that apply)

next dev (local)

[mahdysp]

Turbopack dev: imported binding left unrewritten (ReferenceError) after a for...of whose body ends in an unconditional return (#95494)

TL;DR

This is a genuine Turbopack code-generation (import-rewriting) bug in the 15.4.x line, not a bug in your code. When a for...of loop body cannot complete normally (its last statement is an unconditional tail return), Turbopack's ESM import binding rewriter fails to rewrite references to imported bindings that appear after the loop — leaving them as bare identifiers instead of __TURBOPACK__imported__module__...["beta"], so they throw ReferenceError at runtime.

• Already fixed in 16.x — 16.2.10 returns the correct {"typeofBinding":"function"} for the identical app.
• Only affects next dev --turbopack on 15.4.x; webpack dev/build on 15.4.11 is correct.
• Practical fixes on 15.x: run dev with --webpack, upgrade to 16.x, or make the tail return conditional / restructure the loop.

---

What's actually happening

Turbopack rewrites ESM imports into indexed accesses on a synthetic module object (__TURBOPACK__imported__module__$...$__["beta"]). To decide which identifiers are references to imported bindings, it walks the function body and tracks binding usage. The report shows the failure is positional and deterministic:

• References to the import before the loop → rewritten correctly.
• References in sibling functions → rewritten correctly.
• References after a loop whose body ends in an unconditional return → left as bare identifiers → ReferenceError: beta is not defined.

The precise trigger is that the loop body cannot complete normally: because every path through the body ends in continue or an unconditional return, the code after the loop is, from a control-flow standpoint, only reachable via the loop's normal exit — and Turbopack's usage/reachability analysis appears to treat that trailing region incorrectly, dropping the rewrite for imported bindings referenced there. The reporter confirmed the boundary cleanly:

• Making the tail return conditional (if (item !== '') return ...) → fixed.
• Deleting the tail return → fixed.
• Aliasing the import moves the error to the new name (positional, not name-based).
• Importing directly instead of via a barrel doesn't help.
• Template literals, ?./??, and outer-scope writes were ruled out.

This is the same category of Turbopack import-reference miscompilation seen elsewhere (e.g. mis-resolved/incorrectly-referenced __TURBOPACK__imported__module__ bindings in other reports), just triggered by a specific control-flow shape.

Why it's dangerous (and hard to attribute)

The thrown ReferenceError carries the original identifier name (beta is not defined), so it looks exactly like a scoping/typo bug in user code rather than a bundler defect. In the reporter's real app, a post-loop server-side validation call threw ReferenceError, was swallowed by a fail-open catch, and validation was silently skipped in dev only — a correctness/security footgun that wouldn't surface in tests or production (webpack/16.x are unaffected).

What to do

If you can move versions (best)

• Upgrade to Next.js 16.x — the bug is fixed there (16.2.10+ confirmed by the reporter).

If you must stay on 15.4.x

• Run dev with webpack: next dev --webpack. Webpack's dev output is correct on 15.4.11.
• Restructure the trigger in affected handlers so the loop body can complete normally:

  // Instead of an unconditional tail return inside the loop body:
  for (const item of items) {
    if (item !== 'ok') return Response.json({ bad: item }) // conditional -> rewrite works
  }
  return Response.json({ typeofBinding: typeof beta })

  or hoist the post-loop work so the imported binding isn't referenced right after such a loop.

Don't rely on

• .next/.turbo cache clears — the report confirms it's deterministic and survives recompiles/HMR, so this is not a stale-cache issue.

On the report itself

It's a model bug report: minimal repro repo, exact compiled-output observation (bare identifier vs __TURBOPACK__imported__module__), a crisp control-flow bisection of the trigger, ruled-out confounders, cross-version confirmation (15.4.11 broken, 16.2.10 fixed, webpack fine), and a clear real-world impact. Since 16.x already resolves it, the ask is essentially "consider a 15.x backport + searchability", which is the right framing. The only thing that would further help maintainers is a note on whether it also reproduces with other loop forms (for, while, for...in) ending in an unconditional return, to bound the faulty analysis in the Rust rewriter.

---

Bottom line: a real Turbopack import-rewriting bug on 15.4.x — an unconditionally-returning for...of body causes imported bindings referenced after the loop to be emitted unrewritten, throwing a misleading ReferenceError at runtime in dev only. It's already fixed in 16.x; on 15.x use next dev --webpack, upgrade, or make the loop's tail return conditional.