Turbopack build fails fatally on node-pre-gyp packages without napi_versions (e.g. duckdb)

Link to the code that reproduces this issue

https://github.com/C0casio45/next-duckdb-napi-versions-repro

To Reproduce

1. Clone the reproduction and install dependencies (npm install / bun install). It is a minimal create-next-app on next@canary with a single extra dependency, duckdb, imported from a server route.
2. Run npx next build (Turbopack, the default bundler).
3. The build aborts with a fatal TurbopackInternalError while tracing duckdb's package.json. The same code builds fine with npx next build --webpack.

The reproduction is not duckdb-specific: any Next.js app depending (directly or transitively) on a node-pre-gyp package whose binary config omits the optional napi_versions field hits the same crash.

Current vs. Expected behavior

Current: next build aborts fatally (re-verified today on 16.4.0-canary.8):

- Execution of <NodePreGypConfigReference as ModuleReference>::resolve_reference failed
- missing field `napi_versions` at line 17 column 3
    at binary
      13 |   "binary": {
      14 |     "module_name": "duckdb",
      15 |     "module_path": "./lib/binding/",
      16 |     "host": "https://npm.duckdb.org/duckdb"
         |   v
      17 +   },
         |   ^
    at <unknown> (TurbopackInternalError: Failed to write app endpoint /page) {
  type: 'TurbopackInternalError',
  location: undefined
}

Expected: the build succeeds. napi_versions is an optional field in node-pre-gyp's binary config — it only exists to drive the {napi_build_version} substitution for N-API builds (see the node-pre-gyp docs). duckdb's config (module_name + module_path + host, no template tokens) is valid, and next build --webpack handles it fine.

Root cause (still present on today's canary): turbopack/crates/turbopack-resolve/src/node_native_binding.rs deserializes the config into

#[derive(Deserialize, Debug)]
struct NodePreGypConfig {
    module_name: String,
    module_path: String,
    napi_versions: Vec<u32>,   // <- required by serde, optional in node-pre-gyp
}

so the serde error surfaces as a fatal TurbopackInternalError instead of either (a) parsing the valid config or (b) reporting a scoped, resumable issue.

Proposed fix: mark napi_versions as #[serde(default)], and when the list is empty, resolve module_path once as-is instead of iterating versions (there is no {napi_build_version} token to substitute in that case, so binary tracing still finds the .node files). PR: #97539.

No config workaround exists — serverExternalPackages was tested and the package is still traced.

Provide environment information

Operating System:
  Platform: linux
  Arch: x64
  Version: #134-Ubuntu SMP PREEMPT_DYNAMIC Fri Jun 26 18:43:11 UTC 2026
  Available memory (MB): 48154
  Available CPU cores: 12
Binaries:
  Node: 24.14.0
  npm: 11.9.0
  Yarn: 1.22.22
  pnpm: 10.33.1
Relevant Packages:
  next: 16.4.0-canary.8 // Latest available version is detected (16.4.0-canary.8).
  eslint-config-next: N/A
  react: 19.2.8
  react-dom: 19.2.8
  typescript: N/A
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 build (local), next dev (local)

Additional context

Also reproduced on stable 16.1.6 and on 16.3.1-canary.25 (2026-08-20), and re-verified today (2026-08-26) on 16.4.0-canary.8.

This was previously reported as #97538 and #97600; both were auto-closed by the reproduction-link bot (the first predates the reproduction repository, the second did not follow the issue-template structure closely enough for the bot to detect the link). Following the bot's own guidance ("we encourage you to open a new one linking to the old issue"), this issue supersedes both. The proposed fix is in PR #97539.

Start with turbopack/crates/turbopack-resolve/src/node_native_binding.rs and run the linked reproduction with npm install, then npx next build. Confirm that a node-pre-gyp binary config without napi_versions is handled and the duckdb app builds successfully with Turbopack; review PR #97539 for work already in progress.