Niklas Mischkulnig

We will look into it further soon.

`react-native` doesn't work in a web context anyway. You want react-native-web. See this config for example: https://github.com/nandorojo/solito/blob/2cc9f5e3a24e93ce974312bbaf95d61722e66342/develop/appdir/next.config.js#L37

* **#82827** 👈 (View in Graphite) * `canary` This stack of pull requests is managed by Graphite. Learn more about stacking.

No need to worry. We were just busy recently with getting other stuff fixed for the Next.js 16 release.

I am able to reproduce this in VSCode, but I'm not sure yet if it's Turbopack's, Next.js's or VSCode's fault.

That's a great reproduction. It's indeed a Turbopack bug. You can use `nextConfig.experimental.turbopackScopeHoisting = false` to workaround it by disabling the faulty optimization until this is fixed https://github.com/vercel/next.js/pull/82827

Doesn't this break a whole lot of things? E.g. if something does a match on `JsValue::Add(JsValue::Number(a), JsValue::Number(b)) => JsValue::Number(a+b)`. That would have to always try to unwrap it now.

Yes, the alternative would also to just keep modelling assignments as `undefined`, so revert https://github.com/vercel/next.js/pull/83962 And then later on, we can do it properly with the meta flag.

I think that link is a red herring: https://github.com/vercel/next.js/blob/684d11bfc9fd491102c4f13168ff681df6001952/packages/next/src/server/dev/hot-reloader-turbopack.ts#L277 Do you really see code getting minified in dev with Next.js?

(I think this is also needed for a true WASM-ESM integration, where the loading and compiling is inherently asynchronous). https://github.com/tc39/proposal-top-level-await Without scope hoisting, this seems easy enough (just await the...