Niklas Mischkulnig

@devongovett @5813cf9e38904f I still very much want to do this! Just haven't found the time yet...

@5813cf9e38904f Mayybe with some hacks like data URLs or something. But I’m still trying to convince the Turbopack team to add native support for macros. That would be faster too. 😉 cc @mischnic

unplugin-parcel-macros brings Parcel's build-time macro support to other bundlers, including Vite, Webpack, Rollup, and Esbuild. v0.2.0 adds support for WASM, so it works in browser environments like Stackblitz too! github.com/devongovett/un…

How we're making Turbopack fast. In this deep dive, @lukeisandberg explains how Turbopack uses incremental caching and compilation so the cost of work scales with your change, not the size of your app.

Learn how we built Turbopack with incremental computation to scale development and builds to Next.js applications of all sizes. nextjs.org/blog/turbopack…

@grhmc So „ui“ has a lockfile? You should set config.turbopack.root to path.join(__dirname, „..“) nextjs.org/docs/app/api-r…

I have ~/src/github.com/DeterminateSystems/{ui,docs}. Normally, `docs` depends on an npm-published version of `ui`. Sometimes, though, I'll `npm install ../ui` to debug a cross-cutting issue. Which breaks only turbopack at run-time with `Module not found: Can't resolve the-ui-package`. But everything looks fine. It's maddening to debug this problem until you manage to find one of the many github issues about it pointing to turbopack.root. It's also a bummer because we have to turn off turbopack so we don't get lost in a multi-hour debug session in the rare case we replace a dep with a local checkout. I wish turbopack was smart about local deps, but failing that I wish that error message was loudly complaining about the local dep outside of the turbopack.root, telling me either how to fix it or turn off turbopack.

it's a total bummer that turbopack requires extra config to make locally sourced packages work

We introduced a dedicated HackerOne program for Vercel WAF bypasses for CVE-2025-55182 / react2shell Critical bypass: $50K hackerone.com/vercel_platfor…

@rjwadley I think we are gonna change it so that data-urls are by default spec compliant and you opt into the current behavior with a special mime type

@mischnic the issue I'm seeing is that shared css (e.g. a reset, css layers, global variables, etc) is bundled many times (once per file!) I might be able to fix it by proxying through a real file to deduplicate the sources since I don't need relative imports. thanks for the insight!

@mischnic I wrote a turbopack loader for vanilla extract that uses data URIs to import CSS. github.com/vercel/next.js… mentions they aren't deduplicated, is that still the case?

@rjwadley yes. that is exactly why I went slightly spec-incompliant there. when transpiling css-in-js -> CSS data url import, then it's very useful to have relative imports work. there's a test case here: github.com/vercel/next.js…

@mischnic got it. the spec wouldn't allow relative imports but turbopack currently allows them and resolves them relative to the importing file? For the vanilla extract case the spec'd behavior would probably be better (unless there's better way to virtually import css than a data uri)

We've been working on something new: Turbopack / Next.js bundle analyzer. It's fully aware of Next.js routes and the Turbopack module graph. You no longer have to guess where a module is loaded. It shows the full import stack so that you can easily find where the module is used, not just one path but all paths that lead to the module being included in the bundle. You can also inspect CSS size and other assets, as well as the server bundles. Note: Output size shown is without compression (gzip/brotli). We're planning to add that. For example running it on an open source application:

@JimsonRai @timneutkens See github.com/vercel/next.js…, I have a reproduction now and we'll try to fix it soon.

@timneutkens Tim is the goat and we figured this out in 5min. experimental.turbopackModuleIds is super helpful

@timneutkens I have no idea how to debug this. Hard to get a minimal repro. Updating to next 16, works on 15. Would be helpful if we could get more metadata about the problematic modules Error: Module 998912 was instantiated because it was required from module 837607, but the module factory is not available....

@decocereus What problem are you running into with polyfills?

bro I hate next js why does turbopack have to be so ass with polyfills

@velddev What issue are you seeing exactly? Can you open a GitHub issue?

Does turbopack just not work in a yarn monorepo? I swear I kept seeing errors all these tests passing and then I enable it and it implodes on impact. 🤔🤔

@timneutkens @TrosclairTweets @nextjs This will be fixed by github.com/vercel/next.js…

@TrosclairTweets @nextjs I’ll follow up in DM!

Next.js 16 • Cache Components • Turbopack enabled by default • Turbopack file system caching (beta) • Optimized navigations and prefetching • Improved caching APIs • Build Adapters API (alpha) • React 19.2 nextjs.org/blog/next-16

@fuma_nama @rauchg @isukkaw @nextjs What exactly are you missing? On our radar is most importantly resolver plugins and transformation (i.e. what Webpack loaders do, though not very fast). Turbopack should implement most of the same semi-standard Webpack module.hot HMR API. But indeed not documented.

Yea would be great to have an extensive plugin system like Vite, and more docs on the internals. Developing webpack plugins for Next.js while taking Turbopack compatibility in account is actually difficult, It's a major blocker for deeper integration into the framework (like a public HMR API for plugin developers)

I have spent the past months developing a plugin for @nextjs and App Router. It is an absolute nightmare. The image contains all the bullet points. But if you are interested, the link to the article containing the full story behind the struggle can be found in the replies.

@manulpz4 @timneutkens I see, can reproduce the problem on 15.5.4. It's already fixed on the next@canary versions though.

@mischnic @timneutkens This is our current middleware

Every Route Handler in Next.js is now 200ms+ faster in development! Available on next@canary. Coming to stable soon!

@manulpz4 @timneutkens Are you using middleware with the "nodejs" runtime? And if yes, how are you configuring that? Anything unusual about that `export const config = ...`? #runtime" target="_blank" rel="nofollow noopener">nextjs.org/docs/app/api-r…

Tim, we tried to use --turbopack in the production build on Vercel but it always throws the following, do you know why could it be? Traced Next.js server files in: 116.421ms Created all serverless functions in: 1.662s Error: ENOENT: no such file or directory, open '/vercel/path0/.next/server/middleware.js.nft.json'

@rsdgpt @convex @openrouter You mean web workers? What exactly wasn't working? Do you have a reproduction by chance?

@convex @openrouter okay turbopack and workers do NOT work well together yet. that was an hour of my life for a feature nobody will ever use. but god am i happy it works.

okay, i have a 6 hour flight. Going to ship "Play Chess vs LLMs" while in the air. Tech stack: Convex (first time using) NextJS Bun @shadcn and chessground. Wish me luck and follow along for more.

@redacted_noah @timneutkens That one does indeed not work, you're running into issue: github.com/feross/buffer/… Same with Webpack though, so not specific to Turbopack:

@mischnic @timneutkens ``` const buf = Buffer.alloc(4); buf.writeUint32LE(id); ``` That works in nodejs, not in turbopack

So much random stupid shrapnel in frontend Solana development. Like for some idiotic reason, everyone decided to use Buffer. And Buffer.alloc returns a UInt8Array on web instead of a Buffer like in node. So things just break. In libraries you can't control

@redacted_noah @timneutkens That write function doesn't exist (and your snippet doesn't work in Node.js either), do you mean Buffer.alloc(8).writeBigUInt64LE(2n) maybe? That one does work with both Turbopack and Webpack in Next.js

@timneutkens Easy to replicate. Run Buffer.alloc(4).writeUint64LE(2) That will fail when using Turbopack. Because alloc doesn’t return a Buffer like it should