Conversation
…g an experimental config option
This stack of pull requests is managed by Graphite. Learn more about stacking. |
Failing test suitesCommit: 7836721 | About building and testing Next.js |
| webpackBuildWorker: z.boolean().optional(), | ||
| webpackMemoryOptimizations: z.boolean().optional(), | ||
| turbopackMemoryLimit: z.number().optional(), | ||
| turbopackNodeBackend: z.enum(['workerThreads', 'childProcesses']).optional(), |
There was a problem hiding this comment.
maybe turbopackEscmascriptBackend? turbopackPluginRuntimeStrategy?
if the next process is running in bun then we would use bun worker threads.
There was a problem hiding this comment.
I think that maybe we need to change the crate name to something else like turbopack_loader? thenTurbopackLoaderBackend will be better.
There was a problem hiding this comment.
yeah fair, hello scope creep 😏
There was a problem hiding this comment.
Too late, I'm doing turbopackPluginRuntimeStrategy 😆
| pub use backend::{CreatePoolFuture, CreatePoolOptions, NodeBackend}; | ||
| #[cfg(feature = "process_pool")] | ||
| pub fn child_process_backend() -> Vc<Box<dyn NodeBackend>> { | ||
| Vc::upcast(process_pool::ChildProcessesBackend.cell()) | ||
| } | ||
| #[cfg(feature = "worker_pool")] | ||
| pub fn worker_threads_backend() -> Vc<Box<dyn NodeBackend>> { | ||
| Vc::upcast(worker_pool::WorkerThreadsBackend.cell()) | ||
| } |
There was a problem hiding this comment.
this would be the perfect place to prewarm. of course we would need a chunking context too but perhaps we could build it?
future work
Merging this PR will improve performance by 3.26%
Performance Changes
Comparing Footnotes
|
Stats from current PR✅ No significant changes detected📊 All Metrics📖 Metrics GlossaryDev Server Metrics:
Build Metrics:
Change Thresholds:
⚡ Dev Server
📦 Dev Server (Webpack) (Legacy)📦 Dev Server (Webpack)
⚡ Production Builds
📦 Production Builds (Webpack) (Legacy)📦 Production Builds (Webpack)
📦 Bundle SizesBundle Sizes⚡ TurbopackClient Main Bundles: **401 kB** → **401 kB** ✅ -23 B80 files with content-based hashes (individual files not comparable between builds) Server Middleware
Build DetailsBuild Manifests
📦 WebpackClient Main Bundles
Polyfills
Pages
Server Edge SSR
Middleware
Build DetailsBuild Manifests
Build Cache
🔄 Shared (bundler-independent)Runtimes
📝 Changed Files (1 file)Files with changes:
View diffsserver.runtime.prod.jsDiff too large to display 📎 Tarball URL |

Follow-up to #86266
This was mostly LLM-generated, but it's just moving things around and threading through a config option.
We'd like to be able to turn this on/off with an experimental config option:
- Fixes issues where RA thinks a bunch of code is dead.
- Lets us isolate potential issues to the worker thread implementation.
- Provides an escape hatch for users in case there are issues.
- Better fits the cargo "additive feature" model.