Skip to content

Loading duckdb wasm binary causes Turbopack to hang forever #78591

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
controversial opened this issue Apr 26, 2025 · 3 comments
Open

Loading duckdb wasm binary causes Turbopack to hang forever #78591

controversial opened this issue Apr 26, 2025 · 3 comments
Labels
linear: turbopack Confirmed issue that is tracked by the Turbopack team. Turbopack Related to Turbopack with Next.js.

Comments

@controversial
Copy link
Contributor

Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/compassionate-cray-jklgc5?workspaceId=ws_WCzEq2KEAJjTU1wDZNuBDJ

To Reproduce

  1. Run next dev --turbopack
  2. Load localhost:3000
  3. Observe that “Compiling / ...” is logged
  4. Observe that “compiled in XXms” is never logged
  5. Observe that the page never loads

Current vs. Expected behavior

“Compiling /” hangs forever; the page never compiles.

Provide environment information

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

Additional context

Occurs both during next dev --turbopack and next build --turbopack

Very high CPU usage during while the page is not compiling

The linked reproduction consists solely of

  • import duckdbWasm from "@duckdb/duckdb-wasm/dist/duckdb-mvp.wasm";
  • a line to prevent the import from being dead-code eliminated / tree-shaken: console.log(duckdbWasm);
@github-actions github-actions bot added the Turbopack Related to Turbopack with Next.js. label Apr 26, 2025
@mischnic mischnic added the linear: turbopack Confirmed issue that is tracked by the Turbopack team. label Apr 28, 2025
@mischnic
Copy link
Contributor

mischnic commented Apr 28, 2025

Importing that file generates megabytes of javascript, because turbopack tries to expose every single export, it's just way too much:

Image

import duckdbWasm from "@duckdb/duckdb-wasm/dist/duckdb-mvp.wasm?module"; should ideally also work (especially as a workaround for the problem above), but the package.json#exports field in @duckdb/duckdb-wasm prevents that.

@controversial
Copy link
Contributor Author

Got it, that’s understandable.

Should Turbopack be able to place sensible limits and produce warnings/early failure in this type of case (attempting to codegen an unreasonable a huge number of imports)? As a user, I didn’t have any way to tell that this was the problem!

import ... ?module"; should ideally also work

What is ?module supposed to do? Is that import query mechanism documented?

@mischnic
Copy link
Contributor

something.wasm?module will return the result of WebAssembly.compile
something.wasm will return the result of WebAssembly.instantiate.

I'm afraid that isn't documented anywhere.

Should Turbopack be able to place sensible limits and produce warnings/early failure in this type of case (attempting to codegen an unreasonable a huge number of imports)?

Yes. Either it should just work, or throw an error. I'm hoping Turbopack can still support importing this though

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
linear: turbopack Confirmed issue that is tracked by the Turbopack team. Turbopack Related to Turbopack with Next.js.
Projects
None yet
Development

No branches or pull requests

2 participants