Turbopack does not import from exports correctly when *.ts and *.tsx are specified

[RhysSullivan]

Link to the code that reproduces this issue

https://github.com/RhysSullivan/bun-transpile-packages-turbopack

To Reproduce

To validate it is broken with Turbo:

• bun dev:turbo
• navigate to http://localhost:3000/single , see that it compiles correctly
• navigate to http://localhost:3000/multiple , see that it fails to compile

The only difference between these packages is the exports section of package.json

To validate it works with Turbo disabled

• bun dev:no-turbo
• navigate to http://localhost:3000/single , see that it compiles correctly
• navigate to http://localhost:3000/multiple , see that it compiles correctly

Current vs. Expected behavior

Turbopack should work with multiple file extensions in the exports field

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.4.0: Fri Mar 15 00:19:22 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T8112
  Available memory (MB): 16384
  Available CPU cores: 8
Binaries:
  Node: 20.13.1
  npm: 10.5.2
  Yarn: N/A
  pnpm: 9.1.2
Relevant Packages:
  next: 15.0.0-canary.181 // Latest available version is detected (15.0.0-canary.181).
  eslint-config-next: N/A
  react: 19.0.0-rc-2d16326d-20240930
  react-dom: 19.0.0-rc-2d16326d-20240930
  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), next start (local)

Additional context

No response

[mischnic]

In Node (which introduced the exports field that Next.js/Webpack/Turbopack are imitating), this is actually the intended behavior. It always uses the first entry in the array.

The reason it currently works in Next.js without Turbo is that Next.js is still using Webpack 5.90.0, and this was only changed back to be compatible with Node in 5.94.0

(There's a section about this in the Webpack docs as well, under the "Alternatives" section: https://webpack.js.org/guides/package-exports/#alternatives)

[RhysSullivan]

Interesting thanks, looks like this isn't a bug then thanks for investigating

Might be worth throwing in a warning to turbopack if when using an internal package w/ an exports array, that only the first entry will be used? The error is a little unintuitive at the moment

[lfades]

Did you see docs for having the exports entry be an array? I tried looking at Node.js and TypeScript without any look. Webpack is different but that would be fine as it extends the default behavior.

[voinik]

Holy crap, I've been trying to find what's causing my "Module not found" errors. Turns out it's the array syntax in the exports field. Thank you so much!

[JCMais]

Hmm, I think I have a similar issue, where we are using ES Modules in the project with Node.js module resolution, which means file extensions are required, and they end with jsx or js.

But the actual files are tsx or ts.

Is it possible to make turbopack try to resolve different file extensions for the same module?

[timneutkens]

Going to close this issue as per @mischnic's explanation: https://github.com/vercel/next.js/issues/71001#issuecomment-2407453993

However, you can have fallback resolving using turbopack.resolveAlias or using tsconfig.json paths which supports resolving multiple patterns as well. Relevant docs: https://nextjs.org/docs/app/api-reference/config/next-config-js/turbopack#resolving-aliases

[github-actions[bot]]

This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.