Issue Station
Sign In
Tools hereToolbox

nextjs - ✅(Solved) Fix Turbopack stack overflow when compiling a page with `@techstark/opencv-js` import [1 pull requests, 7 comments, 5 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
vercel/next.js#85357•Fetched 2026-04-08 02:16:13
View on GitHub
Comments
7
Participants
5
Timeline
20
Reactions
1
Author
hlysinehlysine
Participants
AkshatGiriAkshatGirigithub-actions[bot]github-actions[bot]hlysinehlysinelukesandberglukesandbergtimneutkenstimneutkens
Assignees
lukesandberglukesandberg
Timeline (top)
commented ×7labeled ×3mentioned ×2subscribed ×2

Fix Action

Fixed

PR fix notes

PR #85592: Reimplement code frame rendering in native code

Description (problem / solution / changelog)

What

Replaces the @babel/code-frame dependency with a new Rust-based implementation (next-code-frame crate) for rendering code frames in error messages.

Why

  • Crash fix: @babel/code-frame uses the js-tokens library for syntax highlighting, which has known issues with large string literals and long lines. This can cause Next.js to throw RangeErrors when rendering errors, hiding the original issue!
  • Long line support: The old implementation had no concept of terminal width, dumping entire lines into the output. The new implementation uses "horizontal scrolling" — truncating lines and centering the error location in the visible window.
  • Performance: The Rust implementation only processes the visible line range (typically ~6 lines), not the entire file. Syntax highlighting uses a skip-scan heuristic to start tokenizing near the visible window rather than from byte 0.
  • Dependency reduction: Drops the semi-unmaintained @babel/code-frame bundled dependency in favor of code we control.

Benchmarks

In-process benchmarks comparing render_code_frame() (Rust, via criterion) against codeFrameColumns() (Babel, via hrtime with DCE prevention). Both have syntax highlighting and color output enabled. No process startup or file I/O is included in the measurement.

Scenarionext-code-frame (Rust)@babel/code-frameSpeedup
Small file (~490 lines TSX)5.4 µs507 µs~94x
Large file (~39k lines JS)143 µs82.9 ms~580x
Large file minified51 µs--

The gap widens with file size because Babel's highlight() runs a regex tokenizer over the entire source before slicing to the visible window, while the Rust implementation uses a windowed line index and skip-scan heuristic — only processing the visible window regardless of file size. However, for minified files we do end up tokenizing the whole thing so we end up being only 8x faster

How

  • New crates/next-code-frame/ Rust crate with:
    • Frame rendering with terminal-width-aware horizontal scrolling
    • Regex-based syntax highlighting (matching Babel's color scheme)
    • Skip-scan heuristic for O(1)-ish highlighting regardless of file size
    • Windowed line index that only scans/stores offsets for the visible region
    • Comprehensive test suite (800+ lines)
  • Exposed via both NAPI (native) and WASM bindings
  • JS wrappers in packages/next/src/shared/lib/errors/:
    • code-frame.ts — primary wrapper using native bindings
    • optional-code-frame.ts — graceful fallback returning undefined if bindings are unavailable
  • All existing callsites (diagnosticFormatter, parseScss, dev overlay, turbopack utils) updated
  • for patch-error-inspect.ts i adopted an injection style approach to avoid coupling to the native dependency

Concerns / review focus areas

  • Reliability: The regex-based tokenizer is best-effort and language-agnostic — it should never crash on invalid syntax, but highlighting accuracy may differ from Babel's js-tokens in edge cases.
  • Native dependency: This moves code frame rendering into the native binary. Performance should be better, but worth verifying there are no regressions in environments where native bindings behave differently (e.g. WASM fallback path).
  • Regressions: The output format and color scheme closely match Babel's, but there may be subtle differences. The horizontal scrolling behavior is new.

Fixes #85357 Closes PACK-5754

Changed files

  • Cargo.lock (modified, +22/-4)
  • Cargo.toml (modified, +3/-0)
  • crates/next-code-frame/Cargo.toml (added, +34/-0)
  • crates/next-code-frame/README.md (added, +82/-0)
  • crates/next-code-frame/benches/code_frame_bench.rs (added, +207/-0)
  • crates/next-code-frame/src/bin/code_frame.rs (added, +83/-0)
  • crates/next-code-frame/src/frame.rs (added, +538/-0)
  • crates/next-code-frame/src/highlight.rs (added, +1586/-0)
  • crates/next-code-frame/src/lib.rs (added, +10/-0)
  • crates/next-code-frame/src/tests.rs (added, +920/-0)
  • crates/next-napi-bindings/Cargo.toml (modified, +1/-0)
  • crates/next-napi-bindings/src/code_frame.rs (added, +108/-0)
  • crates/next-napi-bindings/src/lib.rs (modified, +1/-0)
  • crates/wasm/Cargo.toml (modified, +1/-0)
  • crates/wasm/src/lib.rs (modified, +19/-0)
  • crates/wasm/src/mdx.rs (modified, +2/-3)
  • packages/next/errors.json (modified, +2/-1)
  • packages/next/package.json (modified, +0/-1)
  • packages/next/src/build/index.ts (modified, +5/-0)
  • packages/next/src/build/load-jsconfig.ts (modified, +9/-6)
  • packages/next/src/build/swc/generated-native.d.ts (modified, +52/-0)
  • packages/next/src/build/swc/generated-wasm.d.ts (modified, +12/-7)
  • packages/next/src/build/swc/index.ts (modified, +21/-3)
  • packages/next/src/build/swc/types.ts (modified, +7/-0)
  • packages/next/src/build/webpack/plugins/wellknown-errors-plugin/parseScss.ts (modified, +4/-5)
  • packages/next/src/bundles/babel-code-frame/index.js (removed, +0/-3)
  • packages/next/src/bundles/babel/packages/code-frame.js (removed, +0/-1)
  • packages/next/src/compiled/babel-code-frame/LICENSE (removed, +0/-22)
  • packages/next/src/compiled/babel-code-frame/index.js (removed, +0/-1)
  • packages/next/src/compiled/babel-code-frame/package.json (removed, +0/-1)
  • packages/next/src/compiled/babel/code-frame.js (removed, +0/-1)
  • packages/next/src/export/worker.ts (modified, +7/-0)
  • packages/next/src/lib/typescript/diagnosticFormatter.ts (modified, +11/-11)
  • packages/next/src/lib/verify-typescript-setup.ts (modified, +4/-0)
  • packages/next/src/next-devtools/dev-overlay/styles/colors.css (modified, +10/-8)
  • packages/next/src/next-devtools/server/shared.ts (modified, +12/-12)
  • packages/next/src/server/dev/hot-reloader-turbopack.ts (modified, +6/-0)
  • packages/next/src/server/lib/install-code-frame.ts (added, +13/-0)
  • packages/next/src/server/lib/router-utils/setup-dev-bundler.ts (modified, +6/-0)
  • packages/next/src/server/patch-error-inspect.ts (modified, +24/-3)
  • packages/next/src/shared/lib/errors/code-frame.ts (added, +23/-0)
  • packages/next/src/shared/lib/turbopack/utils.ts (modified, +19/-17)
  • packages/next/taskfile.js (modified, +0/-23)
  • packages/next/types/$$compiled.internal.d.ts (modified, +0/-4)
  • pnpm-lock.yaml (modified, +0/-3)
  • test/e2e/app-dir/cache-components-errors/cache-components-errors.test.ts (modified, +6/-6)
  • test/e2e/app-dir/server-source-maps/server-source-maps.test.ts (modified, +3/-1)
  • test/production/next-server-nft/next-server-nft.test.ts (modified, +0/-5)

Code Example

(From Devbox)
Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Sun Aug  6 20:05:33 UTC 2023
  Available memory (MB): 4102
  Available CPU cores: 2
Binaries:
  Node: 20.9.0
  npm: 9.8.1
  Yarn: 1.22.19
  pnpm: 8.10.2
Relevant Packages:
  next: 16.0.1-canary.2 // Latest available version is detected (16.0.1-canary.2).
  eslint-config-next: N/A
  react: 19.0.0
  react-dom: 19.0.0
  typescript: 5.1.3
Next.js Config:
  output: N/A
RAW_BUFFERClick to expand / collapse

Link to the code that reproduces this issue

https://codesandbox.io/p/sandbox/opencv-turbo-stack-overflow-repro-7sp8kz

To Reproduce

  1. Open the Devbox, run the dev:turbo task and load the preview.
  2. Turbopack crashes with RangeError: Maximum call stack size exceeded
  3. Run the dev:webpack task instead and verify that Webpack compiles without issues.

Current vs. Expected behavior

I expect Turbopack to compile without issues, just like Webpack.

Provide environment information

(From Devbox)
Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Sun Aug  6 20:05:33 UTC 2023
  Available memory (MB): 4102
  Available CPU cores: 2
Binaries:
  Node: 20.9.0
  npm: 9.8.1
  Yarn: 1.22.19
  pnpm: 8.10.2
Relevant Packages:
  next: 16.0.1-canary.2 // Latest available version is detected (16.0.1-canary.2).
  eslint-config-next: N/A
  react: 19.0.0
  react-dom: 19.0.0
  typescript: 5.1.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)

Additional context

No response

extent analysis

TL;DR

The issue can likely be resolved by adjusting the configuration or dependencies related to Turbopack to prevent the RangeError: Maximum call stack size exceeded error.

Guidance

  • Verify that the next version (16.0.1-canary.2) is compatible with the current Turbopack configuration, as compatibility issues might cause the error.
  • Check the Turbopack configuration for any recursive or circular dependencies that could lead to a stack overflow error.
  • Compare the configurations and dependencies used by the dev:webpack task (which works) with those used by the dev:turbo task to identify potential differences that could be causing the issue.
  • Consider updating or adjusting the versions of react, react-dom, or typescript to ensure they are compatible with Turbopack and the current next version.

Example

No specific code example can be provided without more details on the Turbopack configuration or the codebase, but reviewing the differences between the Webpack and Turbopack configurations in the provided codesandbox link might offer insights.

Notes

The exact cause of the RangeError is not specified, and without more details on the project's configuration or code, it's challenging to provide a precise fix. The issue might be related to a specific dependency version or a configuration setting that's causing Turbopack to exceed the maximum call stack size.

Recommendation

Apply a workaround by adjusting the Turbopack configuration or dependencies to prevent the stack overflow error, as the root cause is likely related to a compatibility or configuration issue rather than a version problem that could be solved by an upgrade.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#task chaining#parallel task#integration issue#index setup#retrieval issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING