blitz dev --turbo (next wrapper) broken since Next 15.0.0-rc.1

[fungilation]

Link to the code that reproduces this issue

blitz-js/blitz#4395

To Reproduce

blitz-js/blitz#4395

Current vs. Expected behavior

blitz dev --turbo should work with blitz which wraps next, but error since Next 15.0.0-rc.1 and 15.x releases.

Don't close this because I didn't provide repro code. Any blitz install with different Next versions as I've bisected would lead to this local dev build error with turbopack.

Provide environment information

(node:18584) ExperimentalWarning: CommonJS module /usr/local/lib/node_modules/npm/node_modules/debug/src/node.js is loading ES Module /usr/local/lib/node_modules/npm/node_modules/supports-color/index.js using require().
Support for loading ES Module in require() is an experimental feature and might change at any time
(Use `node --trace-warnings ...` to show where the warning was created)


Operating System:
  Platform: darwin
  Arch: x64
  Version: Darwin Kernel Version 23.6.0: Thu Sep 12 23:34:49 PDT 2024; root:xnu-10063.141.1.701.1~1/RELEASE_ARM64_T8103
  Available memory (MB): 16384
  Available CPU cores: 8
Binaries:
  Node: 23.3.0
  npm: 10.9.0
  Yarn: 1.22.22
  pnpm: 9.14.2
Relevant Packages:
  next: 15.0.0-rc.0 // Latest available version is detected (15.0.0-rc.0).
  eslint-config-next: 15.0.0-rc.0
  react: 19.0.0-rc-66855b96-20241106
  react-dom: 19.0.0-rc-66855b96-20241106
  typescript: 5.4.5
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_

[JesseKoldewijn]

Either with or without reproduction, the matter at hand still sounds like a blitz issue specifically. So I think it might be best if you move this issue to their side.

[fungilation]

It's a issue with both, but yes I reported issue which I linked at blitz first blitz-js/blitz#4395

and it is a Turbopack issue because if I omit --turbo, dev runs fine. And --turbo worked fine up to Next 15.0.0-rc.0 as I mentioned, broke in rc.1 and on including 15.0.3 and canary .0.4

[mischnic]

This is caused by that [project]/node_modules/.blitz/turbopack-empty.js file. So it's not a Turbopack issue but a blitz one.

Turbopack correctly detects that you are trying to import the default export of a file containing export {}. Which would never work.

They should instead try to do module.exports = {} in that file (or something like that using CommonJS), because that can't be statically analyzed.

[fungilation]

confirmed that module.exports = {} in node_modules/.blitz/turbopack-empty.js works

however this is still issues on both sides. Since export {} works in webpack period, and has worked with turbopack up to Next 15.0.0-rc.0. Shouldn't turbopack be maximize webpack compatibility with libraries generally?

[mischnic]

That turbopack-empty.js is really an edge case.

The original usecase is that you that you (the user) tries to import something from another file that you (the user) also wrote (or a library), and using the wrong export name is never what you want.

So the DX benefit outweighs the compatibility problem here.

[github-actions]

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.