[BUG] Turbopack patch: `discoverBareExternalImports` breaks builds for packages using Node.js subpath imports (e.g. MathJax)

[314systems]

Describe the bug

When building a Next.js app (Turbopack) that depends on a package using Node.js subpath imports (the #name/* syntax in package.json#imports), the OpenNext bundle step fails with esbuild Could not resolve errors.

✘ [ERROR] Could not resolve "#mhchem/mhchemParser.js"

    .open-next/server-functions/default/node_modules/.pnpm/@mathjax+src@4.1.1/node_modules/@mathjax/src/mjs/input/tex/mhchem/MhchemConfiguration.js:7:29:
      7 │ import { mhchemParser } from '#mhchem/mhchemParser.js';
        ╵                              ~~~~~~~~~~~~~~~~~~~~~~~~~

  The remapped path "mhchemparser/esm/mhchemParser.js" could not be resolved:

    .open-next/server-functions/default/node_modules/.pnpm/@mathjax+src@4.1.1/node_modules/@mathjax/src/package.json:58:17:
      58 │     "#mhchem/*": "mhchemparser/esm/*",
         ╵                  ~~~~~~~~~~~~~~~~~~~~

  You can mark the path "#mhchem/mhchemParser.js" as external to exclude it from the bundle, which
  will remove this error and leave the unresolved path in the bundle.

✘ [ERROR] Could not resolve "#default-font/svg/default.js"

    .open-next/server-functions/default/node_modules/.pnpm/@mathjax+src@4.1.1/node_modules/@mathjax/src/mjs/output/svg/DefaultFont.js:1:21:
      1 │ import { Font } from '#default-font/svg/default.js';
        ╵                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  The remapped path "@mathjax/mathjax-newcm-font/mjs/svg/default.js" could not be resolved:

    .open-next/server-functions/default/node_modules/.pnpm/@mathjax+src@4.1.1/node_modules/@mathjax/src/package.json:59:23:
      59 │     "#default-font/*": "@mathjax/mathjax-newcm-font/mjs/*"
         ╵                        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  You can mark the path "#default-font/svg/default.js" as external to exclude it from the bundle,
  which will remove this error and leave the unresolved path in the bundle.

Steps to reproduce

1. Create a Next.js app using Turbopack.
2. Add a dependency that relies on Node.js subpath imports, e.g.
   @mathjax/src (import anything from it in a server route).
3. Build with @opennextjs/cloudflare on a revision that includes fix: dynamically resolve Turbopack external module mappings #1139.
4. Observe the esbuild Could not resolve "#..." errors during
   "Bundling the OpenNext server...".

Checking out a revision before commit b98c6e1 makes the build succeed, which confirms the regression point.

Expected behavior

The build should succeed. Packages that use Node.js subpath imports should either be bundled correctly, or be left to the existing default: await import($ID) dynamic fallback instead of being forcibly promoted to a static await import("<literal>") that esbuild cannot resolve.

@opennextjs/cloudflare version

1.19.3

Wrangler version

4.84.1

next info output

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 25.4.0: Thu Mar 19 19:33:09 PDT 2026; root:xnu-12377.101.15~1/RELEASE_ARM64_T8112
  Available memory (MB): 16384
  Available CPU cores: 8
Binaries:
  Node: 24.15.0
  npm: 11.12.1
  Yarn: N/A
  pnpm: 10.33.0
Relevant Packages:
  next: 16.2.4 // Latest available version is detected (16.2.4).
  eslint-config-next: N/A
  react: 19.3.0-canary-da9325b5-20260417
  react-dom: 19.3.0-canary-da9325b5-20260417
  typescript: 6.0.3
Next.js Config:
  output: N/A

Additional context

This issue was drafted with the help of an AI assistant while investigating the build failure, so some of the technical claims above (especially the commit-level attribution and the root-cause reasoning) may be inaccurate.

[vicb]

@james-elicx it looks like this might be related to #1139, would you mind taking a quick look when you can find time?
Thanks

[james-elicx]

Hi, it looks like this is related to the traced files that are available when doing a build. I've put up a PR to extend what's collected with package.json imports, and there's a prerelease in #1231 (comment) if you want to try it out :)

[vicb]

@314systems could you please include a minimal repro (link to a GH repository) with what you would expect to see.

I know you added steps but it would save us time.

You explicitly mention Turbopack, does that mean that WebPack works?

[314systems]

https://github.com/314systems/opennextjs-cloudflare/tree/mathjax-demo

[vicb]

@james-elicx figured out that the root cause of the issue is in Next.js.

As the Next team is working on a fix, we are pondering whether to release James' workaround or wait for the fix to be released in the next Next version.